Pathing / targeting bug?

When testing my algo against the boss B10_UIUC-SPECIAL, a group of scramblers choose a strange target destination:

It scored at [23,18], the path finding look coherent assuming [23,18] was the target destination, but there were clearly closer target destinations (I expected [18,22])

Is this a bug or did I miss something ?


I actually just discovered this this morning and was working on it today. Odd that two instances of this bug were revealed on the same day after not having issues for some time, it may have been introduced very recently

Please let us know if you see this again, it may help me track down the cause


I think I just found another strange pathing bug, with pings following this path:

They did the same thing the turn after except they scored at [6,20] instead of [5,19] since there was firewalls at [4,18] and [5,19]

This is maybe related to the first bug: in both case the units seem to like the y=18 coordinate


@C1Ryan I had also this when testing some stuff by hand:

So this is probably not related with any precise y coordinate.


I believe I patched the original bug you found yesterday, but it is possible I did not do so completely, introduced a new issue, the update has not gone out yet, or units are pathing correctly (Its hard to tell from your example). Ill investigate.


Oof ill fix this today



Did the fix for this go in yet? I just played a match where I think this pathing bug was the difference between winning and losing:
Match time: 2018-10-19T05:03:55.334Z

Round 8, 9, and 12 some pings end up dying when I believe their path should have kept them completely safe and the opponent wins in the end with 3 health left.


Agree, looks like a bug here


Another instance of targeting bug where units want to score only at [23,18]:
At first the pings did:
Then when the filter at [23,13] was destroyed:
They didn’t change their target when they destroyed the firewalls at [24,14] and [24,15]

In all those cases I would have expected the pings to go for [27,14], [26,15] or [25,16] instead.


Not quite related to the pathing bug, but I noticed in one of my matches that some enemy units self destructed for no apparent reason when their units occupied the same square:
Happens in turn 5.

Edit: It actually looks like those units were targeting [11,22], since the scramblers move directly towards that square.


Yeps, definitely not intended


I’m glad you put that here, it is very likely a result of the same bug. If a unit reaches their destination, they check if it is the enemy edge they are trying to reach: If it is, they score, if its not, they self destruct. This behavior is extremely strange, im not sure how that tile could have ever been marked as an endpoint. I’ll heavily prioritize solving this on monday after resolving anything on my plate which other team members are depending on.


I have seen multiple matches now with another pathfinding bug. Normally units move like in the docs described: “If multiple tiles are equally close to the units destination, move in the opposite direction of the previous movement”

But this doesn’t seem to be the case in the following match:


Just wondering, which player and frames you had in mind?


For example on round 17 multiple units of ALGO_V50 are moving a long time on the y-13 row with the target location [1, 12]. I would have epected one of the following target locations: [10, 3] or [13, 0].


Looks like both of paths would be 22 moves.

Could it be that point 4. in pathfinding rules is triggered here?

  1. If there are two tiles with equal distances and are equally prefered based on direction, the unit will choose one that is in the direction of it’s target edge. For example, if a unit wants to reach the top-right edge, and must choose between moving left and right, if both tiles have the same minimum number of steps it will move right.


@Janis That unit should have go for [10,3], passing by [19,10] then [16,9]

By the way in that game of @Felix the bug is present as soon as turn 3, frame 277 with the EMP passing by [24,13] instead of [23,12]


I am able to consistently reproduce the bug in the playground (by hand) with those steps:
Turn 0, player 1: Spawn any firewall at [0,13], then remove it using the removal mode
Turn 0, player 2: Spawn a ping at [0,13] (from player 2 pov) to check the normal path of the ping
Turn 1, player 1: Nothing
Turn 1, player 2: Spawn a ping at [0,13], that ping will use a bugged path


What am I missing? I depicted your mentioned path to [10, 3] through [19, 10] and [16, 9].

  1. Why does it need to end up in [10, 3]?
    As seems also the yellow path is 22 turns long.
1 Like

From what i’m guessing the pathing algorithm use a map of the distances between each tile and each edge, and when a firewall is added or destroyed that map of distances is updated by changing only the area that has become inconsistant, propagating a new correct distance from tile to tile. When a unit move, it goes to the tile with the lowest distance to the unit target edge, and if there are several of them do it’s zig-zag preference.

However in some conditions at unit destruction there is a bug where a tile is given a distance that is lower than it should, and this error is propagated to every tile before it

1 Like