numlock on in sdl version:
Keys 4 8 6 2 function both as an arrow and print a number in console (so for an example pressing 8 will print 8 in console then jump to previous command due to it being an up arrow).
Numpad enter doesnt work in chat.
numlock on in glx version:
Keys 4 8 6 2 function just print a number in console
numlock off in sdl version:
123456789 dont do anything
numlock off in glx version:
13579 dont work while 4 8 6 2 function as arrow keys
Works fine in 0.7 version. Tested latest autobuild
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Can you tell me what version of SDL is used? You can find that out by looking at your xonotic log at start up, you should get a line saying "Using SDL library version ..." in the first few hundred lines or so.
Ah, I think I misread the bug report and misled @itsme.xonotic in the process. I understood this as being a bug with key binds, but the binds work fine for both packer and me.
However, I am also experiencing the issue you describe concerning text input. In the console, with numlock enabled, the keys have double action: both the inputs expected with and without numlock occur. Pressing 7 for instance takes me to the beginning of the line, then inputs a 7. With numlock disabled, the keys have no effect.
The game does detect numlock state in a sense, as it works just as expected for key binds. As I mentioned in my comment above, outside of text input, the game sees keypad key presses as either KP_* events when num lock is on, or arrows etc. when num lock is off.
In the console, with numlock enabled, the keys have double action: both the inputs expected with and without numlock occur. Pressing 7 for instance takes me to the beginning of the line, then inputs a 7. With numlock disabled, the keys have no effect.
This is a consequence of SDL internal numlock state being always OFF when the application starts, even if numlock is ON. Toggling numlock (OFF), even SDL internal numlock state gets inverted (ON) leading always to the 2 different bad behaviour you experienced. Btw it also happens when you toggle numlock outside the game (after an Alt-TAB).
I fixed this issue in terencehill/numlock_workaround, please test.
outside of text input, the game sees keypad key presses as either KP_* events when num lock is on, or arrows etc. when num lock is off.
That's the expected behaviour after the changes I did so that you can use 11 more keys. Do you think that's somewhat confusing if one doesn't pay attention to numlock state?
So... since my patch darkplaces!13 (closed) isn't getting applied to the engine, here is what you can do to prevent numpad keys from behaving incorrectly: make sure you start the game with numlock off and avoid changing its state outside the game. If you don't do it you can revert the bug by simply toggling numlock state outside the game.