Character keys outside of latin1 codepage cannot be bound
First of all, DarkPlaces does not recognize non-ASCII symbols in the console as first argument for the bind command. For example,
bind é foo outputs "é" isn't a valid key if utf8_enable is 1 and outputs nothing if it's set to 0, but the bind does not work (the character showing in the console when é is typed is part of the special font characters). Moreover, those keys cannot even be bound in the menu, it complains that "<UNKNOWN KEYNUM>" isn't a valid key (regardless of utf8_enable).
This can be worked around for character keys in the latin1 range through the use of a latin1-encoded configuration file with lines such as This hack has the potentially confusing consequence of binds overlapping. Nevermind. See freenode/#xonotic Aug 01 2012 9:30 UTC.
bind é foo.
The real problem comes with characters that are not in the latin1 range. Slovak keyboards, for example, have a numerical key row that consists almost entirely of accented characters that are not in the latin1 codepage and are thus not bindable at all. I guess cyrillic keyboards are not usable at all either. This is kind of a big deal.
I put this issue in the "engine" category, but it also affects the menu.Relevant forums.xonotic threads:
- Slovak keyboard: Cant use F-keys (they actually meant the number row)
- Russian keyboard: Keyboard messed up on OS X (although perhaps not fully related to the present issue)
- French keyboard: Numbers key don't work with azerty keyboards
In French and Belgian keyboards numbers are on shift level. The corresponding non-shift level has characters such as é, à, ç, ... all in the latin1 range.
Ow. What can we do about this then? Show a warning message in the menu suggesting QWERTY when the language is set to a cyrillic-based one? Add a FAQ item to the site and documentation? Put it in a README?
Because right now, Xonotic "just doesn't work" for cyrillic layouts.
Russians typically (or rather, ALWAYS) have some keybind to switch to US layout.
Fixing this would basically require turning ALL MAX_KEYS sized arrays into hashtables. Not an easy task at all. Once that's done, the special keys can be remapped from 127 upwards to 0x1000000 upwards and we're good.
- File keys.diff added
I tried to make a patch that synthesizes keycodes if only ascii code is given (which is the case with the international keys). It works with GLX, and fails horribly with SDL (keys never get released). It looks to me like this is the wrong approach...