Units command queue is reset when they enter new formation

[zoot]

Steps to reproduce:

1. Task one soldier to gather resources.
2. Task another soldier to gather resources somewhere else.
3. Select both soldiers.
4. Queue the soldiers to build a house.

What happens: The soldiers immediately stop their current task and begin building the house.

What I expected would happen: The soldiers should complete their current task before they begin building the house.

OR

Steps to reproduce:

1. Begin building house with a soldier.
2. Select him and another soldier and queue-order them to build another house.

What happens: The soldiers immediately stop their current task and begin building the second house. This is bad because it is very common to add workers to a building task one-by-one as they become available from other tasks.

[leper]

I'm not really convinced that this is a bug. I know that this happens, check GetFormationUnitAIs in simulation/helpers/Commands.js to see why.

What should happen? The newly created formation should wait for all units to finish their current tasks? What if one of those units is in a formation with a lot of queued tasks? Should the new formation wait for that one to finish? Should they just start executing the task on their own? What is the purpose of formations then?

(It doesn't happen for female citizens, because they can't use formations)

[Jonathan Waller]

I agree with the sentiment that this is not worth trying to fix. UnitAI is ugly enough already, this is an unusual case and the expected behaviour is not well defined.

[zoot]

Though I understand the reasoning, I very much disagree that this is an unusual case. I'm convinced a lot of people will run their head against it once they have just a tiny bit of routine.

[Kieran P]

Seems like something for a design committee. To me, it seems like we need a new system here: If a unit is gathering resources, building something replaces the current order. If the unit is building something, building something else queue after the current order.

[leper]

The code in Commands.js (GetFormationUnitAIs) could check each units order queue, but I don't really see how that would improve much.

[zoot]

Here's an even worse case:

1. Begin building house with a single soldier.
2. Now order a second soldier to begin working on the same house.
3. Now order a third soldier to begin working on the same house.
4. While the soldiers are still building the house, select them and queue-order them to build another house.

What happens:

The soldiers immediately stop their current task and begin building the second house. This is bad because it is very common to add workers to a building task one-by-one as they become available from other tasks.

[elexis]

At times it happened to me to build a civic centre / tower / fortress and then queuing those units to build more things or attack the enemy, expecting that they finish the building first. But they end up having the structure built only 98% and then moving away (often it wasn't noticed).

Another example is to queue some enemies to attack. They will not finish their first target before moving to the next.

leper has given some hints on irc on how to implement the update.

[elexis]

An illustration of how the current order is canceled when the intention was to queue an order.

[mimo]

moved back to backlog as no activity

[Imarok]

Move tickets to Simulation as UI & Simulation got some sub components.

[Freagarach]

Fixed along the way. Somewhere between A20 and A23b apparently. A not so quick search couldn't find a relevant commit.

[Freagarach]

Ouch, I was too trigger happy.

First, see also #3479, secondly, the issue still exists, albeit only using formations. So perhaps these tickets can still be closed and a new one specifically for formations can be made.

[wraitii]

In 24480:

Allow picking a default formation for walk (and walk-like) orders.

This allows choosing a "default formation", which is activated automatically for units given walk orders (and attack-walk etc.).
Conversely, units in formation that are given a gather/build/... order are taken out of formation and given the order individually.
The default formation can be selected by right-clicking on any formation icon.

This leverages formations for walking, where they are quite efficient (in fact, perhaps too efficient), while circumventing issues with various orders.

Choosing the "null formation" as the default formation de-activates the behaviour entirely, and plays out exactly like SVN.

This makes it possible to queue a formation-order then a noformation-order (i.e. walk then repair), though the behaviour isn't very flexible.

For modders, it should be relatively easy to change the setup for each order, and/or to force deactivating/activating formations in general.

Tested by: Freagarach, Angen

Refs #3479, #1791.
Makes #3478 mostly invalid.

Differential Revision: ​https://code.wildfiregames.com/D2764

[wraitii]

(I think this was referring to formations since back then they were active by default).

The root cause of this 'bug' is that units are immediately put in formation, as they discard their current order. As written above, doing this in a "deferred" manner seems non-trivial: should units wait for others? How to determine which units should be part of the formation in the future? How to handle deaths? It's unlikely that all units will stop their current order at the same time. All that seems rather complex, and possibly un-necessary.

r24480 / ​Phab:rP24480 introduces "formation->noformation" queuing but that's much easier than the opposite, and it's still _kinda_ hacky. Further, that diff circumvents the issue by using formations for walking only, and by ignoring formations for queued orders (fixing the reproduction above of 'assign units to buildings, then queue a move order)

I don't think the ticket is necessarily invalid or fixed, but it's no longer a 'must have' IMO.