Signals

Signals are messages sent to a computer from some external source and can be used for many purposes. They always have at least a name, and may have any number of (simple) parameters. Note that computers may also queue signals on themselves.

Signals can be consumed using [[computer.pullSignal()|API/Computer]] or its preferred wrapper, [[event.pull()|API/Event]].

The following lists all signals triggered by components and the built-in libraries. They are listed in the following format: name(arg: type, ...), meaning you would pull them like local name, arg, ... = event.pull().

Screen

• screen_resize(screenAddress: string, newWidth: number, newHeight: number)
  This signal is queued by screens when their resolution changes, for example because it is manually set via the GPU. The address is the address of the screen the queued the signal.
• click(screenAddress: string, x: number, y: number, playerName: string)
  This signal is queued by screens of tier two and three when they are clicked. This includes left clicks in the GUI (i.e. when a keyboard is attached) or when right-clicking/activating them in the world directly (i.e. when no keyboard is attached). The address is the address of the screen the queued the signal. The x and y coordinates are in "letters" (meaning they map directly to term.setCursor or gpu.set, for example). The player name is the user name of the player that triggered the event.
  Note on the player name: I'll probably add an option to disable this argument in the future, for those who think it's too... unrealistic. It's just quite handy for multi-user programs, so I left it in for now.
• walk(screenAddress: string, x: number, y: number[, playerName: string])
  This signal is queued by screens when a player or other entity walks on them. The address is the address of the screen the queued the signal. The x and y coordinates are the coordinates of the sub-block of the multi-block screen that queued the event. Use [[gpu.getSize()|Component/GPU]] to figure out which area of the display that actually represents.
  Unlike clicks, this can be triggered for regions of the screen where nothing is displayed based on the current resolution, so keep that in mind.
  The same considerations apply to the player name parameter as in click.
• redstone_changed(address: string, side: number)
  This signal is queued by redstone components when an incoming signal changes. The address is either that of the Redstone I/O block or that of the computer with the redstone card that generated the signal. The side is one of the [[sides|API/Sides]] constants and indicates on which side the signal changed. This is relative to the container of the component, so for computers and robots this depends on which way they are facing. For Redstone I/O blocks this is always the absolute side.
• inventory_changed(slot: number)
  This signal is queued by robots when their inventory changes. Note that this only includes changes to the kind of item stored in a slot. For example, increasing or decreasing the size of an already present stack does not trigger this signal. However, swapping one item with another (say, torches with sticks) by hand will actually trigger two signals: one for the removal of the torches, one for putting the sticks into the temporarily empty slot. Swapping items using [[robot.transferTo()|API/Robot]] will even trigger four signals - the same thing, but for the two slots involved in the swap.
  Also, this only fires for the actually addressable inventory of the robot, i.e. it does not trigger for changes in equipment (tool, card, upgrade).