Oolite Bulletins

Progress is happening. But here's a conundrum I've stumbled across.

At the moment, all the function keys (F1-F8) are hard coded. Even if you change the "key_gui_screen_status" setting in keyconfig.plist, F5 will still take you there.

That might not seem that important on the surface, but it becomes important on screens that allow for data entry (like the save commander screen). On those screens, the default keys for switching screens (ie 1-8) won't work, because you might need to type some numbers in. But the function keys will work. You can switch to another GUI screen even if you haven't finished typing in the name of your commander on the save game screen.

Again, that might not seem too important, but it could become more important when users have the ability to set their own keys in the game itself. The default config will have both "1" and "F1" (and all the other equivalents), but an end user might decide they want to remap all the function keys to do something else. What that would mean is that the user won't be able to switch screens until they complete whatever it is they're doing (by pressing enter) or cancelling it (by pressing esc). So, not game breaking, but a definite change in the way the game works.

I don't have an answer for this yet, and I'm leaning towards the answer being "That's the price of having fully configurable keyboard settings in game." But I'm putting it out there in the interest of full disclosure.

For anyone interested, I've created a code branch for my work on this feature. You can find it here: https://github.com/OoliteProject/oolite/tree/new_keyconfig.

There's a lot of interim and duplicated code in there, as it's still very much a WIP, but I thought it best to get the current code uploaded so others can comment on what's been achieved so far.

What has been achieved so far?
- New "keyconfig2.plist" file
- Keys should use the new mapping system
- Lots of missing keys have been added, and a couple of names have been changed for consistency.

I think I've found every hard-coded instance in the game. Some I've decided to stay away from. For instance, holding control to get fine control over movement. I'll review that as we move forward.

As for builds with this code, I can only do a Windows build right now (let me know if you're interested and I'll post a zip file somewhere). And we have a problem with our automatic build system on GitHub, which I'm also trying to get a solution for (it wouldn't help for this anyway, but will be important for getting new test releases on all systems).

And I should point out, for any Obj-C programmers out there, that I am not a native Obj-C coder. So feel free to point out any mistakes (and I'm sure there are tons) so I can improve.

I think this is valuable and have no wish to derail the project. The more of Oolite which is "modd-able", the greater the ability of people to come up with valuable and interesting adaptations.

Just to say, if all this proves problematic for whatever reason (computers too slow...), there is a simplistic solution:

Just (1) provide OXPs (Miscellaneous oxp's?) in the Expansions Manager for QWERTZ & AZERTY (and possibly JCUGEN & ABJAD too)

and (2) update Keyconfig with the new key-commands (possibly with instructions in German, French, Russian, Spanish & Italian...).

I'm getting closer to the pointy end of the coding work for this update (ie, creating a screen and UI to handle keyconfig config changes). I thought I'd put some mocked-up screens together to get some early feedback on my ideas so far.

Here's what I'm thinking. First, you'd access the keyboard configuration screen from the Options page, taking the place of the current "View keyboard configuration" option on that menu. That would take you to something like this:



(Edit: I might make that descriptive line read "Select the function you wish to change the key binding for", which I think reads a bit better).

Here we see the first page of the list of keyboard controls, including headers for grouping similar controls together. On the left side is the name of the control, while on the right is the current key assigned (or keys, in the case of some of the functions).

Selecting one of the entries (in this case, the highlighted "Launch ship" item, takes you to a screen like this:



Here you can change the key assigned to the function, and add alternate keys if you want. You can also turn on/off the shift/control/alt options for the key (for Mac users, the "Alt" will be changed to "Command").

I'm thinking of limited the number of alternate keys you create to 2 (ie 1 base key plus 2 alternative keys), purely to keep the screen from needing to scroll/page. If you want to have more than 3 different keys, you can always do it manually via the keyconfig2.plist file.
(Edit: I'll probably need a "Remove alternate key" function as well)

Thoughts? Does this cover 99% of use-cases you can think off?

In addition to this, there will be some form of error checking as well: if you try to assign the same key to two functions, a warning will be displayed. At the moment, I'm think it will just be a warning, rather than preventing the user from making the change, but I'm open to suggestions.

This error checking will have some smarts to it, in that some keys are only active in certain circumstances (eg while docked, when paused, etc), so the checking process will know where potential conflicts could occur.

Picking my jaw up
off of the floor in stunned
silence; Amazing.

Looking good!

phkb wrote: ↑Sat Aug 14, 2021 5:22 am

In addition to this, there will be some form of error checking as well: if you try to assign the same key to two functions, a warning will be displayed. At the moment, I'm think it will just be a warning, rather than preventing the user from making the change, but I'm open to suggestions.

This error checking will have some smarts to it, in that some keys are only active in certain circumstances (eg while docked, when paused, etc), so the checking process will know where potential conflicts could occur.

What you posted is looking good to me.

Regarding the warning: If you only display that the user may still have invalid or unusable configuration - and cleaning up may be even worse for the innocent.
I know that other games will assign the key to the function the user chooses, and if that key was already assigned it will automatically be removed from the other function. Somehow I believe unassigning from other function + a warning would help best.

Nice and clear: lovely!

phkb wrote: ↑Sat Aug 14, 2021 5:14 am

Thoughts? Does this cover 99% of use-cases you can think of?

This looks all very nice to me.
One question I have: Will it also be possible to just press some key and let it automatically assign the right key-code? For example, I might not know the (internal) key-code for right/left/up/down arrows or another special keys (like ö,ä,ü,ß).

tsoj wrote: ↑Sun Aug 15, 2021 12:56 am

Will it also be possible to just press some key and let it automatically assign the right key-code?

That’s a good point. What happens if you press a key Oolite can’t display because it falls outside its current character set. Hopefully I’ll be able to achieve a scenario where, if the entered keypress can’t be displayed, the code will be displayed instead. Thanks for the reminder.

tsoj wrote: ↑Sun Aug 15, 2021 12:56 am

For example, I might not know the (internal) key-code for right/left/up/down arrows or another special keys (like ö,ä,ü,ß).

For the arrow keys, I'm going to allow you to enter "arrowLeft" or "arrowRight", so you don't have to remember those codes.

For special keys, if they're visible on the oolite-font.png file, and you can press a key (or keys) on your keyboard to display it, you won't need to remember codes. For special keys that aren't on the oolite-font.png file you're using, that's where we get into uncharted territory. We might end up needing to put some test releases out that can collect some data before a final solution is in place.

I wonder whether Oolite is the only game with keyboard layout challenges...
https://gamedev.stackexchange.com/quest ... rd-layouts

hiran wrote:

I wonder whether Oolite is the only game with keyboard layout challenges...

It isn't. You would be surprised to know how many applications face issues of such kind.