In-game keyboard configuration

[phkb]

Another question, less technical this time:

For the current tutorial, there are times when it says things like:

The '4' or 'F4' key meanwhile gives access to a range of ship and station systems...

The "4" in that quote is being picked up from the current key definition. The "F4", however, isn't. It's hard-coded into the mission text.

In my current implementation, I have it looking like this:

The '4 / F4' key meanwhile gives access to a range of ship and station systems...

So, my question, is this adequate and, perhaps more critically, understandable? I can change the "/" to "or" easily enough. What do you think?

[Cody]

I think "or" works better - but I ain't had morning coffee yet!

[Cholmondely]

I think "or" works better - but I ain't had morning coffee yet!

I refer the honourable gentlemen to the sentiment expressed immediately above, both parts of it!

[Cody]

I refer the honourable gentleman to my now half-empty coffee pot!

[phkb]

OK, I think my shake-down tests have uncovered most of the obvious bugs. I think I'm ready for some other testers.

Here's a link (oolite_keyconfig.zip) to a ZIP that contains the following:
1. oolite.exe - a 64bit version of Oolite 1.91
2. descriptions.plist
3. keyconfig2.plist
4. missiontext.plist
5. verifyOXP.plist

You need to have a copy of the latest Trunk available to make this work. Rename the current exe file (to, say, "oolite.exe.bak"), then drop the new exe into the folder. Do the same with the plist files in the "Config" folder. And then...fingers crossed...keyboard configuration should be available from the front menu, and also during play (docked and when paused in flight). Mouse control should work as well.

This is extremely experimental, so don't be surprised if things go pear-shaped. But there are a couple of things I'd like to get tested.
1. Performance. Do you notice any lag or delay when pressing keys, particular during large battles, etc.
2. Flexibility. Can you enter and use all the keys on your keyboard, including Ctrl/Alt variations? Particular important if you're using a non-QWERTY US/UK keyboard).
3. Accuracy. Are conflicts being correctly identified? Is everything getting saved/restored successfully?
4. Clarity. Did you find anything confusing to use or understand? Did something happen you didn't expect, or something not work in the way you expected?

Let me know what you find. If a Linux or Mac person who can build from source wants to give this a try, the new_keyconfig branch has my latest check-in, so you could try building it yourself. I'd be very interested to hear the results.

[another_commander]

Great work! I run a brief test, without stretching it too much and so far it seems to work pretty well. Two observations only:

Using an Italian keyboard here and I cannot enter any special Italian characters. For example, "ù", which on an Italian keyboard is at the location of "\" in the US one, does not get recognized when the language (I refer to the language indicator at the tray, bottom right) is switched to Italian. It is recognized (as "\") when the language is swithed to English.

Also, I got a bit confused with keys like "C" for fast docking. The keyconfig screen gives this as key "C", with all modifiers set to off. But, in order to get "C", you need to have shift down, so the fact that the Shift modifier was shown as off thew my a bit off-course. Should an entry like "C", or "L" (for docking clearance) be shown as "c" or "l" respectively, with Shfit modifier inidcated as being on? Not sure if that's the best way, it's just a suggestion.

Overall, great stuff, though. Well done and complments for taming the Lovecraftian beast that the GUI code is.

[phkb]

Using an Italian keyboard here and I cannot enter any special Italian characters

I was afraid of that. I suspect I’m going to need to expand the MyOpenGLView properties *shivers*

Also, I got a bit confused with keys like "C" for fast docking. The keyconfig screen gives this as key "C", with all modifiers set to off. But, in order to get "C", you need to have shift down

I was uncertain about that scenario. I could force all uppercase characters to lowercase and automatically switch the shift flag on. Or I could prevent uppercase characters from being entered, which would force the user to turn on the shift flag. I’m a touch nervous about playing in that space for what might happen to international characters.

taming the Lovecraftian beast that the GUI code is

Its certainly *ahem* interesting!

[Cholmondely]

What about a set of oxp's for Italian, German, French etc keyboards?

The cognoscenti can take and twiddle with them to their hearts delight, and those without the skills get something more suited to their keyboards?

Would that help the situation? Or do you still need to fiddle with the MyOpenGLView?

[phkb]

Would that help the situation? Or do you still need to fiddle with the MyOpenGLView?

It might only help if the player doesn’t want to go into the configuration screen and make any changes themselves. As soon as they do and want to enter a special character, they’ll hit a wall.

It’s not so bad really. I’m sure the twitches will subside over time!

[Cholmondely]

It’s not so bad really. I’m sure the twitches will subside over time!

You are a brave man, sir! We'll put your name forwards for the Naval Gold Medal.

[phkb]

The keyconfig screen gives this as key "C", with all modifiers set to off. But, in order to get "C", you need to have shift down, so the fact that the Shift modifier was shown as off thew my a bit off-course.

After a night of reflection (I fell asleep on a mirror! Ha! *ahem* Anyway...), I think a better approach would be to hide the shift modifier entirely if we detect that an uppercase character has been entered. I'll leave this issue for a little bit while I work on the special character issue to give others a chance to add their thoughts.

Quick question, though. Can you enter special characters via a mission screen with the text entry option on?

[phkb]

We'll put your name forwards for the Naval Gold Medal.

Well, in that case...

[Cody]

Well, in that case...

<chuckles>

[phkb]

Okay, I've just checked in an update that should fix the special characters issue. You should be able to enter them, see them on the screen, and then pressing them should activate whatever the assigned function is. I can't guarantee I haven't broken lots of other things, though. I've made some pretty wholesale changes to the handling of KEYDOWN and KEYUP, I'm almost certain to have tripped up somewhere.

In my tests, I assigned a function to "#". On my normal US-style keyboard, this is Shift-3. I then switched to a UK keyboard which puts the "#" key on its own above the enter key and the function follows the "#" key to the new location on the keyboard. I also tryed switching to a German keyboard that has "ß", "ö" and "ä" and I was able to enter them all and the functions assigned triggered as expected.

On the plus side, Print Screen and Pause are now available to be used on a Windows/Linux machine. Sorry, Mac people - apparently you generally don't have those keys (unless you're using a PC-style of keyboard). At least, that's what my research told me.

I haven't addressed the confusing "no shift for Capital letter" issue yet. Next time.

[phkb]

If this works, and is stable, there might not be any need for the option of entering a 3-digit code. Possibly. Maybe.