Selection Loading and Command Race Behaviour

posted on December 10th, 2013, 12:16 am

Summary: The game engine sends player orders to the ships that are currently displayed as being selected. It can take a discernible amount of time for the engine to load a selection of ships from a saved command group. If the player issues an order in the time between selecting a command group and it being displayed, the order will go to the ships previously selected.

Details: Consider the key-press sequence:

1
R
2
Right-mouse click

If the right-mouse click is issued in the time between the player pressing "2" to call up command group 2 and the engine displaying the ships contained in command group 2, then the order given by the right mouse click will in fact go to group 1 (overwriting the repair order and possibly resulting in unnecessary unit loss).

In a hectic situation, even a performance computer under light load can take long enough to load a new selection for orders to go to the wrong group.

Specific reproduction steps:

1. Set up two saved command groups, eg 1 and 2. Each command group should have a mix of vessels and ideally have 17 or more ships in them.
2. Impose sufficient CPU / memory load on the machine for there to be a definite period of time between requesting a selection group and for it to be displayed.
3. Select group 1.
4. Select group 2. Before the new selection is displayed, issue an order (move, repair, etc). Note the order is carried out by group 1, not group 2.

Reproducibility: Consistent.

Impact: Even on a Core i7 with low loading, this can be encountered, disrupting micro and thus flow. If you've ever wondered why some groups didn't seem to get the orders you sent them in the middle of a hectic battle, this is likely the reason why.

Workaround: Make sure the command group requested is displayed before issuing a command.

Fixable? Unknown, but considering the functionality involved, probably difficult.

posted on December 10th, 2013, 3:32 am

nice discovery....

i need to ask.

is it same if i send one ship from fleet "1" to repaire and i select quickly fleet "1" and give movement order than previously selected vesel for repaire doesnt go to repaire ?

secondly what is causing oposite situacion ? when i send one ship from fleet to repaire, and all my ship from that fleet goes to repaire but not the one send in first place ....

posted on December 10th, 2013, 4:01 am

nice discovery....

i need to ask.

is it same if i send one ship from fleet "1" to repaire and i select quickly fleet "1" and give movement order than previously selected vesel for repaire doesnt go to repaire ?

If you only did a normal repair (r) instead of force repair (shift+r), then the repair order would be overridden by the movement order to the entire group. If you did a force repair on the single member and encountered what I have reported, then the rest of group 1 wouldn't move.

However, if you issued a force repair on the single unit while close to the yard, then switched to the group as a whole and issued a movement order just as the unit was entering the repair queue, then the movement order would override even a force-repair order at that moment. It's a known behaviour, dating back to Armada II (maybe even Armada I), and I'm not sure the devs can do anything about it. I suspect it was programmed in as a way to let a ship break free of the queue if the yard it's heading into is destroyed or decommissioned.

secondly what is causing oposite situacion ? when i send one ship from fleet to repaire, and all my ship from that fleet goes to repaire but not the one send in first place ....

Edit: I misread what you said. Here's my correction:

What may have happened is that you may have hit shift a bit too early in the command sequence. Shift + selecting a ship in a group removes it from the current selection group, so you may have inadvertently deselected the ship to repair from the group. When you subsequently hit the repair command, you've ordered all of that group bar the intended ship to go repair!

posted on December 10th, 2013, 5:23 am

What may have happened is that you may have hit shift a bit too early in the command sequence. Shift + selecting a ship in a group removes it from the current selection group, so you may have inadvertently deselected the ship to repair from the group. When you subsequently hit the repair command, you've ordered all of that group bar the intended ship to go repair!

first, thx for shoving me deselect comand, i tryed to found it , no luck.

second , that isnt the case, you understand it corectly, but the ship send to repaire (btw shift +R) stays on the fleet "1" stop all actions but all the other ships from fleet "1" go for priority repaire. Not only close to yard.
this bug was seen several times by me and Drone, and several more players. Cant name them, because i do not remember exactly to who , it happened.

posted on December 11th, 2013, 4:40 am

This type of UI behavior that you describe, Madhatter, should not be possible.

What's most likely is problems with the command being registered. With sufficient latency, a single key press (resulting in a string of "orders" gets interrupted and then interpreted as several orders of the same type). Basically to do with the rather archaic way that Armada interprets key strokes. I.e. if you hit R, the command "string" can go out at the beginning of the press up to the end with enough latency. So, if you have fleet "1", hit R, and then hit fleet "2" without releasing R yet, the R command gets resent to fleet "2". Other more obvious issues include two-hotkey command systems, when a separate command shares one of the same hotkeys. Let's say C and shift+C. If you were to hold down shift and C, the first command would go through, but if you released Shift before "C", a "C" command would then be input.

Ships that were previously force repaired getting called out at the moment of entering a queue is basically a problem with giving another order between when the force repair is cancelled and the queue order is called. Bad timing, and bad Craft AI programming.

As for fleet vs ships-in-fleet issue that Shadow brought up, that's a function of the Craft AI. Craft AI in this case is responsible for assigning individual ships to a formation. As long as ships were given an order together, they are part of the same fleet and inherit commands (like attack commands and move commands). Repair orders are queued differently than other orders, and so can get inherited by the whole fleet. The more latency there is, the worse this issue gets. In general, more latency=more order problems, because latency results in skipped cycles. That means an order cycle might get missed in what would otherwise be a smooth transition.

These type of Craft AI issues are the hardest for us to fix, but we have a solution a ways down the road

posted on December 12th, 2013, 3:58 am

This type of UI behavior that you describe, Madhatter, should not be possible.

I'll keep testing with your information in mind but please bear in mind that I've been observing this behaviour, with a view towards characterising it and getting it in a decent bug report, for months.