[posila][0.17.50] Numpad numbers do not accept Shift as a modifier key

We are aware of them, but they have low priority. We have more important things to do. They go here in order not to take space in the main bug thread list.
Post Reply
Der_Failer
Burner Inserter
Burner Inserter
Posts: 9
Joined: Tue Apr 25, 2017 9:25 pm
Contact:

[posila][0.17.50] Numpad numbers do not accept Shift as a modifier key

Post by Der_Failer »

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

User avatar
mexmer
Filter Inserter
Filter Inserter
Posts: 869
Joined: Wed Aug 03, 2016 2:00 pm
Contact:

Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key

Post by mexmer »

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.

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key

Post by posila »

mexmer wrote:
Sat Jun 22, 2019 3:47 pm
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.
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.

User avatar
mexmer
Filter Inserter
Filter Inserter
Posts: 869
Joined: Wed Aug 03, 2016 2:00 pm
Contact:

Re: [0.17.50] Numpad numbers do not accept Shift as a modifier key

Post by mexmer »

posila wrote:
Sat Jun 22, 2019 6:21 pm
mexmer wrote:
Sat Jun 22, 2019 3:47 pm
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.
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.
ah ok, thanks for correction. :oops:

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: [posila][0.17.50] Numpad numbers do not accept Shift as a modifier key

Post by posila »

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.

Post Reply

Return to “Minor issues”