Why did they have to split the double click processing to two different places?
Judging by the amount of commented out code and what it refers to I suspect that the original implementation/intention of mouseLDoubleClick() was to handle double clicks no matter where they occurred in the game. It makes it easy to debug double-click behaviour with a one-stop shop but they evidentally came to a more logical viewpoint: context is everything...
Unless some of the selected ships happen to be repair corvettes.
Having played around with ship combinations it seems that the bug is really that repair corvettes have been lumped in with support frigate behaviour. The current behaviour is correct for support frigates since they can never dock again, so support is their only order possibility. Repair corvettes can both dock and support. I'd have said that repair-corvette "contaminated" selections of fighters/corvettes should all dock (which is what the mouse cursor shows). If you want the repair corvette to support instead you have the option of control-Z; the alternative behaviour (ship-specific docking) has no keyboard equivalent.
So then we have the more interesting case of fighter/repair corvette/support frigate/whatever combinations. I'd say that anything able to dock in the selection should dock and everything else should be filtered out. Support frigates should retain their previous orders, not
change to support the Mothership/Carrier. It's not what the mouse cursor indicates will happen and there shouldn't be any secondary side effects. A support order would have to be made more explicitly.
(On a personal note, thanks for bringing this topic up as it's allowed me to understand the exceedingly annoying behaviour of a support frigate continually driving around through my fighter squadrons when I issue a support order on them. I expected the frigate/capital repair beam support behaviour to kick in, not the drunk driver chaos that currently ensues...)
I am also quite confused about the roles of selSelected and mouseCursorSelect.
I believe selSelected
is just intended for transferring MaxSelection
data around. This is not an isolated instance; there are lots of globally accessable buffers of various types throughout the codebase. I can only assume that Relic had major memory problems or wanted to limit the potential for creating memory leaks but I'm just guessing here. As it is, I've seen at least one bug caused by code reading one such global buffer, storing a temporary value into it and then reading it back again assuming it was still the original value... Having said that, in this particular case, selSelected
may be a storage area dedicated to filtering operations so that original selections (in this case mouseCursorSelect
) are not corrupted during processing.