I was more thinking of selecting the group of enemy ships, and then hitting priority button. Not too complex in a middle of a fight. Say, double-click the offending cruisers to select all on screen, and hit a P9 button. This would be more to guide the AI rather than override its target selection logic outright.
Gotcha -- I see now what you mean. Still, there are several complexities in this at the moment including 1) we don't support selection of enemy ships, and changing that will be a challenge 2) all of the 0-9 keys are already used for control groups in the main window. This last can be overcome, but still.
In the current target selection logic, each ship is currently acting independently and killing what it can best kill, whereas with this sort of prioritized approach they would presumably have to just limit themselves to the current highest-level priority and kill whatever they are best able to kill in there. I could see a few mild benefits from this, but overall it's fairly redundant with a lot of what is already there in the game. This is one of those cases where I just don't feel like the juice is worth the squeeze, for a variety of reasons. If there's widespread demand for this I'll look into it more, but no other RTS game that I've played has had this, and I just don't feel like there's a lot of value there compared to the several days of programming it will required (and the number of bugs a change of this magnitude will likely introduce in unrelated areas).
I was thinking that this command would set the priority on the 2000 enemy ships, and then tell the 6000 ships to re-prioritize targets. Only 8000 commands. Alternatively, perhaps it's time for a multicast attack command. Say attack( firer array, target array). Then of course you would need code to figure out what multicasts to send...
Yep, something like this would work -- given your example here, actually it would just take the 2,000 commands for setting the priority on the enemy ships. The other 6,000 ships would not needed cross-network commands at all, that would just be part of the simulation logic when they are auto-targeting. So your approach as outlined here is certainly vastly more efficient network-wise than what I was thinking, but I'm still not feeling the love for this one. Sorry! I hate turning down a feature, but at this point this particular one is just more of a bear than I really want to get into. The feature is on my maybe-down-the-line list, though, so if it comes up with a lot of players then maybe we can revive it.
Oh, and I second the vote for explicit Windowed mode (where I can resize the window, and where the mouse is not snapped to the window).
Hmm, resizing the window is not going to ever be possible with the game in realtime, just based on the way everything is coded out it has to be restarted after every resize. But what I will do is put some common resolutions in there so that you can choose from a list as to what you want. Should have something for this in there today for you to try out, hopefully that will be a help.
Thanks again for posting!