Whole fleet options kinda seems dangerous to me, if you are using lots of different ship types - never used it to not mess up with individual ship settings to be honest. Copy to variant is great, though =) There is a separator that seems to be doing nothing, and save/load options could be combined under one setting if you want to cram everything in one.
I think I found a decent solution for this one. The whole code for the GUI was getting a bit messy, since I just kept on slapping on more options, so I did a lot of refactoring. Now, by default, only the current ship is affected. If you hold shift, the whole fleet is affected and if you hold control, all loadouts are affected. I might try to add a confirmation dialogue to whole-fleet options, though. I'll put out a new pre-release soon (TM) to get some feedback on this.
Multiple suffixes that you can use would be nice to be honest, and that's exactly what I asked for - a suffix for ForceAutofire, not an AI (one of the bottom options, not the top one as it doesn't make sense in the top area anyway). For now, I believe you can only allow it for missile-only groups where flux isn't a concern - even though there are a few missiles that generate flux, it should be a safe option I think. Just like how you cannot set some AI PD-related stuff on non-PD weapons, perhaps?
Yeah, I understand that you would like a suffix that does this^^ Unfortunately, that's technically not possible. Suffixes are part of the AutofireAIPlugin, which gets loaded into the weapon. When something that isn't the active ShipAI, such as an AutofireAIPlugin, gives a command to the ship, the game will throw an exception, meaning the game will crash. That's why I said that both a suffix and a ShipMode would be required. That way, the suffix would essentially do nothing and the ShipMode would simply check if a group contains that suffix.
I could, in theory, simply implement the "force autofire for all weapon groups that have a ForceAutofireSuffix" ShipAI and apply it to every ship, even when set to default. But to be completely honest, I don't really want to. So far, when you set something to default, it will keep its original AI. If I did this, all ships would end up with a custom ShipAI, even if set to default, which seems risky/unclean. I'm the kind of person that gets really annoyed when software does stuff like that, so I don't really want my software to do stuff like that... xD
Also, I don't think it's really necessary to restrict it to missile weapons. There are some missile weapons (e.g. the [REDACTED] antimatter missiles) that generate lots of flux and some non-missile weapons that barely generate any flux.
Would you still be interested in this suffix, even if it only works if you also enable the ForceAutofire(SuffixOnly) ShipMode?
To be honest, yours' is doing it without a hullmod; it's doing the same thing in a different way. It's up to you of course!
I'll think about it. I would at the very least want to talk to the author of automated commands first.
The second option could also work in reverse. Book A could display your persistent settings, and Book B appears only if you made a change during combat, so that you can revise them and apply them to persistent book. Book A, the persistent settings are always loaded, Book B is only there for you to check the changes. When checking out a ship's options, an option could be used to toggle between A and B so that you can see what exactly you've changed. Unless you apply the changes to A yourself, B will vanish on the next battle, something like that. I apologize if this is what you meant by the whole thing, and I misunderstood it in reverse.
That said though, the whole Book A & B thing would make the UI even more cluttered in my opinion. Cluttered is maybe the wrong word, confusing perhaps is the right word. As you've said, what will the user be looking at when they open the GUI? Where will it say that which settings are permanent, and which were temporary; used in your previous battle/test? Unless you can create a completely custom UI, you might not have the necessary tools to deliver that information as cleanly as possible I think. And as far as modding in Starsector goes, I've seen an over-reliance on dialogue and intel panels - either it's easier, or the rest are somewhat hardcoded an inaccessible. To be honest, seeing your 'excel-sheet' for the options was a surprise to me, no other mod I've seen has a menu like that (outside the intel screen).
The first option seems preferable. A setting in the file that's set to false by default; that I need to change in order to make combat changes temporary seems to be exactly what I'm asking for, and thus I'm biased If you can detect simulations, the option can be split into two; changes in combat being temporary, and changes in simulations being persistent for example. Though that's another thing. A button to use in-combat to save the temporary changes would go alongside this nicely.
Using the GUI to apply/revert combat changes could also be an option in the GUI; it'd go alongside the persistent/temporary in-combat change setting in the options file. The separator option (is it used for something, by the way?) on 4 for example, if the ship in question had an in-combat change, it can say 'Apply settings from last combat' and when you press it, it can turn into 'Revert changes from last combat'. It is grayed out otherwise. It's a simplified version of Book A/B, per ship, and only appears (not grayed-out) if there's a change.
Anyway, all in all, I'd say the easiest solution might be the best. You can use that time to enjoy the game / do other things instead of making something that might be used by just a handful. I mean I can always try to remember changing stuff back after a battle =)
In theory, you can pretty much build a custom GUI in whichever way you want. As soon as you deviate too much from what Starsector intended, you are firmly in manual OpenGL-territory, which gets very messy & complicated very quickly xD My custom GUI is mostly default Starsector with just a sprinkling of custom OpenGL stuff. Implementing the kind of GUI that conveniently & intuitively displays the content of two different books would put it into 90% custom OpenGL mode, which is probably a bad idea^^
So I think I agree with your assessment, that the first option alongside a "persist changes"-hotkey is probably the cleanest way to do things (and should be easy enough to implement). I don't even think it's necessary to differentiate between simulation/combat, since you can always press the "persist changes"-hotkey when you want to set stuff up in simulation.
Update:
If anyone is interested, my current roadmap looks something like this:
First, I want to implement a couple QoL-improvements and requested features, such as the ones discussed in this post and maybe the option to apply suggested modes to enemy ships (disabled by default, as this is a bit gimmicky, but has been requested via Discord) and playtest a little more.
After that, I want to start working on a 1.0-version, which will probably change quite a few things. Currently, my plans for 1.0 are roughly:
- Replace the GUI with a refit-screen integration. Not yet 100% sure how/if this will work.
- Replace weapon group modes and suffixes with modular tags. So, rather than e.g. setting a group (with HE weapons) to Opportunist with a HoldFire(Flux>75%) suffix, you'd e.g. assign the AvoidShields, Conservative, HoldFire(Flux>Threshold) and Threshold=75% tags or so. I still need to come up with a good control scheme to make this work in combat, though. My current best idea is: You can (either in settings.editme or in a special GUI) define presets (i.e. collections of tags) which you can cycle through in combat the same way you can currently cycle weapon groups. Alternatively, since 0.95 it might actually be possible to make a GUI show up in combat? Not sure though^^
As this will require re-writing large parts of the mod, don't get your hopes up that this will happen anytime soon, though...
I might occasionally put out a work-in-progress build in case anyone wants to help with testing, but I most likely won't be paying much attention to feature-requests etc. until I'm done.