I tried to bind something to (right) Shift + Numpad 0, but instead the game just bond it to right shift. I played a bit around and fond that it seems to be related to num lock. When num lock is on the bond key will be just shift, if num lock is off it will be bond correctly to shift Numpad 0.
All Numpad number keys and Numpad comma (in the german qwertz-layout) are effected, other numpad keys (like enter + - etc.) work as expected, regardless of num lock. Other modifier key like Alt and Control also work as expected.
OS is Win 10
[posila][0.17.50] Numpad numbers do not accept Shift as a modifier key
-
- Burner Inserter
- Posts: 9
- Joined: Tue Apr 25, 2017 9:25 pm
- Contact:
Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key
you might not be aware of this, but numpad keys are only "numpad number", when numlock is on. when numlock is off, they have other purpose (on normal pc keyboard it's arrows, ins, del, home, end, pgup, pgdown)
as it has been stated some months ago (i think somewhere on version 0.15), game changed from using scancodes to keycodes (There were issues with remaping of different regional layouts and other stuff). so what you see, is what actually keyboard sends. if numlock is on, it will send numpad0, if it's off, it will send insert.
scancode - code that keyboard emmits (each position has own fixed keycode) - this are based on ibm pc qwerty keyboard layout
keycode - actual symbol that key represents
if we take Q key on QWERTY layout, it's keycode and scancode is Q, while on AZERTY scancode is Q, but keycode is A ...
and same goes for numpad keys.
with scancodes, NUM 0 will be same code, regardless numlock status, because scancode is key postion, but keycode changes, depending on numlock being on or off.
as it has been stated some months ago (i think somewhere on version 0.15), game changed from using scancodes to keycodes (There were issues with remaping of different regional layouts and other stuff). so what you see, is what actually keyboard sends. if numlock is on, it will send numpad0, if it's off, it will send insert.
scancode - code that keyboard emmits (each position has own fixed keycode) - this are based on ibm pc qwerty keyboard layout
keycode - actual symbol that key represents
if we take Q key on QWERTY layout, it's keycode and scancode is Q, while on AZERTY scancode is Q, but keycode is A ...
and same goes for numpad keys.
with scancodes, NUM 0 will be same code, regardless numlock status, because scancode is key postion, but keycode changes, depending on numlock being on or off.
Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key
The change was the other way around (from keycodes to scancodes), so I'd expect numpad0 to emit the same code regardless of numlock state.mexmer wrote: ↑Sat Jun 22, 2019 3:47 pmas it has been stated some months ago (i think somewhere on version 0.15), game changed from using scancodes to keycodes (There were issues with remaping of different regional layouts and other stuff). so what you see, is what actually keyboard sends. if numlock is on, it will send numpad0, if it's off, it will send insert.
Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key
ah ok, thanks for correction.posila wrote: ↑Sat Jun 22, 2019 6:21 pmThe change was the other way around (from keycodes to scancodes), so I'd expect numpad0 to emit the same code regardless of numlock state.mexmer wrote: ↑Sat Jun 22, 2019 3:47 pmas it has been stated some months ago (i think somewhere on version 0.15), game changed from using scancodes to keycodes (There were issues with remaping of different regional layouts and other stuff). so what you see, is what actually keyboard sends. if numlock is on, it will send numpad0, if it's off, it will send insert.
Re: [posila][0.17.50] Numpad numbers do not accept Shift as a modifier key
Thanks for the report.
I've looked into it and the problem is that when pressing Shift + Numpad X, while numlock is active, we receive shift key up (despite it being still held down) before receiving numpad key down. I didn't see any wonky logic in SDL that would cause this behavior, and tested that it behaved the same way with in 0.16 in Allegro, so it is probably how Windows generates these event in the first place. So, I am putting this to minor issues; possibly we'll get back to this in the future and try to hack around the OS behavior.
I've looked into it and the problem is that when pressing Shift + Numpad X, while numlock is active, we receive shift key up (despite it being still held down) before receiving numpad key down. I didn't see any wonky logic in SDL that would cause this behavior, and tested that it behaved the same way with in 0.16 in Allegro, so it is probably how Windows generates these event in the first place. So, I am putting this to minor issues; possibly we'll get back to this in the future and try to hack around the OS behavior.