Keyboard Bindings

[klauss]

I would advice against using one key for each strafe-thruster direction, since then things would get really clumsy. Instead I would suggest a single strafe key, which turns all directional movement into strafe movement. In fact I wouldn't even offer the individual bindings, so the player does not have to make tradeoffs between ergonomy and functionality (not being able to strafe while turning can be considered a disadvantage when it's theoretically possible).

I don't remember the default bindings... but that's in there already. It not only works with keys, also with the joystick, turning it into Apollo-ish controls (quite hard to master, but really fun). Perhaps the bindings need some work, though.

[Silverain]

OK, returning to some old work after being away, re-reading the thread, wiki-work etc.

One thing I never got my head around, was the saying that VS maps keys 1:1. Does this mean:

Standard US Qwerty keyboard, the q key is third row down (Esc, `~, Tab), two keys in (Tab, q). So VS records that location, not that the key is q. So, on a Zwerty keyboard, the key that should be used is z, being three down, two in? So if I map a function to q, on a zwerty keyboard it is actually mapped to z? This would help explain international problems, in that the 'odder' keys located simply on a US keyboard, are in different places on a non US (german, french etc) keyboard. It would be a point of simply changing the keybindings - ; is four down, three left, so on a non_US replace ; with whatever default key is there.

Am I right with this? I have read all sorts of answers in different threads over time.

If I'm wrong, and VS is picking up the key, irrespective of where it is located i.e. I press q, it records q whether my keyboard is Qwerty (3 down, two in), or Zwerty (5 down, 2 in), then there should not be as many problems.

Related thought. Currently, "Shift" is not marked as a modifier like "Ctrl" and "Alt" are. Would it be possible to de-couple it and make "Shift" a modifier? If so, would it even be worthwhile? If mapping is key location (first point above), it may be better to do this, as it frees up non-US keyboards to map their keys with Shift, rather than be limited to the static key bindings with Shift (which are US keyboard centric, and seem to be the major cause of international problems).

[Silverain]

Following on,

It isn't hard (just time consuming) to create several keybinding variations (Language variations, left/right handed, notebook etc), but we do need a "Standard" keybinding setup that is the "default". This default is then used for the Manual, initial setup etc.

One of our "problems" is agreeing to a default setup. The common usage for most games (that I see anyway), is a typical US keyboard, right handed setup.

I suppose I'm seeking a consensus on which to build a "default" keyboard, something like this:

US keyboard layout
Right handed player
Using mouse in right hand
Left Hand resting on asdf

With this as my base, I'm then looking for agreement on the following:
- Redesigning key use completely for easiest access of most used keys in that configuration - this was my original proposal, but from latter comments was not well received.
- Or, keeping close to current setup, where many keys have a "legacy" of associated use e.g. m for map, t for target etc. The advantage is many remain familiar with this usage, the disadvantage is that many keys have to be hunted across the keyboard with the left hand.

So, I'm looking for consensus on this point as well.

Having such a "default" Standard is (I believe) necessary. Of course, players can (will and do) modify the Standard to suit their particular tastes. Whether they edit the config file, drop in a new and complete set of bindings off the wiki, or (eventually) can change keys while ingame, there still needs to be a starting set.

[Silverain]

Once I(We) have our Standard set, how do we record this? Currently, we have the one set of keybindings in the config file - basically, the Standard.

Do we keep it this way? Leave only one set of keybindings in the config file?

Or:

Create multiple sets of keybindings in the config file? Set one is Standard, sets for each language, notebook set, left and right set, and combinations thereof?

This can be done, and create a new setting in setup to select which keybinding option to choose. The problem? The more variant sets in the file, the more bloated the file. But it can be done with the existing VS design.

Option 1 - (that would require a bit of coding work), is to extract the keybindings from the current config file, and have a new config file "keyboard.config". Takes all the variant sets and locates in a fresh file. Setup and loading obviously would need to read the keybindings from this file, rather than vegastrike.config, but otherwise no change.

Option 2 - I remember reading a suggestion, that instead of such a master file (vegastrike.config, keyboard.config), we instead use multiple files that are stored. E.g. keyboard.standard.right.config, keyboard.standard.left.config, keyboard.german.right.config, keyboard.notebook.standard.right.config etc. Setup selects which keyboard config we want, and imports that particular config - either directly on loadup into the game, or imports into the head vegastrike.config file. Designed a new keyboard configuration? Drop it into the folder, and select it, download and save other's configs etc.

Again, a consensus here would be good. Just go with a standard design (on whatever basis)? Come up with several subsets in vegastrike.config? Multiple sets (here I would need someone to do the coding to make it work)?

Lastly, more directed at Klauss, with the port to Ogre, how would that change keyboard configuring? I would believe we still need a "default" configuration, but what else would change?

[Silverain]

Going through some old PMs, and came across this from chuck_starchaser:

... I honestly think we could use two-key sequences: a menu opens up for the first key, such as for autopilot modes when you press A, for communications when you press C, for targeting commands under T, etceteras...

T-> F for Friendlies
T-> H for Hostiles
T-> J for Jump-points
T-> P for Planets
T-> S for Space Stations

C-> F for Friendly message (greet)
C-> H for Hostile message (insult)
C-> Q for Query
C-> A for Answering a query
C-> O for Offer credits in exchange for help with current mission

A-> T for autopilot to Target
A-> M for autopilot to mission destination
A-> J for autopilot to the next jumpoint in the mission route
A-> H = autopilot to Hostile target (auto to a safe distance)
A-> S = autopilot in Stealth mode (same as above but stay out of radar range)
A-> L = auto-Land (on planet)
A-> D = auto-Dock to ship or station

.... and so on. Then the complexity of the game can really grow unimpeded by the scarcity of bindings. And two keystroke sequences are really easy to learn, in my experience; wouldn't need to look at the menu for long.

Its certainly a viable idea. Expands the effective number of keybindings, since a key has multiple uses depending on whether it is primary key (to open a menu, or activate function under menu a, different function under menu b etc). Would require recoding to implement, but if warranted, I could come up with design doc and work with it...

EDIT: could be a way to get around the internationalisation problems too...