About order of actions during a frame

According to the doc, the order of actions during a frame is:

  1. Each unit takes a step, if it is time for them to take a step.
  2. Each shield decays.
  3. New shields are applied, if a unit has entered the range of a friendly encryptor
  4. All units attack.
  5. Units that were reduced below 0 stability are removed

However when looking at this match, at turn 1 frame 55 to 56, I would expect the pings to move horizontally instead of vertically. I have computed manually that the deaths of the filters append before the movement of the pings, so from my understanding it is not a visual glitch

Before the precision was added to the doc, I had already noticed that kind of behavior and was thinking that the move was decided before the removal of dead units but applied after.

I have missed something? Is this a bug? Or is the doc still imprecise?

Edit: Apparently it is just an other instance of the pathing bugs, the order of actions is correct.

This does not have anything to do with the order of actions. This is related to your other topic and a pathing bug.

Given the config, we can see that pings move every second frame because their speed is equal to 0.5.

Frames:

  1. Pings move one step vertically and then attack. This is coherent with the documentation.
  2. Now, they only attack because it is not yet “time for them to take a step”. The filter gets destroyed.
  3. In this frame, they move vertically first and then attack (the destructor). The order of actions is correct here once again, but the decision to move vertically is wrong.

The filter was already destroyed in the previous frame and thus they should have moved horizontally according to rule 2. of “When it is time for a Unit to choose a tile to step onto” in the documentation:

If multiple tiles are equally close to the units destination, move in the opposite direction of the previous movement. For example, if the Unit made a vertical move on its previous step, it will prefer a horizontal move.

The documentation is precise, but this is a pathing bug.

2 Likes

8 is correct here. I can confirm that this is a symptom of the same pathing bug being discussed in the pathing bugs thread. I have been working on it on and off for a bit, so we should have a fix in soon. Sorry it’s been floating around for a while, its relatively low impact so we have been prioritizing other features over fixing it.

2 Likes