I'm not convinced that grouping all scanners together would be a good idea.
I think something like
this would be much more helpful.
Okay. People have mice with a basic standard of two buttons to click on it (mouse 1 and 2). I have additional buttons which I use for macros but FDev can't guarantee everyone will have that, and my free hand is used for thrust and manoeuvring and occasionally tapping another button but its sustained use needs to be concentrated on that purpose. A gamepad has two triggers and two bumpers with, depending on layout either option is used for the 2 existing firegroups and then forward and reverse thrust/throttle. Depending on how somebody has their bindings set up two firegroups can be intuitively bound to left hand on the screen being the left trigger/mouse click, and the right hand on the screen being the right trigger/mouse click.
I don't have a HOTAS so I don't want to be presumptive about how many options people have but seeing as they're all different by model, the only real rule seems to be a trigger, a hat, and a starting point of two additional buttons on the main stick - then after that get a diagram out for your specific parts.
So if we have firegroups with a primary, secondary, tertiary and auxiliary fire button - which people may need to sustain a click on depending on what they have bound to it - where do you propose these buttons go on a control layout that means we can reasonably expect everyone to functionally use them in a sensible way? How to you represent these four distinct firing options in the HUD without generating a lot of visual clutter to navigate/that obscures the view and ends up more confusing than informative? I'm not saying you can't individually find a way to get four fire buttons active for yourself, but designing a game around a niche control input possibility isn't sensible or accessible.
Now that the patch for Chp 4 has gone live and the functions have embedded in a little my position really hasn't changed substantively, but seeing as the thread has been resurrected I'll reiterate with a slight update:
- The detailed surface scanner is no longer a scanner in the same form as other scanners. It doesn't get you the detailed surface scan information, which is now generated through FSS activity. Instead it surface maps through launching probes at stellar bodies as a distinct minigame launched from supercruise. It should be renamed to something more intuitive to its function so that its historic link to a now shifted function isn't a source of confusion. By the game mechanics (that it launches probes) it should also now be a utility module, with existing optionals remaining as they are but no longer available for purchase, so as not to penalise explorers far away from a station. The only other optional modules that launch something from the ship are the limpets (through the cargo bay) and the ship launched vehicles (through the appropriate hatch). There's nowhere to launch the probes from, so they should be fire from a surface fitted module.
In terms of fire groups for the DSS it makes sense to have a distinct key to bind in a fire group, as this is not a simple scanning function that can be reduced. An optional hotkey binding to do this similar to a heatsink would be sensible but shouldn't be mandatory. Having the ability to set the fire probes button to something distinct from the launch DSS mode firegroup button would be good too, please.
- Pulse Wave Analyser makes sense to have a distinct key to bind in a fire group, as this is not a standard scanner in the same way as the others and produces a visual response that you may not always want. An optional hotkey binding to do this similar to a heatsink would be sensible but shouldn't be mandatory.
- The discovery scanner now no longer needs to have a distinct firegroup button as it can now be activated in FSS mode through a separately bound control layer. I quite like that I can still have it in a firegroup so that I don't have to go into the FSS to fire off a honk. However as its main function is in supercruise there's little no reason to not have a context appropriate HUD response (ie don't tell me anything when I don't need to know) but still have it slaved to the same activation function as ...
- Literally every other scanner in the game. Which all operate in the same way - I have an object selected, I face it within my active scanning arc and within range, and I hold the bound fire button of the appropriate firegroup until the scan completes.
Why are some of these literally the same (datalink scanner and composition scanner)?
Why do I need to set each of these in a fire group individually?
Why do I need the visual clutter in the HUD to tell me everything I have in that firegroup when they have identical operation? The only distinction being that some of the specific scanners can be upgraded to complete more quickly or have a longer range but that doesn't change how they mechanically work in terms of my gameplay interaction.
Why would I always need them to tell me their failure or success? This could easily be a context appropriate response based on whether I have am in supercruise or normal space, and whether I have a human ship/xeno ship/geological feature/data interface targeted that the ships systems can recognise and return the appropriate message for.
My solution: install each of these modules individually in line with current outfitting. The ship then recognises which scanner modules are installed and slaves them all through a scanning systems package. Then you only have to set one scanner in the fire groups, with each of the distinct scanners slave to that as its subsystems (which can be represented in the firegroups tab without making me bind each individually). But hopefully I know what I installed on my ship: I don't need an individual fire button for each; I don't need them to create visual clutter in the HUD; I only need one of them to generate a context appropriate firing response message at a given time. An optional hotkey binding to do this similar to a heatsink would be sensible but shouldn't be mandatory.
