Don't interpret K_KP_DOWNARROW and K_KP_UPARROW in console.

[mickael9]

These map to the 2 and 8 on the keypad which makes it impossible to use them on the console for entering numbers.

This is especially important for AZERTY layouts where the number keys are not directly accessible in the first row and using the keypad is more convenient.

[ensiform]

IIRC you're supposed to turn numlock off to use the keypad as numbers. However, I think instead of removing this an optional feature to treat keypad binds in the sdl_input.c code as char events when console or chat is open would be a better approach. Cvar optional please.

[mickael9]

Two events are actually emitted, one key event for the UP/DOWN key and then one char event (if numlock is on) with the number, so if you press keypad 2, it first clears the input line permanently (down key) then it adds the number 2.

Maybe adding new K_KP_0..9 (except for 5) keys would be an option, but I think this goes against the spirit of the bindings system where modifiers are never taken into account and keys are just identified by their physical position (eg, you can bind "[" but not "{", those would be equivalent since shift modifier and caps lock are ignored, or more precisely, considered as regular keys).

Adding a cvar for this? I'm not sure if it's worth it since you can still use the normal directional keys or Ctrl-p / Ctrl-n. Besides, who ever has numlock off (not by mistake!) and is actually using the keypad for movement? (Perhaps I'm biased in this regard since I have an AZERTY keyboard and no number keys on the first row without shifting)