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])
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 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.
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.
@RegularRyan
Another instance of targeting bug where units want to score only at [23,18]:
At first the pings did: https://imgur.com/1VWbS1c
Then when the filter at [23,13] was destroyed: https://imgur.com/8KydXdf
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: https://terminal.c1games.com/watch/477158
Happens in turn 5.
Edit: It actually looks like those units were targeting [11,22], since the scramblers move directly towards that square.
@RuberCuber
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”
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].
Could it be that point 4. in pathfinding rules is triggered here?
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.
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
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