In-game keyboard configuration

[another_commander]

Observations from the new build:

- International keys seem to work now.
- There is a problem with modifier keys. Ctrl seems to not work at all as a modifier. Alt worked for some assignments (e.g. FPS indicator), did not work for others (e.g. scanner unzoom). Assigning Alt+c for the fast docking works, but plays the Blue Danube for a split second while the tunnel animation is shown. Normally, the Blue Danube does not play at all when fast docking.
- We seem to have lost the Shift+Esc quit shortcut.

[phkb]

Ah, yep, after thinking for a bit I can see where I’ve gone wrong. I’ll do some rework and ship another update.

Thanks for the feedback a_c!

[phkb]

Discovered that Ctrl+Alpha character results in a control code (1-26) being returned as the unicode character, rather than the actual letter. And Ctrl+Number character doesn't return any unicode character at all. So, a quick bit of translation was in order. And I had a logic fault in the code as well. Anyway, I've pushed a new update to the new_keyconfig branch, and I've updated the zip package if someone wants to download that.

[another_commander]

More observations:
- Ctrl still does not work as a modifier when used in conjunction with international characters (e.g. Ctrl+ù is not recognized). Alt seems to be ok though.
- This has probably something to do more with the way the input code handles the scanner zoom inputs, but setting z for zoom and Ctrl+z for unzoom (or even Alt+z) does not work. The scanner zooms continuously no matter what I press, probably because the "z" input is checked first and the zooming routine runs before the unzooming one, using the modifier keys, has any opportunity to be tested or executed. So far this is the only functionality that I have seen doing this, but this might be something to look out for.

Oh, and performance is perfectly fine too. No difference to what we had before as far as I can tell.

[hiran]

More observations:
- Ctrl still does not work as a modifier when used in conjunction with international characters (e.g. Ctrl+ù is not recognized). Alt seems to be ok though.
- This has probably something to do more with the way the input code handles the scanner zoom inputs, but setting z for zoom and Ctrl+z for unzoom (or even Alt+z) does not work. The scanner zooms continuously no matter what I press, probably because the "z" input is checked first and the zooming routine runs before the unzooming one, using the modifier keys, has any opportunity to be tested or executed. So far this is the only functionality that I have seen doing this, but this might be something to look out for.

Oh, and performance is perfectly fine too. No difference to what we had before as far as I can tell.

This sounds really good.
I might chime in as soon as a Linux version is available. Or is it already?

[phkb]

I might chime in as soon as a Linux version is available. Or is it already?

Not yet. I don't have the setup for a Linux build.

[phkb]

setting z for zoom and Ctrl+z for unzoom (or even Alt+z) does not work.

I can fix this, but I'm concerned the fix might have flow on effects.

At the moment, when checking the key press for a function, I'm checking whether the modifier flag is false, OR the modifier key (ie shift, ctrl, alt) is down. So, if the modifier flag is not set, it should ignore the equivalent modifier key, and it would only check the modifier key if equivalent flag is true.

I can change this to be the modifier flag must equal modifier key (ie, both true or both false). That way, "z" will only activate if none of the modifiers keys are down.

However (and this is the downside), you wouldn't be able to press two keys at once if one of those keys contains a modifier. In that instance, the key that didn't have a modifier would not trigger.

How often would this happen? Probably not very often. Where it would be a problem is if you're doing maneuvers with the keyboard, holding down one or two arrow keys, and then (having mapped the fire missile key to Ctrl-m), try to fire a missile. Pressing Ctrl-m would work, but the movement keys would not be recognised while the control key is down and you would stop spinning. As soon as you release the Control key, movement would start again (assuming you hadn't taken your fingers off the keys).

I'm going to push this change to the branch to see how it plays out, but I suspect more work will need to be done to get this right.

As for Ctrl and international characters...hmm... <walks away to pick up big shiny mallet>

[phkb]

Actually, based on what I can see by adding a few additional keyboard layouts to my system, it's likely to be something of a frightful mess for anyone using something other that UK/US keyboard, at least until they go in and make a bunch of changes.

For instance, a ";" on a US keyboard doesn't require a shift. So the definition in keyconfig doesn't have one. But on a German keyboard, you need to use shift to get that character. The standard keyconfig won't work.

I'm actually beginning to think I might need to alter the structure of the keyconfig file to be something like this:

Code: Select all

{
     default = {
        key_roll_left = ([..]);
        ...
     };
     "de" = {
         ...
     };
     "uk" = {
         ...
     };
     "it" = {
         ...
     };
     etc
}

That way, we can control what the standard layout is for the base game, although it would make documentation a much bigger project. Of course, I'd need to be able to get the current locale code. That should be simple, right?

And I thought the hard bit was going to be the GUI code...

[phkb]

To add to the mess, the SDL key codes (and the results from calling the SDL_GetKeyName function) seem to be linked to the system language, not the keyboard layout.

[phkb]

Let me expand a bit on what I've discovered so far in my journey through SDL hell. As they say in the classics, "let me tell ye my tale of woe".

Whenever a key is pressed in Oolite, it triggers a "keydown" event, followed by a "keyup" event. For the keydown event, certain properties are available:
1. A keyboard scancode, which is a unique number corresponding to a key in a specific and constant location on the keyboard. This code is the same no matter what keyboard layout you are using (with caveats).
2. A unicode value that translates into the key character from whatever keyboard layout you are using.
3. A SDLKey property, which is an SDL code for the key. This value is unique and constant, staying the same no matter what keyboard layout you are using. Most of the time, on a US QWERTY keyboard, this will equivalent to the unicode value (with caveats).

Now, Oolite is reading our keyconfig file and translating the key characters into unicode values. And we're getting the unicode value passed to us during the keydown event, which allows for an easy match up.

And if you're just pressing straight keys (ie, with no modifiers), everything is fine. International keys are no problem.

But problems arise if you press Ctrl. First, when pressing Ctrl and an alpha character (a-z), instead of the normal unicode values for a-z (which are 97-122 for lowercase letters, 65-90 for uppercase), you'll get values from 1-26. The reason for this is...well it's complicated. Essentially, Ctrl codes were operations a user could perform to do special functions (like add a CR/LF). The upshot of this is that, suddenly the unicode representation of the key character being pressed is lost.

The SDLKey value is still available. But it remains constant no matter what keyboard layout you're using, I suspect because of what I noted in my previous post, that the values are tied to the system language, not the keyboard layout in use). Which means there is no way to easily translate the data back to the expected key character you entered on the config screen.

As an example, here are some results of some keypresses.
For a US QWERTY keyboard

Code: Select all

Press "z":         Scancode = 44, unicode = 122, SDLKey = 122
Press "Ctrl-z":    Scancode = 44, unicode = 26, SDLKey = 122

For a German QWERTZ keyboard

Code: Select all

Press "z":         Scancode = 21, unicode = 122, SDLKey = 121
Press "Ctrl-z":    Scancode = 21, unicode = 26, SDLKey = 121

The scancode is different because the location of the "z" key has moved, but the unicode values have stayed the same.

So, for basic Ctrl-a to Ctrl-z I can translate the unicode value into the actual key. But things get a little more murky when dealing with Ctrl and international character. For instance, here are the results from pressing ß on a German keyboard (which is a "-" on a US keyboard):

Code: Select all

Without ctrl: Scancode = 12, Unicode = 223, SDLKey = 45
With ctrl:    Scancode = 12, Unicode = 0, SDLKey = 45

Now, when pressing Ctrl, the unicode value is gone completely. Based on this data, I have no way of knowing what the actual key character is. I know the position on the keyboard, and I could look up the SDLKey reference to learn that this is called SDLK_MINUS, but that doesn't help me determine what international character has been mapped to the minus key.

What I need to find is a way to translate the scancode into a virtual keyboard key. The SDL function "SDL_GetKeyName" stubbornly refuses to give any answer other than "-", regardless of the keyboard layout in play (again, because of aforementioned limitation).

This is certainly a challenging project!

[hiran]

Whenever a key is pressed in Oolite, it triggers a "keydown" event, followed by a "keyup" event. For the keydown event, certain properties are available:
1. A keyboard scancode, which is a unique number corresponding to a key in a specific and constant location on the keyboard. This code is the same no matter what keyboard layout you are using (with caveats).
2. A unicode value that translates into the key character from whatever keyboard layout you are using.
3. A SDLKey property, which is an SDL code for the key. This value is unique and constant, staying the same no matter what keyboard layout you are using. Most of the time, on a US QWERTY keyboard, this will equivalent to the unicode value (with caveats).

I think it makes sense to look at the combination of SDLKey and SDLMod. Rendering that with Unicode characters for the user should be optional for the gui but not authorative during gameplay.

https://www.libsdl.org/release/SDL-1.2. ... board.html

[phkb]

think it makes sense to look at the combination of SDLKey and SDLMod

The difficulty is I have no reliable way to translate what the user could enter on the screen, and the data I'm getting back in SDLKey.

[hiran]

think it makes sense to look at the combination of SDLKey and SDLMod

The difficulty is I have no reliable way to translate what the user could enter on the screen, and the data I'm getting back in SDLKey.

Then do not care. In theory you could really show the numerical keycode to the user. It is more important to have consistent behaviour during gameplay.
Once that works we can revisit the 'key naming' or 'key labelling' problem. If nothing else helps, we could even show a graphical version of the keyboard and highlight the key the user pressed. Then no names are required.

[phkb]

After a bit more time to think, the issue only relates to the Ctrl key combinations. If, when doing the override and the user turns on the Ctrl option, I could open a new page with a request to enter the Ctrl+key combination so that the key code can be recorded and stored (probably in the defaults file). If we’ve already captured that key sequence before, we don’t have to ask again.

I think that would be an acceptable user experience, keeping the simplicity of the players key caps as the input, while collecting the additional info required for checking the key down messages.

What do you think?

[hiran]

After a bit more time to think, the issue only relates to the Ctrl key combinations. If, when doing the override and the user turns on the Ctrl option, I could open a new page with a request to enter the Ctrl+key combination so that the key code can be recorded and stored (probably in the defaults file). If we’ve already captured that key sequence before, we don’t have to ask again.

I think that would be an acceptable user experience, keeping the simplicity of the players key caps as the input, while collecting the additional info required for checking the key down messages.

What do you think?

Sounds like a way to go.

BTW, the SDLKey and SDLMod data is almost the raw data received from the keyboard, and the character you are looking for is the cooked information provided by the keyboard driver (or input locale as it might be named these days). For gameplay you want the raw data to also process keys pressed in parallel or get al the CTRL-combinations which seem to not always have a character representation. Only for GUI display you want show cooked data.

The difficulty rises even more if one simple key combination does not directly represent a character. Take this accented french thingy (I do not even know how it is named: è
To get this character, on my german keyboard I press Shift+' to indicate I need this accent: `
The character does not arrive in the display. Instead the keyboard driver waits for the next character. If I press e, then it inserts è. If I press a, it inserts à. If I press Space, it inserts `.
So for the accented characters I press one key combination plus an additional key.

I could not find any reference, but if you find a way to ask the OS or input locale what character is generated with a specific key combination you could achieve something that works across input locales.