Updated Signals (markdown)

Signals.md

@@ -7,14 +7,25 @@ The following lists all signals triggered by components and the built-in librari
 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|Component/GPU]]. The address is the address of the screen the queued the signal.
+  This signal is queued by [[screens|Blocks#basic-screen]] when their resolution changes, for example because it is manually set via the [[GPU|Component/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.
+  This signal is queued by screens of [[tier two|Blocks#advanced-screen]] and [[tier three|Blocks#superior-screen]] 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.  
+  **Important**: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[registered as a user|ComputerUsers]] on the computer (or there are no users registered on the computer).
 - `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.  
+  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 `click`.
+- `key_down(keyboardAddress: string, char: number, code: number, playerName: string)`  
+  This signal is queued by [[keyboards|Blocks#keyboard]] when a user inputs something on the screen it's attached to, more specifically when the user *presses* a key. This event may be repeated if the user keeps pressing the key.  
+  **Important**: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[registered as a user|ComputerUsers]] on the computer (or there are no users registered on the computer).
+- `key_up(keyboardAddress: string, char: number, code: number, playerName: string)`    
+  This signal is queued by [[keyboards|Blocks#keyboard]] when a user inputs something on the screen it's attached to, more specifically when the user *releases* a key.  
+  Note that although most cases where a player can be "removed" from a screen without releasing the key before-hand *should* be handled (I think) there may still be cases where this fails. Meaning this feature is more or less in an... observation stage, and may be removed at a later point if it proves infeasible.  
+  **Important**: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[registered as a user|ComputerUsers]] on the computer (or there are no users registered on the computer).
+- `clipboard(keyboardAddress: string, value: string, playerName: string)`  
+  This signal is queued by [[keyboards|Blocks#keyboard]] when a user pastes text from the clipboard (Shift+Ins or middle mouse button). Note that the maximum length of the text that can be pasted is limited (can be changed in the config).
+  **Important**: this signal is *checked*, i.e. it is only queued on a computer if the player that caused it is [[registered as a user|ComputerUsers]] on the computer (or there are no users registered on the computer).
 - `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.
 - `inventory_changed(slot: number)`