chore(release): v0.16.2
All checks were successful
All checks were successful
This commit is contained in:
parent
9a43b14f80
commit
132deac5bc
3 changed files with 19 additions and 17 deletions
18
CHANGELOG.md
18
CHANGELOG.md
|
|
@ -7,6 +7,24 @@ change type. Preview the next one with `ludic dev release --dry-run`.
|
||||||
A released section may carry a hand-written summary paragraph above its groups
|
A released section may carry a hand-written summary paragraph above its groups
|
||||||
(v0.2.0 has one); the generated bullets below it are not edited by hand.
|
(v0.2.0 has one); the generated bullets below it are not edited by hand.
|
||||||
|
|
||||||
|
## v0.16.2 — 2026-09-15
|
||||||
|
|
||||||
|
### Fixes
|
||||||
|
|
||||||
|
- **Keys are physical positions on Windows and macOS, whatever the layout** - `Input.key_down('w')`
|
||||||
|
is the key above S on every keyboard.
|
||||||
|
|
||||||
|
- **Windows** keyed the held set by the character the active layout gave a virtual key, so
|
||||||
|
a game's WASD belonged to whatever the layout put there: on AZERTY W and A were other
|
||||||
|
keys, and with an input method on (Chinese, Japanese, Korean) every letter arrived as
|
||||||
|
VK_PROCESSKEY and no letter key worked at all. The typing block is now read from the
|
||||||
|
scancode; the arrows, the numpad and the F-keys still go by virtual key, and the frame
|
||||||
|
key (`Input.key`, typing) keeps the layout's character.
|
||||||
|
- **macOS** did the same through `charactersIgnoringModifiers`; it now reads `keyCode`.
|
||||||
|
- **`Input.key_label(key)`** names a key for the player in their own layout - `'w'` shows
|
||||||
|
as "W" on QWERTY and "Z" on AZERTY - so a game that shows its bindings never shows a
|
||||||
|
key the player cannot find. Windows reads the layout; headless, macOS and the browser
|
||||||
|
give the US character.
|
||||||
## v0.16.1 — 2026-09-15
|
## v0.16.1 — 2026-09-15
|
||||||
|
|
||||||
### Features
|
### Features
|
||||||
|
|
|
||||||
2
VERSION
2
VERSION
|
|
@ -1 +1 @@
|
||||||
0.16.1
|
0.16.2
|
||||||
|
|
|
||||||
|
|
@ -1,16 +0,0 @@
|
||||||
bump: patch
|
|
||||||
type: fix
|
|
||||||
**Keys are physical positions on Windows and macOS, whatever the layout** - `Input.key_down('w')`
|
|
||||||
is the key above S on every keyboard.
|
|
||||||
|
|
||||||
- **Windows** keyed the held set by the character the active layout gave a virtual key, so
|
|
||||||
a game's WASD belonged to whatever the layout put there: on AZERTY W and A were other
|
|
||||||
keys, and with an input method on (Chinese, Japanese, Korean) every letter arrived as
|
|
||||||
VK_PROCESSKEY and no letter key worked at all. The typing block is now read from the
|
|
||||||
scancode; the arrows, the numpad and the F-keys still go by virtual key, and the frame
|
|
||||||
key (`Input.key`, typing) keeps the layout's character.
|
|
||||||
- **macOS** did the same through `charactersIgnoringModifiers`; it now reads `keyCode`.
|
|
||||||
- **`Input.key_label(key)`** names a key for the player in their own layout - `'w'` shows
|
|
||||||
as "W" on QWERTY and "Z" on AZERTY - so a game that shows its bindings never shows a
|
|
||||||
key the player cannot find. Windows reads the layout; headless, macOS and the browser
|
|
||||||
give the US character.
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue