Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
component:signals [2015/01/14 23:40]
127.0.0.1 external edit
component:signals [2023/12/27 03:29] (current)
hfsr [Contents]
Line 3: Line 3:
 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 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 [[api:​computer|computer.pullSignal()]] or its preferred ​wrapper, [[api:​event|event.pull()]]. The latter is preferred because unwanted signals and the requested signal itself are also distributed as events, which is used by a couple of system functions, such as primary component tracking.+Signals can be consumed using [[api:​computer|computer.pullSignal()]] or its convenience ​wrapper, [[api:​event|event.pull()]].
  
 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()`. For example, to pull a modem message: 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()`. For example, to pull a modem message:
Line 40: Line 40:
  
 - `screen_resized(screenAddress:​ string, newWidth: number, newHeight: number)`  ​ - `screen_resized(screenAddress:​ string, newWidth: number, newHeight: number)`  ​
-  This signal is queued by [[block:​screen|screen]] when their resolution changes, for example because it is manually set via the [[component:​gpu|GPU]]. The address is the address of the screen ​the queued the signal.+  This signal is queued by [[block:​screen|screens]] when their resolution changes, for example because it was manually set via [[component:​gpu|GPU]]. The address is the address of the screen ​that queued the signal.
 - `touch(screenAddress:​ string, x: number, y: number, button: number, playerName: string)`  ​ - `touch(screenAddress:​ string, x: number, y: number, button: number, playerName: string)`  ​
-  This signal is queued by screens of tier two and tier 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.  ​+  This signal is queued by screens of tier two and tier 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 ​or when sneak-activating). 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.  ​   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.  ​
   //​Important//:​ this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[:​computer_users|registered as a user]] on the computer (or there are no users registered on the computer).   //​Important//:​ this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[:​computer_users|registered as a user]] on the computer (or there are no users registered on the computer).
Line 48: Line 48:
   This signal is almost equivalent to the `touch` signal. The only difference is the implicit meaning: when this signal is fired, it "​belongs"​ to a `touch` signal that was fired earlier. This can only be triggered by dragging in the GUI.   This signal is almost equivalent to the `touch` signal. The only difference is the implicit meaning: when this signal is fired, it "​belongs"​ to a `touch` signal that was fired earlier. This can only be triggered by dragging in the GUI.
 - `drop(screenAddress:​ string, x: number, y: number, button: number, playerName: string)`  ​ - `drop(screenAddress:​ string, x: number, y: number, button: number, playerName: string)`  ​
-  This signal is only triggered ​if a `drag` event was triggered first. It is fired when the player releases the mouse button, ​so it's basically ​conditional mouse-up event (with the condition being that the mouse moved while the button was held).+  This signal is triggered when the player releases the mouse button ​after a `touch` signal. Despite the name, it does not necessarily follow ​`drag` signal.
 - `scroll(screenAddress:​ string, x: number, y: number, direction: number, playerName: string)`  ​ - `scroll(screenAddress:​ string, x: number, y: number, direction: number, playerName: string)`  ​
   This signal is queued by screens of tier two and tier three when the player uses the mouse wheel in the GUI. The x and y coordinates are the cursor location when the scroll occurred and are, like the `touch` signal, in "​letters"​. The `direction` indicates which way to scroll, where a positive value usually means "​up",​ whereas a negative value means "​down"​. Note that this may differ based on the client'​s operating system and/or driver configuration. The player name is the user name of the player that triggered the event.  ​   This signal is queued by screens of tier two and tier three when the player uses the mouse wheel in the GUI. The x and y coordinates are the cursor location when the scroll occurred and are, like the `touch` signal, in "​letters"​. The `direction` indicates which way to scroll, where a positive value usually means "​up",​ whereas a negative value means "​down"​. Note that this may differ based on the client'​s operating system and/or driver configuration. The player name is the user name of the player that triggered the event.  ​
Line 76: Line 76:
 ---------------------------- ----------------------------
  
-- `redstone_changed(address:​ string, side: number)` ​  +- `redstone_changed(address:​ string, side: number, oldValue: number, newValue: number[, color: number])`   
-  This signal is queued by [[component:​redstone|redstone components]] when an incoming signal changes. The address is either that of the [[block:​redstone_io|Redstone I/O block]] or that of the computer with the [[item:​redstone_card|redstone card]] ​that generated ​the signal. The side is one of the [[api:​sides|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.+  This signal is queued by [[component:​redstone|redstone components]] when an incoming signal changes. The address is of the [[block:​redstone_io|Redstone I/O block]] or that of the [[item:​redstone_card|redstone card]] ​installed in the machine where the redstone ​signal ​was detected. The side is one of the [[api:​sides|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. The color is only included with bundled inputs, referring to which color of input changed. 
 + 
  
 Motion Sensor Block Motion Sensor Block
Line 102: Line 104:
 Abstract Bus Card Abstract Bus Card
 ----------------- -----------------
 +
 +from [Stargate Tech 2](http://​stargatetech.theender.net/​miscellaneous/​home.html).
  
 - `bus_message(protocolId:​ number, senderAddress:​ number, targetAddress:​ number, data: table, metadata: table)` ​ - `bus_message(protocolId:​ number, senderAddress:​ number, targetAddress:​ number, data: table, metadata: table)` ​
Line 114: Line 118:
 -------- --------
  
-**Important**:​ This component has moved to the OpenComponents addon.+from [Redstone in motion / remain in motion](https://​www.curseforge.com/​minecraft/​mc-mods/​remain-in-motion). 
 + 
 +<del>**Important**:​ This component has moved to the OpenComponents addon.</​del> ​  
 +Contents of OpenComponents have already been added into OpenComputers.
  
 - `carriage_moved(success:​ boolean[, reason:​string[,​ x:number, y: number, z: number]])`  ​ - `carriage_moved(success:​ boolean[, reason:​string[,​ x:number, y: number, z: number]])`  ​
Line 121: Line 128:
 Contents Contents
 ----------- -----------
-{{page>api:​contents&​noheader&​noeditbutton&​nouser&​nofooter}}+{{page>component:​contents&​noheader&​noeditbutton&​nouser&​nofooter}}