Oolite Bulletins

another_commander wrote: ↑Mon Aug 16, 2021 7:39 am

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.

In fact I am not.

Progress:






I now have a new screen that lists all the keyboard settings and what key is assigned. The above screen shots capture the current full list of keyboard settings, and in the current order I have them - hopefully they're large enough to read! Sub-headings was a bridge too far for me, so I've made the description column sufficiently wide enough to have prefixes included. I've still tried to follow Cholmondely's suggested order/grouping from his joystick improvements suggestion, but let me know if you think the order should be tweaked at all.

You'll notice the "Overrides" column on the screens - this will be either a simple "*" or a "Yes" to indicate that the default setting has been overridden, so it's reasonably straight forward to tell which keys you've changed in-game, and which are coming from the config file.

At the moment, all this screen does is list the description and the assignment. You can't change anything yet. But given the difficulty I've had working out the GUI code and getting everything to work, this felt like a success worth sharing.

Next up - storing and retrieving the overrides from the GNUstepDefaults file.

Wonderful!

I take my hat off to you, Sir! A veritable tour-de-force.

Minor issue: Too many key-commands

I had a discussion with a_c_ quite some time ago now about introducing more key-commands into Oolite for Fast Activation of oxps. He was against new key-commands. The principal reason from what I could make out was that there are already too many such in Oolite. So, yes, I've been posting about the greater number of key-commands for driving cars & flying planes.

But a_c_ does have an important point. We want other people to join us. If we make the skill barrier too high, it won't happen. How many different things do people have to learn before they can start enjoying Oolite? How much time will they need to spend doing so?

My wish to rewrite the OoliteRS (defeated by the difficulties of manipulating OpenOffice) came from a_c_'s comments - to split up the key commands between
(1) the vanilla game,
(2) the extra equipment (ECM's, Fuel Injectors, Docking Computers, ASC etc)
and (3) the extra extra (OXP) equipment (Priming buttons, fast activation buttons & MFD buttons).

Unlike a_c_ I feel that more new buttons in the third category is fine - by this stage our newcomers have already worked out that they like the game, and will want to manage what is now an added complexity. Especially more Fast Activation buttons - one only defines as many as one wants/needs.

a_c_ did make the point to me that if more buttons are defined, then more buttons will be used ( a bit like building more roads, which encourages more people to drive more of the time...). Personally, I feel that if stays that way for oxp's only, then fine. We each choose which oxp's we incorporate, nobody forces any of us. I avoided Ship Configuration for an entire year because of its complexity. I will avoid OoCheat because I don't want to. Etc. etc. etc. In the real world we often find that we have two sets of controls together - a basic crude easy to manage set, and a more complex more refined set (think of a radio with preset buttons, or windscreen wipers with one automatic setting and several more manually determined).

So, yes, I fully support your idea of splitting the views between all the various key-commands. BUT our older version was much easier to learn, even if it was less precise.

I know, myself, that I get the half-dozen missile buttons mixed up. If I plug in my Elgato button box, it's fine - each button is clearly labelled, and in a combat I can clearly see what each one does. (Ditto with Clym Angus's overlays). But without, I won't remember.

Similarly (for example) for the new views, I suspect.

Would it be an idea to consider keeping the lengthy but simple toggle for the views too? Then people can start off with that, and if they then use the views enough and learn the 8 new key commands, fine. but if not, they can still access the external views easily.

Of course, if this is eventually added to the Joystick Configuration, an 8-way "hat" will solve the issue very simply indeed...

References:
Keyboard Issues (wiki)
My rant about cars and airplanes

6 pink missile buttons on buttonbox's Combat setting:


Clym's overlays:

Cholmondely wrote: ↑Fri Aug 20, 2021 3:09 am

Minor issue: Too many key-commands

Can't argue with that. But the goal of this particular project is not to reduce the number of key-commands, but to give complete access to all of them. A lot of the commands were hard-coded - this WIP exposes everything so that the player can (if they want) change the lot.

That said - the current keyboard layout document should still apply. I'm not changing anything in the game. There will be the same number of key-commands afterwards as there were before. None of the key sequences are changing.

Ultimately, the keyboard is a poor interface for ship flight control. A full HOTAS joystick setup is the best arrangement, so muscle memory can play a greater role in flight.

Cholmondely wrote: ↑Fri Aug 20, 2021 3:09 am

Similarly (for example) for the new views, I suspect.

The key commands for the external views are in the game now. All I'm doing is exposing all the keys used to access them and allowing you to change them. (Note: after switching to the external view, you need to press "Caps-Lock" to engage the freeview camera. That's one keypress I'm less confident in swapping out, as it's one of a very limited number of keys that has a constant state. Once I'm through the initial dev process, I might revisit this one).

Cholmondely wrote: ↑Fri Aug 20, 2021 3:09 am

Unlike a_c_ I feel that more new buttons in the third category is fine - by this stage our newcomers have already worked out that they like the game, and will want to manage what is now an added complexity. Especially more Fast Activation buttons - one only defines as many as one wants/needs.

I have a plan for giving players the ability to assign as many keys to primable equpment as they want. I'll share more when I've gotten closer to the end of this phase.

phkb wrote: ↑Fri Aug 20, 2021 4:15 am

I have a plan for giving players the ability to assign as many keys to primable equpment as they want. I'll share more when I've gotten closer to the end of this phase.

Good! By the way, the one relevant comment that I stumbled across was Norby's note at the bottom here:

Telescope.oxp wiki page

Keypress functions

The ident button ("r") is given a new feature by Telescope: it can lock onto the most centered target even when it's not shown on the screen!

The next "r" press will start auto steering to the target if the most centered target is the same target, otherwise it will lock onto the new target; a third "r" press will unlock it.

In Red Alert it will not narrow the locking to the attackers; it can still lock any "target".

Works only if there was a locked target beforehand, due to the triggering of the shipTargetLost event, so if there's no target it won't get called. Press "r" again or get something into the crosshair or use equipment buttons to lock a target. (Usually only an issue when leaving a station, exiting witchspace or Torus drive.)

If you turn off the weapons with the underscore button ("_") then a scan happens and you enter into "Navigation Mode", where autolock helps you to see through targets (called Panorama targeting): continually relocking to the most centered target.

This "_" button should be chosen to avoid unwanted fire if you have turrets.

In Red Alert you can lock any target and see distant targets if you turn this mode on.

The Ident "r" button presses can turn Panorama targeting on and off when in Navigation Mode.


With the Telescope primed (Shift+N), the mode button ("b") cycles through the functions of the activate ("n") button:

Commands:
Nearest target
Rescan
Step forward in the target list
Step back in the target list
Functions:
Lightballs: off / navigation only / ships / masslock borders / large
Sniper ring km: off / 5-25.6 / 10-25.6 / 15-25.6 / 5-30 / 10-30 / 15-30
Steering: off / nearest target only / both nearest and step in the list
Targets: 20 and limitation in red alert / 50 / 100 / 200
Visual target: off / weapons off / no ring / no station / no question mark / all
Visual target size: 1-8


The first 4 functions are actually commands which happen instantly when activated. The "Step forward" and "Step back" will rescan if you step over the end of the target list only. The Target list contains hostiles first (if any), then all ships in normal scanner range (25.6km), followed by Cargo & Escape Pods, and finally ending with ships which are beyond the normal scanner range.

The last 6 functions are some of customizable properties in the telescope.js file, which you can change during flight. Your settings are stored into missionVariables and saved when you save your game after docking. The 20-200 telescope items is an internal list to work with, for example to show lightballs over ships in space or step through the target list with mode and activate buttons.
If the core game ever provides more equipment buttons, a back button could step back to the previous function (maybe Ctrl+"b"). With a second equipment button (maybe Ctrl+"n") the settings list could be separated from the commands list.

Reference: http://wiki.alioth.net/index.php/Telescope

phkb wrote: ↑Fri Aug 20, 2021 1:56 am

Bottom right (8th of 9 screens):

Might

External Views toggle - v

make more sense (for the first line only)?

The issue I see with telescope is not necessarily a lack of available keys, but more that there are too many functions trying to be squeezed into one control point (ie one piece of primable equipment).

Cholmondely wrote: ↑Fri Aug 20, 2021 8:13 am

Might
External Views toggle - v
make more sense (for the first line only)?

Sure.

phkb wrote: ↑Fri Aug 20, 2021 8:14 am

External Views toggle

More thoughts: this isn't a toggle, though. You press "v" to switch to the first external view, then each subsequent press switches to the next external view, and keeps switching ad-infinitum. You get back to a normal view by pressing "1" or "F1". So it's not really a toggle, more of a cycle. So would "Cycle external views" be clearer, do you think?

Short answer: yes!

phkb wrote: ↑Sat Aug 21, 2021 2:05 am

... would "Cycle external views" be clearer, do you think?

Cody wrote: ↑Sat Aug 21, 2021 8:40 am

Short answer: yes!

I refer the honourable gentleman to the answer submitted immediately above....

Progress: I now have the basic functionality of the keyboard config working, in that you can enter and update keys to your hearts content. I’ve got a lot of UI tweaking to get through now, but I feel like the end is in sight. I’ll post some screen shots tomorrow of how it works so far.
Next up: validations.

Here we go - screenshots!

Here's the new keyboard config screen, showing the first page of keys, and the second item selected, "Options screen".


Here I've entered the configuration for the "Options screen". Both keys (2 and F2) are shown.


Here I've selected the "2" key code and now have the option to enter something else. Hope I pick the right key...


Oops! Looks like I've got a conflict. I've accidentally selected "3", which conflicts with the "Equip ship screen" key.


Back on the main list, all the keys in a conflict state are highlighted orange to make it clear that there are issues to be addressed.


So, all that is working. Here's a question, though. If a conflict is detected, should you be allowed to exit the configuration screen? Or should it force you to fix things up before allowing you to exit?

Next steps: I'll be doing some testing over the weekend to make sure I haven't broken anything, and tweaking messages, etc. If it all goes well, I'll put out a small package that can be applied to a 1.91 release so others can test it. And for clarity, I can only do a 64bit Windows package at the moment. If I can work out how to do an equivalent in a Linux VM I'll try to do that as well.

Definitely go with the "you can not save the keyboard configuration if there is a conflict" option. Being able to save it with a conflict in place is only going to lead to forum posts about why someone's keyboard is not working properly. Perhaps as a further option leaving the keyboard configuration without saving reverts everything back to the previous save or to the default configuration if you have never saved a configuration.