In-game keyboard configuration

[phkb]

More thoughts on the format. Take this current example:

Code: Select all

	key_prev_compass_mode		= "|";

Translating this into the new format would look like this (I've removed the mod1/mod2 lines to keep this brief):

Code: Select all

      key_prev_compass_mode = {
      	   key = "|";
      	   shift = false;
      };

In some ways this could confusing, because you could be forgiven for thinking this would be an equivalent:

Code: Select all

      key_prev_compass_mode = {
      	   key = "\";
      	   shift = true;
      };

(At least on US/UK QWERTY keyboards).
And some things would be quite impossible to translate. For instance:

Code: Select all

      key_new_function = {
      	   key = "!";
      	   shift = true;
      };

I'm not aware of any keyboard layouts that put "!" on a non-shifted key - it's usually Shift+1, or Shift+something. So how do you shift something that is already shifted to being with?

Not sure if I'm overthinking this now (quite possible, running a little low on sleep atm), or if this even needs addressing via code (it might be better left for documentation). But I thought I'd put it out there for further reflection.

[hiran]

I'm not aware of any keyboard layouts that put "!" on a non-shifted key - it's usually Shift+1, or Shift+something. So how do you shift something that is already shifted to being with?

Not sure if I'm overthinking this now (quite possible, running a little low on sleep atm), or if this even needs addressing via code (it might be better left for documentation). But I thought I'd put it out there for further reflection.

I believe we should check two items:

• Look at the relevant standards (so far I only found https://en.wikipedia.org/wiki/ISO/IEC_9995) and try to implement based on that. It may look like more effort but on the other hand would ensure we cover all the keyboard layouts. This way we know what is to be expected across different keyboard layouts.

• Look at how SDL works with keyboard because if the data Oolite receives there is completely different all else is futile.

[phkb]

I've been looking through the source code, assessing how to potentially make all the changes, and I wanted to get an opinion from the broader community. Would you be put off by losing backwards compatibility with the current keyconfig.plist? To explore what that would mean in a bit more detail, it would mean:
(a) all keyboard configurations would revert to default
(b) any OXP that published a custom config would stop working
(c) any custom key configurations you might have applied to your own setup would stop working.
(d) any tool that was designed to create a custom keyconfig.plist would not have any relevance for the new version

I'm not sure if full backwards compatibility is achievable at the moment - still too early in the dev cycle. I guess I'm looking for indications on how hard I should be trying to get there. If there is an overall desire to improve the keyboard customisations, then a small amount of short-term pain in re-implementing a more comprehensive solution might be OK. But if there has been a lot of investment into custom layouts that players don't want to leave behind, it may be worth adding it into the development process.

[Cholmondely]

I've been looking through the source code, assessing how to potentially make all the changes, and I wanted to get an opinion from the broader community. Would you be put off by losing backwards compatibility with the current keyconfig.plist? To explore what that would mean in a bit more detail, it would mean:
(a) all keyboard configurations would revert to default
(b) any OXP that published a custom config would stop working
(c) any custom key configurations you might have applied to your own setup would stop working.
(d) any tool that was designed to create a custom keyconfig.plist would not have any relevance for the new version

I'm not sure if full backwards compatibility is achievable at the moment - still too early in the dev cycle. I guess I'm looking for indications on how hard I should be trying to get there. If there is an overall desire to improve the keyboard customisations, then a small amount of short-term pain in re-implementing a more comprehensive solution might be OK. But if there has been a lot of investment into custom layouts that players don't want to leave behind, it may be worth adding it into the development process.

No problems with it. And if it helps those using non-QWERTY keyboards, I am very much for it. More power to your knucklebones!

[tsoj]

I've been looking through the source code, assessing how to potentially make all the changes, and I wanted to get an opinion from the broader community. Would you be put off by losing backwards compatibility with the current keyconfig.plist?

Personally, I don't care for backwards compatibility regarding the keyconfig.plist. There aren't that many keys, so manually translating the old keyconfig.plist into the new in-game configuration wouldn't be much of an issue, especially considering the upsides of an in-game keyconfig.

[Cody]

This sort of stuff makes my dumb pilot's brain hurt.

Another downside of having the in-game config stored in the GNUstepDefaults file...

... is how easily that file autowipes itself. Otherwise, I have no problems.

[phkb]

Here's another thing to mull over.

What do you think makes more sense from the end-user perspective? The goal with the settings below is to read a capital X.This:

Code: Select all

    key_my_setting = ({
        key = "X";
    });

or this:

Code: Select all

    key_my_setting = ({
        key = "x";
        shift = true;
    });

Or should it handle both?
Actually, on reflection, the first one makes more sense, I think.

[hiran]

Here's another thing to mull over.

What do you think makes more sense from the end-user perspective? The goal with the settings below is to read a capital X.This:

Code: Select all

    key_my_setting = ({
        key = "X";
    });

or this:

Code: Select all

    key_my_setting = ({
        key = "x";
        shift = true;
    });

Or should it handle both?
Actually, on reflection, the first one makes more sense, I think.

Maybe I have been exposed too much to keyboard handling in my past.
It seems to me the first example takes the character that the keyboard driver will emit for a keypress (cooked) while the second one will evaluate the key combination pressed itself without the driver (raw). I can handle either one concept, but if you mix them then I get confused whether I need to enter raw or cooked information.

There is another difference, and that should be even of more impact: If you want to allow pressing keys while flying the ship, you are probably better off with the raw make and break codes of the keyboard, alternatively the raw data that is available to Oolite. Do not rely that the keyboard driver would get all the combinations the way we want them. A barrel roll requires me to press two keys already, and if I want to fire a missile or the laser during that I believe the keyboard driver would go nuts and not emit any character, which could void the cooked mode approach.

So my approach would be to eliminate the key='x' and key='X' completely and simply go by keycode=74, shift=true, leftCtrl=false, ...
https://en.wikipedia.org/wiki/ISO/IEC_9 ... rence_grid

[phkb]

So my approach would be to eliminate the key='x' and key='X' completely and simply go by keycode=74, shift=true, leftCtrl=false

If that were the only style catered for, I think a normal player (without your experience with keyboard handling) would be rather put off by having to find the correct code for every entry. And we'd be adding explanatory comment lines to every entry explaining what the keycode translates to.

I think instead the goal I will aim for is to allow for either - if you want to use the character, put that in. If you want to use a keycode, put that in. At the moment, with the current keyconfig.plist file, that's what's happening internally anyway - characters are being replaced with the integer keycode value equivalent. One feature I'm planning on trying to implement is to allow for descriptive key names for special function keys, like "arrowLeft", "pageUp", "f3", "esc", that sort of thing, so that you don't have to have a keycode reference sheet handy any time you want to play around with your keyboard layout.

As for the leftCtrl/rightCtrl idea, what follows is a bit technical and relates to my current read of the source code (so I'm prepared to be told I have no clue about what I'm talking about!). There are two files in the core code that deal with keyboard handling. "src\SDL\MyOpenGLView.m" and "src\Cocoa\MyOpenGLView.m". I think the "Cocoa" is a Mac-specific one, while the "SDL" version applies to Windows and Linux. In the "SDL" version, I can see some simple changes could be made to allow for the different versions of Ctrl and Alt to be visible to the rest of the game code.

But in the "Cocoa" version, there isn't a clear-cut distinction between the different sides. There is, instead, this:

Code: Select all

/* Capture shift, ctrl, opt and command press & release */
- (void)flagsChanged:(NSEvent *)theEvent
{
	NSUInteger flags = [theEvent modifierFlags];
	opt = (flags & NSAlternateKeyMask) ? YES : NO;
	ctrl = (flags & NSControlKeyMask) ? YES : NO;
	command = (flags & NSCommandKeyMask) ? YES : NO;
	shift = ( flags & NSShiftKeyMask ) ? YES : NO;
	if ([theEvent keyCode] == 0x39) // 57 = key code for caps lock
	{
		capsLockOn = (flags & NSAlphaShiftKeyMask) ? YES : NO;
	}
}

"opt", "ctrl" and "command" are keyboard-side agnostic. And my quick scan of the Apple documentation doesn't give me a left/right option (in fact the current modifiers have even been deprecated in newer versions of Obj-C, by the look of it).

Is there a way around this? Probably. But I don't have a Mac, so I can't test any change and I'd be programming in the blind making wholesale changes to Mac-specific code.

So, given this code change is already going to be a stretch goal for me, I'm thinking I'll leave the left/right variations for a later date. I'll just try to make sure I leave room in my implementation for future changes that won't break what is there already.

[hiran]

So my approach would be to eliminate the key='x' and key='X' completely and simply go by keycode=74, shift=true, leftCtrl=false

If that were the only style catered for, I think a normal player (without your experience with keyboard handling) would be rather put off by having to find the correct code for every entry. And we'd be adding explanatory comment lines to every entry explaining what the keycode translates to.

Huh? We are talking about internal Oolite data storage format, since the aim is for users to configure keyboard settings via the UI. That means the user would never search for keycodes - instead he would be asked to press the desired combination...??

I think instead the goal I will aim for is to allow for either - if you want to use the character, put that in. If you want to use a keycode, put that in. At the moment, with the current keyconfig.plist file, that's what's happening internally anyway - characters are being replaced with the integer keycode value equivalent. One feature I'm planning on trying to implement is to allow for descriptive key names for special function keys, like "arrowLeft", "pageUp", "f3", "esc", that sort of thing, so that you don't have to have a keycode reference sheet handy any time you want to play around with your keyboard layout.

Oh wow. That mechanism makes me suspicious. What if there is no direct key for that character?

Example 1: the at-character: @
On US keyboard that is Shift-2, on German keyboards that is RightALT+q.

Example 1: the LEFT SQUARE BRACKET-character: [
On US keyboard that is a plain [, on German keyboards that is RightALT+8.

How does that get into the keyconfig.plist today and how is it treated by Oolite? On what key combination would Oolite then fire the functionality?

[phkb]

We are talking about internal Oolite data storage format, since the aim is for users to configure keyboard settings via the UI

Ultimately, yes. But first I'm essentially doing a re-write of plist file to allow for more customisations and finer controls. This new file will work the same as any other plist file, in that it can be edited by the user, and customised via OXP. When we get to the UI stage, this will override the content from the plist file (at least, that's my current thinking), but the plist file will remain unchanged.

How does that get into the keyconfig.plist today and how is it treated by Oolite? On what key combination would Oolite then fire the functionality?

At the moment, using the "@" keycode as the example, Oolite doesn't care what physical keypress the user performs to generate that character code. If they can generate the "@" symbol, Oolite will record the hit.

[hiran]

How does that get into the keyconfig.plist today and how is it treated by Oolite? On what key combination would Oolite then fire the functionality?

At the moment, using the "@" keycode as the example, Oolite doesn't care what physical keypress the user performs to generate that character code. If they can generate the "@" symbol, Oolite will record the hit.

If they can generate...

This may require to release all other keys for that moment. You cannot tell otherwise without testing all the keyboard drivers that are inbetween.
Probably you know better than me what that may mean to the gameplay.

If it has been ok up to now I won't mind, but meanwhile I understand better and better why I did not want to touch the keyboard configuration even if that means I am not able to fully master the game.

[phkb]

A small progress update. I have a new key config file defined and it's loading into the game successfully. I've also (just now) got one of the keys working successfully with the new validation routine, which (fingers-crossed) means I can potentially start switching all the keys across to the new routine.

But the next thing I need to do is work out some benchmarking. All the previous keyboard checks were a simple "is this keycode currently being pressed" type of thing. I've now got a routine that has a loop, extraction of an object from an array, and possibly as many as 7 checks (ie "if" statements). That could potentially add a lot of overhead to the keyboard polling routines and slow things down significantly. So before I go too much further I need to know how much baggage I've just added to the process, and then find ways to toss bags off the bus but still achieve the same result.

[Cholmondely]

A small progress update. I have a new key config file defined and it's loading into the game successfully. I've also (just now) got one of the keys working successfully with the new validation routine, which (fingers-crossed) means I can potentially start switching all the keys across to the new routine.

But the next thing I need to do is work out some benchmarking. All the previous keyboard checks were a simple "is this keycode currently being pressed" type of thing. I've now got a routine that has a loop, extraction of an object from an array, and possibly as many as 7 checks (ie "if" statements). That could potentially add a lot of overhead to the keyboard polling routines and slow things down significantly. So before I go too much further I need to know how much baggage I've just added to the process, and then find ways to toss bags off the bus but still achieve the same result.

Interesting! How long has it taken you so far?

I presume that even if all your work makes things just a little too slow for computers right now, that for the computers in 10 years time it might be a different story....

By the way... that conversation gave me the nuggets of information needed to sort out Galactic Navy for the AppleMac. I'd never have managed to fix it all by myself otherwise. Thank you!

[phkb]

How long has it taken you so far?

About 2 days.