AstralTransRocketries/OpenComputers
1
0
Fork 0
mirror of https://github.com/MightyPirates/OpenComputers.git synced 2025-08-03 11:07:23 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Signals (markdown)

Florian Nücke 2014-03-14 01:54:18 -07:00
parent 71e6faf9bc
commit c14fec1f82
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Signals.md

@ -44,7 +44,7 @@ Screen
This signal is queued by screens of [[tier two|Blocks#advanced-screen]] and [[tier three|Blocks#superior-screen]] 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.
The same considerations apply to the player name parameter as in `touch`.
- `walk(screenAddress: string, x: number, y: number[, playerName: string])`
This signal is queued by screens of [[tier two|Blocks#advanced-screen]] and [[tier three|Blocks#superior-screen]] 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.
This signal is queued by screens of [[tier two|Blocks#advanced-screen]] and [[tier three|Blocks#superior-screen]] 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 `touch`.
@ -64,17 +64,17 @@ Keyboard
Redstone Cards and I/O Block
----------------------------
- `redstone_changed(address: string, side: number)`
This signal is queued by [[redstone components|Component/Redstone]] when an incoming signal changes. The address is either that of the [[Redstone I/O block|Blocks#redstone-io]] or that of the computer with the [[redstone card|Items#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.
This signal is queued by [[redstone components|Component/Redstone]] when an incoming signal changes. The address is either that of the [[Redstone I/O block|Blocks#redstone-io]] or that of the computer with the [[redstone card|Items#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.
Network Cards
-------------
- `modem_message(receiverAddress: string, senderAddress: string, port: number, distance: number, ...)`
This signal is queued by [[network cards|Items#network-card]] (including wireless ones) when they receive a message on an open port. The first address is the address of the network card that received the message, the second the address from where the message was sent. Note that the sender address may differ from the card that originally sent the message when it passed through one or more [[routers|Blocks#router]]. The port is the port on which the message was received. This distance is the distance only set when receiving *wireless* network messages, in which case it is the distance to the wireless network card that sent the message. For normal network cards the distance will always be zero. All further parameters are user defined and correspond to what the sender specified in `[[modem.send()|Component/Modem]]` or `modem.broadcast()` as the message's payload.
This signal is queued by [[network cards|Items#network-card]] (including wireless ones) when they receive a message on an open port. The first address is the address of the network card that received the message, the second the address from where the message was sent. Note that the sender address may differ from the card that originally sent the message when it passed through one or more [[routers|Blocks#router]]. The port is the port on which the message was received. This distance is the distance only set when receiving *wireless* network messages, in which case it is the distance to the wireless network card that sent the message. For normal network cards the distance will always be zero. All further parameters are user defined and correspond to what the sender specified in [[modem.send()|Component/Modem]] or `modem.broadcast()` as the message's payload.
Robots
------
- `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.
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).
Carriage