Oolite Bulletins

It would be really good if function keys could be assigned to primable equipment, so that piece of equipment could be instantly primed with one keypress, without having to cycle through all the primable items.

would be very nice indeed, but function keys already have a binding in the core code, and i think there are keyboards (laptops) that lack function keys.

Maybe using Shift + Numberkey for equipment would work.

How would oxps find out which keycombo is assigned to them ?
If oxps are able to request a keycombo , how would clashes be prevented ?

A connection somehow with numberkeys would be very handy, including a way to have the player choose his own combo configuration

shift 1 = prime this
shift 2 = prime that

cbr wrote:

A connection somehow with numberkeys would be very handy, including a way to have the player choose his own combo configuration

shift 1 = prime this
shift 2 = prime that

They would have to be player programable, as I already have these assigned to other things. Which is a problem with such suggestions, they have to work for everyone.

We currently have fast activation attack and fast activation defense, assigned to "0" and "tab". If we could use "[", "]", "{" and "}" that would give us four more fast activation slots. "9" is also available, as is "(" and ")" and shift-Tab. That's 8 extra slots, giving us the potential for 10 fast activation slots in total.

My recommendation would be:
fast_affinity_defensive: defaults to "0" (connects to player.ship.fastEquipmentA)
fast_affinity_offensive: defaults to "Tab" (connects to player.ship.fastEquipmentB)
fast_affinity_slot1: defaults to ")" ("shift-0") (would connect to player.ship.fastEquipmentC, new property)
fast_affinity_slot2: defaults to "shift-Tab" (would connect to player.ship.fastEquipmentD, new property)
fast_affinity_slot3: defaults to "9" (would connect to player.ship.fastEquipmentE, new property)
fast_affinity_slot4: defaults to "(" ("shift-9") (would connect to player.ship.fastEquipmentF, new property)
fast_affinity_slot5: defaults to "[" (would connect to player.ship.fastEquipmentG, new property)
fast_affinity_slot6: defaults to "]" (would connect to player.ship.fastEquipmentH, new property)
fast_affinity_slot7: defaults to "{" ("shift-[") (would connect to player.ship.fastEquipmentI, new property)
fast_affinity_slot8: defaults to "}" ("shift-]") (would connect to player.ship.fastEquipmentJ, new property)

We'd also need a redesigned "Set primable equipment" interface screen.

Would that work, do you think?

As someone with a different keyboard layout, this would be unusable, if it isn't player programmable. Just saying.

If we could map the ctrl+key to the mode function then we will not need prime at all.
For example ctrl+0 could be the mode key of the first fast equipment due to key_fastactivate_equipment_a="0" in keyconfig.plist. Using this we must not prime first then press "n" or "b", just press the assigned key for activate and ctrl+key for mode change.

The free keys without shift during fligth are f, o, q, x and 9 which is enough up to 7 fast equipments, but based on previous discussions the core team will not allocate more direct keys for equipments, so I think the shift+numbers has more chance (just shift+8 is allocated for the screenshot key). In this way shift+1 could activate the third fast equipment and ctrl+shift+1 could be the mode key of this eq. The interface screen simply need more lines and keyconfig.plist could be extended like this: The ctrl+ variants will not need new lines due to handled by the core like the current ctrl+ combinations.

Lone_Wolf wrote:

i think there are keyboards (laptops) that lack function keys.

Really? Where? Can you show an example?

Function keys are pretty much essential these days, and all the laptops I've seen make extensive use of them for things like screen/monitor switching, volume and muting, wifi toggling, etc... Most laptops lack numeric pads (though with the newer widescreen styles, more and more have them), but I've never seen a laptop without function keys.

can't give examples, but a few years ago the compnay i worked for got several new models of "multimedia laptops" .
They did have physical keys at the locations function keys are supposed to be.
Default they were assigned to multimedia functions, and the only way to use them as F1 - F12 was to disable the multimedia functionality in bios/uefi firmware.
(No Fn key to swich functionality, and default setting was multimedia functionality of those keys.)

I and my IT colleagues looked into it , and found a purchaser without IT experience had ordered the cheapest variant they could find of the laptops we had ordered.
We returned around 2 dozen shiny new laptops and ordered replacements with proper keyboards.

Wow.. I'm gobsmacked that anyone would even manufacture such a brain-dead device..

Especially when you consider the evolution of the standard PC keyboard, due to the IBM/Microsoft alliance. Microsoft took the IBM Common User Access guidelines on board, and over time, developed standardised uses for all 12 function keys.. And given that pretty much all PCs are designed from the ground up to be used with MS Windows, it's beyond stupid that a manufacturer would abandon the standard.

Thankfully, that kind of abomination seems to be extremely rare. I don't think we ought to be concerned about it.

Diziet Sma wrote:

Wow.. I'm gobsmacked that anyone would even manufacture such a brain-dead device..

Especially when you consider the evolution of the standard PC keyboard, due to the IBM/Microsoft alliance. Microsoft took the IBM Common User Access guidelines on board, and over time, developed standardised uses for all 12 function keys.. And given that pretty much all PCs are designed from the ground up to be used with MS Windows, it's beyond stupid that a manufacturer would abandon the standard.

Thankfully, that kind of abomination seems to be extremely rare. I don't think we ought to be concerned about it.

The ultimate solution would be a fully interactive keyboard mapping setup in the core and the setup screen, including a button to "reset to factory default". That works for everyone, on every platform, on every keyboard. A key press that does not exist on one platform is irrelevant in that case.

It would work by first choosing a command to map, then choosing a key to bind the action to.

Choosing a command to map would include the options "prime <equipment...>", "mode change <eqipment...>", and "activate <equipment...>", where the choice of equipment is a 2nd level menu screen where you get to select from the installed set of equipment. It would require some checks so that if a piece of equipment doesn't exist any more at the time it is reference it's just ignored while in flight.

This would give everybody the option to set up their prime/mode-set/activate to precisely how they like it.

A lesser solution would be just to add the shift-number-keys to the existing allowed activation, but I'd still prefer the option to either prime, change mode, or activate on a per device, per key setup.

Also, there could be a "lock settings" option so that you can't mistakenly change the mode of something you really don't want to change by mistake.

Apple keyboards also have assigned functions for F1 to F12 - you have to switch this off from system preferences to use them normally, and since they cover things like screen brightness, media controls, etc. switching them off would be a nuisance.

And I suspect that most people who play Oolite on other computers use the function keys f1-f8 almost interchangably with number keys 1-8 for views etc.

The numeric keypad is free for use outside of debug builds (IIRC).

Besides that, th game does makes the difference between shifted and non-shifted keys, so there's actually a lot of free keys to bind that are relatively safe ('H', 'V' etc.).

Speaking of that, I would welcome the possibility of un-binding the "Q" which exits the game without confirmation - or even removing entirely if it's not too extreme.

Another remark I'd like to make is that some OXPs use the primables as a mean to configure things, and clutter the list as a result. Sometimes there's also too many modes for a single equipment, and the F4 screen is not safe from becoming cluttered as well.

The root cause, it seems to me, is that there is no simple and standard way to offer configuration options in Oolite. Things have gone, in a way, even worth with OXZ packaging because it's harder to hack files with a text editor.

I'd suggest to create a configuration screen dedicated to OXPs that can be reached in-flight. This should stop the "abuse" of primable equipments and solve the OXP configuration problem. Extra points the screen displays different things when in-flight and when docked, with the idea that "static" settings (e.g. number of extra planets) should not be visible in-flight.

Astrobe wrote:

I'd suggest to create a configuration screen dedicated to OXPs that can be reached in-flight.

Svengali's latest BGS kinda offers that - not in-flight, but when docked. Whether other OXPs will use it is the question.

Cody wrote:

Astrobe wrote:

I'd suggest to create a configuration screen dedicated to OXPs that can be reached in-flight.

Svengali's latest BGS kinda offers that - not in-flight, but when docked. Whether other OXPs will use it is the question.

It's Lib_Config.js in Library and, unlike the old OXPConfig, the script can be used in-flight. It would at least help to declutter the equipment list, so if there's real interest I could add a option.