Some QoL stuff for firegroups.

Ok, first up, let me say that this is NOT a "do it my way" thread. The design I'm proposing here will let the folks happy with how it is now keep it exactly like that. The idea here is to allow more people to set up their control schema exactly how THEY like it.

We have lots of stuff that "should" or "may" be assigned to a firegroup to use. Some of it works in SC only, some only in normal space. Some of it works in Analysis mode only, some in combat mode only. Some of it doesn't even need hardpoints deployed, while most of it, of course, does. The current state has you either with lots of firegroups to cycle through which aren't relevant to your current ship state or with just about every firegroup generating a "switch modes" or other flag when you use it.

Two additional options would make both these go away if the players set them.

1: An option to "skip non-functional firegroups" - when enabled, cycling firegoups forward or back would skip any that have nothing assigned that are functional in the current ship state and HUD mode. When changing ship state or HUD mode, if the current firegroup would be skipped when cycling, cycle forward to the next one that has at least one action assigned that is functional in the new ship/HUD state.

2: an option to "suppress state warnings" if the fire key being triggered has anything that works in the current ship/HUD state assigned. So if a firegroup has mining lasers and beam lasers assigned to primary, with this option unset you would still get the warning in both analysis and combat mode, because there is something assigned that doesn't work in this mode. Set the option, though, and an overloaded firegroup of this kind will generate no warnings because there is something assigned to that fire key that works in the current state.

This would allow greater flexibility for those players that want it while letting folks who like the way it currently is just leave those options unset and keep playing the way they currently do. The players that want to overload firegroups or set things up another way would be able to set one or both of these options and configure things to their preference.
 
So this is a "do it my way" thread.
Just kidding its not :)

I must admit on some of my ships the firegroups are a total mess and the warning messages constantly generated really annoying. I would support anything that would go towards cleaning it up at least a bit. Would your ideas work as intended, I don't know, but you have to start somewhere.
 
...Would your ideas work as intended, I don't know, but you have to start somewhere.

Agreed. I've a background in writing software requirements and I did my best to think through as many use-cases as I could come up with and not preclude any of them in the proposed design. For example, a user who has VoiceAttack macros to select firegroups would never set the first option, because they have to keep the number of firegroups cycled through constant, irrespective of ship state or HUD mode, for their macros to work. On the other hand they might want overloaded firegroups, such as one they designate "lasers" which has their beam lasers and mining lasers assigned to primary, their multicannon and prospector limpets assigned to secondary. So they'd set the second option to suppress the warnings and simply tell VA to "select lasers" whether they were rolling into a fight with their fangs out (HUD in combat mode) or quietly lining up to ravage a poor innocent asteroid (HUD in analysis mode)

With this basis, I'm sure the design could be fleshed out a bit by FD (heck, if they want to hire me to do it I'm up for that!) - they might, for example, decide they wanted the warning suppression to be more than just a toggle , say three states "strict" (current situation, and the default), "fuzzy" (only suppress warnings if there is something bound to that fire key that does work - my proposed state ifthe options is on, above) and "none" (never warn, even if nothing can fire in the current state.)

But, as you rightly say, it's a starting point. So long as whatever the final design turns out to be fulfills two criteria, it's an improvement. Those two criteria are 1: to not require a user to alter current behaviour if they do not wish to. 2: to permit different configurations to suit as many additional use-cases as possible where they are poorly catered to by the current behaviour. You can almost never go wrong by making something more configurable.
 
So if i could be developer for a day, one of the first things i would do would be.
1) give fire groups a third fire button. i have a hotas as do most people, i shoudl be able to bind 3 weapon groups at once.
2)Make 2 catagories for fire groups, combat, and data fire groups, combat fire groups only appear when in combat mode, and data groups only appear with in data mode. I hate having to switch through my bloody sensor stuff to get to my weapons.
 
Or allow keybinding of fire groups. Skip silly toggling through fire groups altogether.

I am keyboard+multibutton mouse. Don't know if this helps HOTAS at all.

My Ultimate Preference: Programmable Macros
  • Give each ship parameter a macro command name and provide simple macro text editor.
  • Allow a keybinding for each macro.
  • Macros can be stored globally per account. Macro keybinding done on a per ship basis, perhaps through the cmdr's HUD interface. Therefore each ship can have its own unique macros defined (not global).
  • Macros would allow FDev to evolve ships with more features without overwhelming a cmdr trying to pilot the ship.
  • We are all big boys and girls. I'm sure we can handle programming basic macros.

Example Macro:
// Macro Name: Cobra_Prep_Combat_1
// Purpose: Set defaults for combat
// Keybind: F1
set external_cam = off
set gal_map = off
set sys_map = off
set combat_mode = on
set hardpoints = on
set cargo_hatch = off
set SysPips = 4
set EngPips = 1
set WepPips = 1
set Hpoint 1= Fgroup1, 1
set Hpoint 2 = Fgroup1, 1
set Hpoint 3 = Fgroup1, 2
set Hpoint 4 = Fgroup1, 2
set FGroup = 1
 
Last edited:
Agree.

There's another thread for this stuff..

 
Never one to not learn something

Why do my heatsinks fire in data mode when i pair them with DS but not in the the same state when I arrive at a station?
 
Back
Top Bottom