Currently we have a hardcoded check in the JS GUI to hide the formation panel if and only if the selected unit is not an animal or not a unit.
So if we selected a unit that has no formation available and is not a domestic animal, then we have a panel full of disabled buttons.
If a mod decides to implement animals (dogs? goose https://www.youtube.com/watch?v=inZTfHW2MxA ? starcraft clone?) and decides to give them a formation,
the formation panel will be hidden.
Code should be as versatile as possible.
We don't need this hardcoded animal check at all and can hide the panel if and only if no formations can be selected.
For the same reason one could argue that the test for the Unit class can be removed too.
Using D190 we can measure whether the test helps with performance (functionality wise it is not needed) by
adding the following code to the patched function after the declaration of availableFormation:
let t1 = Engine.GetMicroSeconds();
unitEntStates.some(state => !hasClass(state, "Unit"))
let t2 = Engine.GetMicroSeconds();
availableFormations.some(formation => canMoveSelectionIntoFormation(formation))
warn("unitEntStates " + ("0000000000" + (Engine.GetMicroSeconds() - t2)).slice(-10) + " canMoveSelectionIntoFormation " + ("000000000" + (t2 - t1)).slice(-10));Then start the game with "unlimited" population and use the "salad bowl <number>" cheat to spawn many units.
Observeration:
WARNING: unitEntStates 0000000859 canMoveSelectionIntoFormation 0000000038 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000042 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000036 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000049 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000025 WARNING: unitEntStates 0000000004 canMoveSelectionIntoFormation 0000000027 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000034 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000035 WARNING: unitEntStates 0000000004 canMoveSelectionIntoFormation 0000000020 WARNING: unitEntStates 0000000004 canMoveSelectionIntoFormation 0000000021 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000030 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000096 WARNING: unitEntStates 0000000004 canMoveSelectionIntoFormation 0000000035 WARNING: unitEntStates 0000000011 canMoveSelectionIntoFormation 0000000061 WARNING: unitEntStates 0000000004 canMoveSelectionIntoFormation 0000000024 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000024 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000028 WARNING: unitEntStates 0000000005 canMoveSelectionIntoFormation 0000000028 WARNING: unitEntStates 0000000958 canMoveSelectionIntoFormation 0000000091 WARNING: unitEntStates 0000000012 canMoveSelectionIntoFormation 0000000047
So the first time we select the units unitEntStates is much much slower (900 microsec), for every following call canMoveSelectionIntoFormation is about 3 to t times slower (10 microsec vs 50 microsec).
Therefore we can keep the Unit check if we are strict about the performance. Code-wise it still seems unneeded.