The Windows runtime keyed the held set by the character MapVirtualKeyA gave a virtual key, so a game's WASD belonged to whatever the active layout put there, and with an input method on every letter arrived as VK_PROCESSKEY. The typing block is now read from the scancode (the arrows, numpad and F-keys still by virtual key); macOS reads keyCode the same way. Input.key_label(key) names a key in the player's own layout (Windows) or as its US character elsewhere. Verified on Windows with SendInput into a live window: VK_Z carrying W's scancode holds 'w', VK_PROCESSKEY carrying A's holds 'a', Caps Lock changes nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.2 KiB
1.2 KiB
| id | name | category | kind | tokens | sig | tip | order | ns | member |
|---|---|---|---|---|---|---|---|---|---|
| input-key_label | Input.key_label | input | namespace-method | Input.key_label | Input.key_label(key) -> string | The name to show a player for a key - in their own keyboard layout. | 11 | Input | key_label |
Returns the name to show for key. The letter, digit and punctuation codes that Input.key_down reads are physical keys, named for what they type on a US layout: 'w' is the key above 's' on every keyboard, whatever layout, language, input method or Caps Lock state the player has. So WASD is always under the left hand, and the label is what that key types in the player's layout - "W" on QWERTY, "Z" on AZERTY. Space, Enter, Esc, Tab, Backspace, Shift, Ctrl, Alt and the arrows get words, and a code with no name returns "".
On Windows the label is read from the active layout. Headless, on macOS and in the browser it is the US character, upper case.
program Demo {
entry {
print(Input.key_label('w'))
print(Input.key_label(32))
print(Input.key_label(Key.Left))
}
}