Mapping keys/buttons to OXP equipment

[phkb]

Rather than continue in the "In-game keyboard configuration" thread, I thought it best to start a new one to discuss this particular topic.

So, now that we have a method for assigning keys to functions in the game itself, we can move on to the next part of this process: how we can assign keys (and joystick buttons) to the activate and mode functions of OXP equipment.

To start, there is a fairly important point to raise. You won't be able to set these keys until you have started a game. You won't be able to set them at the intro screen, because at that point in the games state, no OXP's have been loaded, so we don't know what equipment might be there.

In my view, that's probably OK, but I'd be interested in other takes. When it comes time to attach a key to a function, we can do it globally, and save it to .GNUstepDefaults, so it will persist between different save games. It's just that you can't do it until a game has actually started.

Next, is the issue of visibility. I can loop through all the installed equipment and find the ones that have a script attached. That's relatively easy. However, some equipment items are only awarded in certain circumstances, and it's possible that revealing the name of that piece of equipment might count as a spoiler of sorts.

So, question: should the list of equipment items only be made up of items you actually have installed on your ship? Because it then gets complicated: in game "A" you have bought lots of equipment items, and assigned keys to each one. Then you start a new game, game "B", where you have none of those items. Should the config screen still how the ones you've defined keys for in game "A", even if you don't have them yet, or hide them again? My feeling is that anything you've explicitly defined should be shown, even if you don't have it, but again, I'd be interested in other opinions on this.

[Cholmondely]

Rather than continue in the "In-game keyboard configuration" thread, I thought it best to start a new one to discuss this particular topic.

So, now that we have a method for assigning keys to functions in the game itself, we can move on to the next part of this process: how we can assign keys (and joystick buttons) to the activate and mode functions of OXP equipment.

To start, there is a fairly important point to raise. You won't be able to set these keys until you have started a game. You won't be able to set them at the intro screen, because at that point in the games state, no OXP's have been loaded, so we don't know what equipment might be there.

In my view, that's probably OK, but I'd be interested in other takes. When it comes time to attach a key to a function, we can do it globally, and save it to .GNUstepDefaults, so it will persist between different save games. It's just that you can't do it until a game has actually started.

Next, is the issue of visibility. I can loop through all the installed equipment and find the ones that have a script attached. That's relatively easy. However, some equipment items are only awarded in certain circumstances, and it's possible that revealing the name of that piece of equipment might count as a spoiler of sorts.

So, question: should the list of equipment items only be made up of items you actually have installed on your ship? Because it then gets complicated: in game "A" you have bought lots of equipment items, and assigned keys to each one. Then you start a new game, game "B", where you have none of those items. Should the config screen still how the ones you've defined keys for in game "A", even if you don't have them yet, or hide them again? My feeling is that anything you've explicitly defined should be shown, even if you don't have it, but again, I'd be interested in other opinions on this.

Might this be a good reason to implement a pre-flight check procedure?

I find that I always have to reset my MFDs and prime my primables. Fine if I'm not attacked on launch - but with Hotrods.oxp I often am! It would be nicer to be able to do this before launch as part of my pre-flight checks.

ie Docked -> Press F1 -> muck about with MFDs/primables & now add in astrogatory panel checks -> Press F1 again -> launch

[phkb]

Might this be a good reason to implement a pre-flight check procedure?

It's probably independent of that discussion. Regardless of when you get to the keyboard config screen to make changes, the issue is, what should you be allowed to see.

[Cholmondely]

Might this be a good reason to implement a pre-flight check procedure?

It's probably independent of that discussion. Regardless of when you get to the keyboard config screen to make changes, the issue is, what should you be allowed to see.

Personally speaking, I think that for a new Jameson one should start from scratch with just the option to change the regular key-bindings on your astrogation boards.

And if I start adding more equipment, I'll deal with the additions then. Unless I'm cheating and give myself massive bank balance at the outset to buy all the oxp goodies. But I'm usually only buying Okti's Long Range Scanner for testing purposes.

[phkb]

Personally speaking, I think that for a new Jameson one should start from scratch with just the option to change the regular key-bindings on your astrogation boards.

That's fine for a brand new game where no key bindings have been mapped to OXP equipment. The issue is, what happens in the next new game? What you seem to be suggesting is that the key binds should be wiped for the new game. But what happens if you then go back to the first game?

So, I guess that begs the question: should these bindings be per save game, or per Oolite installation? Essentially, where should I store the binding info - in GNUStepDefaults with all the other binding info (which would make it per installation), or in the save game file (making it per save game)?

And it would be good to work this out now, as the decision will impact on how I code things.

[Switeck]

Probably best to be per installation and saved in GNUStepDefaults with all the other binding info.
It would be insanely confusing to load a savegame and not know the key bindings used in it.

But it might mean a new option seen under GAME OPTIONS for changing key bindings again...

[phkb]

But it might mean a new option seen under GAME OPTIONS for changing key bindings again...

It shouldn't. The keyboard and joystick config pages are now divided up into logical groupings, with headers. I'm planning on adding a new section with it's own header, probably "OXP Equipment Control" or something like that, then the name of each equipment item is used as the entry. There will be two entries per equipment item: one for "Activate" and one for "Mode".

Probably best to be per installation and saved in GNUStepDefaults with all the other binding info.

That was my original thought, and if I limit the list the logic would be like this:
Entries when starting a new game: none.
Entries after buying a piece of gear with activate/mode: 1 item in list
Entries after buying 3 more pieces of gear: 4 items in list

Now, if key binding have been applied for those 4 items, the logic for the next new game would be:
Entries when starting a new game: 4 items in list.
Entries after buying a new piece of gear: 5 items in list.

Then, if you go back to the first game:
Entries after loading the game: 5 items in list

And so on. That way, once the key binding is defined, you don't have to remember to rebind it. It's also worth noting that, if you have the key binding visible, but don't have the equipment installed, nothing will happen if you press the key.

But what do others think? Should the bindings be saved at a global/application level, or at the save game level?

[another_commander]

Global.

[Cholmondely]

So, I guess that begs the question: should these bindings be per save game, or per Oolite installation? Essentially, where should I store the binding info - in GNUStepDefaults with all the other binding info (which would make it per installation), or in the save game file (making it per save game)?

And it would be good to work this out now, as the decision will impact on how I code things.

Save game makes most sense to me. I just can't see an argument for doing it the other way. I often change one or two .oxp's mid game, and the first option seems more adaptable.

[Switeck]

Even if the settings are saved globally, they are all stored in 1 easy-to-copy file.

...which makes that easier than dealing with multiple OXPs (note: I don't mean OXZs which resolve some of that) with dependencies and conflicts.

[phkb]

Save game makes most sense to me. I just can't see an argument for doing it the other way. I often change one or two .oxp's mid game, and the first option seems more adaptable.

There are two arguments: The first is muscle memory. For example, I might bind "Fast Target Selector" to key "9". As I play the game I start to instinctively press "9" whenever a new ship comes into scanner range. Now, if I start a new game, I'm going to keep instinctively pressing 9, because I've developed the muscle memory in response to the stimulus.

The second reason is ease-of-use. Key bindings should be a "set-and-forget" type of thing. I don't think it's something that will be gone into a lot, no matter how friendly we make the UI. So, after binding a function to a key, it's a poor user experience for them to have to go back in, every time they start a new game, to rebind all their kit again.

I understand you're aiming for immersion, and that having a pre-flight check where you go through all your bindings sounds like something that would enhance that. But key bindings sort of straddle two worlds, the players real-world, and the game-world. The fact that I'm binding "9" to a key is already somewhat immersion breaking, because in the game world that key wouldn't exist - there would be some sort of trigger attached to the control stick that would initiate the function.

As for changing OXP's mid game, if you remove an OXP, my plan is for that binding to automatically be removed anyway. You should only need to revisit the key binding when you buy a new piece of kit.

Still happy to bat this around though!

[phkb]

Just wanted to let everyone know I haven’t forgotten this, and I’ve made some significant progress. I hoping to have a PR lodged next week(ish).

Status: I have the basic functionality working, where info stored in the .GNUstepDefaults file can be used to allocate the activate and mode keys (or any joystick button) to any equipment item.

Next steps: UI for keyboard and joystick entries. Compiling list of equipment items with scripts you either (a) already have or (b) purchase/install. And debugging.

[phkb]

Well, that went better than expected!

For anyone who's interested, the branch map_keys_to_oxp_equipment has been checked into GitHub, which (drumroll please!) enables user defined keys/buttons to be attached to any OXP equipment item that has a script, avoiding the need to prime that equipment item individually and then press the n/b keys to activate/change mode.

For those who can, it would be great if you could checkout this branch and build it yourself to see how it plays. Hopefully I've found all the major issues - but I'm a programmer so I'm always going to say that!

Feedback welcome. I'll leave it as a branch for the present time, and maybe create the PR later next week.

[hiran]

Well, that went better than expected!

For anyone who's interested, the branch map_keys_to_oxp_equipment has been checked into GitHub, which (drumroll please!) enables user defined keys/buttons to be attached to any OXP equipment item that has a script, avoiding the need to prime that equipment item individually and then press the n/b keys to activate/change mode.

Sounds great!

For those who can, it would be great if you could checkout this branch and build it yourself to see how it plays. Hopefully I've found all the major issues - but I'm a programmer so I'm always going to say that!

Feedback welcome. I'll leave it as a branch for the present time, and maybe create the PR later next week.

I believe we could increase the feedback you receive tremendously if the build were just created automatically.
@AC: Can we agree on a strategy to have Github build feature branches? Currently it only happens on the master branch.

[another_commander]

I believe we could increase the feedback you receive tremendously if the build were just created automatically.
@AC: Can we agree on a strategy to have Github build feature branches? Currently it only happens on the master branch.

Github already builds feature brnaches, it just does not create pre-releases from them. In my opinion this is fine and github should provide as a pre-release only binaries corresponding to master.

That said, and since branch binaries are auto-built as artifacts anyway (albeit accessible only to those with a github account), all one has to do in order to make them fully publically available is to upload them somewhere where anyone can access them.

Here, I have uploaded the automatically built binary corresponding to phkb's latest code for anyone interested:https://drive.google.com/file/d/1w5Q-ew ... sp=sharing

This is Windows only. A Linux artifact was also created, but I am not uploading that since there are known issues with the Linux auto-builds from github and they fail to run at this time.