In the screenshot below, the yellow line is the multitarget path the right most unit trying to move to. However, it gives me Path Failed : Computation Time 0.00 ms Searched Nodes 0 If I manually intervene, like slightly moving the this unit or update a navmesh cut caused by other units, it usually can find a right path again. Any insight on why this is happening?
Path Failed : Computation Time 0.00 ms Searched Nodes 0
Error: Couldn't find a valid node close to the any of the end points
Path Number 45 (unique id)
UnityEngine.Debug:LogWarning (object)
AstarPath:LogPathResults (Pathfinding.Path) (at ./Packages/com.arongranberg.astar/Core/AstarPath.cs:849)
AstarPath:<.ctor>b__82_3 (Pathfinding.Path) (at ./Packages/com.arongranberg.astar/Core/AstarPath.cs:665)
Pathfinding.PathProcessor:CalculatePathsThreaded (Pathfinding.PathHandler,Pathfinding.BlockableChannel`1/Receiver<Pathfinding.Path>) (at ./Packages/com.arongranberg.astar/Core/Pathfinding/PathProcessor.cs:357)
Pathfinding.PathProcessor/<>c__DisplayClass27_0:<StartThreads>b__0 () (at ./Packages/com.arongranberg.astar/Core/Pathfinding/PathProcessor.cs:121)
System.Threading.ThreadHelper:ThreadStart ()
Seeker and AI configuration
AStar configuration
Astar 5.1.1
Unity2022.3.28f1
Hi
I note that you have set A* Inspector → Settings → Max Nearest Node Distance to 0.15.
This means that the path will fail if the end points are more than 15cm from a reachable part of the navmesh (even on the Y axis). Maybe this is what is happening?
The navmesh cut in the picture has a 1.6 radius. The ends of those yellow lines are definitely within 0.15 to a walkable area. I tried make it 0.5 instead of 0.15 and it seems a bit better, but not fixing it completely. Making the Max Nearest Node Distance a lot bigger (like 10), will cause it to generate a wrong path when there is a thin wall (e.g. a 2 width wall caused by multiple units’ navmesh cut) between the unit and the target. Is there anything else I can try?
Hi
Are you sure it is close enough on the Y axis as well? The y axis also matters for the distance calculation.
The Y axis is always 0 in my game. The ground is completely flat, the collider generating it is a simple plane/box.
I noticed that even when I move a stucking unit by 0.1 (manually moving the unit while running in editor), it would generate a valid path afterward. Otherwise, the stuck unit usually need a navmesh cut update (some other unit moved/died) to “find” the path.
Weird.
Would you mind changing the A* Inspector → Settings → Debug → Graph Coloring setting to “Areas”. All the nodes around your agents should show up in the same color if they are connected. If some nodes unexpectedly show up in a different color, something might be happening with the navmesh cutting.
I changed the Max Nearest Node Distance back to 0.15 so that the issue triggers more often. (I was using 0.35 since last time you mentioned it).
The navmesh is always the same color at the moment. I captured some screenshot when some units failed to find a path. Again, yellow lines are the multitarget path destinations.
See the screenshot below:
Hi, is there anything else I can try to mitigate this?
I cannot see anything strange in the screenshots. It looks like it should work just fine.
Could you try to edit the MultiTargetPath.cs script to replace this line:
var endNNInfo = GetNearest(originalTarget);
with
var endNNInfo = GetNearest(originalTarget);
Debug.Log("Found end node " + i + " at distance " + Mathf.Sqrt(endNNInfo.distanceCostSqr) + " " + Vector3.Distance(endNNInfo.position, originalTarget));
to see what it prints. Increase your Max Nearest Node Distance setting to 0.35 (or higher).
This is what I get when someone stuck:
It is from index 0 to 59 in this case.
This is the state when it is stuck:
Max Nearest Node Distance setting is 0.35 in this testing.
Can you additionally add:
var alt = AstarPath.active.GetNearest(originalTarget, NNConstraint.None);
Debug.Log("Found alternative " + Mathf.Sqrt(alt.distanceCostSqr) + " " + (alt.node != null ? alt.node.Area.ToString() : "<null>") + " " + startNNInfo.node.Area);
I got this:
It seems the alt route is able to print out something with the
NNConstraint.None.
This is the nnConstraint for the original calculation:
That’s strange.
It prints that there is indeed a node very close, but it has a different area compared to the starting node.
This means that the pathfinding system thinks there is no valid path to that node.
But I’m confused, because previously you posted an image with the coloring mode set to “Areas”, and from what I can tell from the screenshot all nodes have the same color (which indices the same area value).
Do you have a separate hidden graph in your scene or something?
Also. That NNConstraint doesn’t make sense. It says area=6, but the debug info printed startNNInfo.node.Area as being equal to 5. They should be the same.
I have more graphs (for different sizes and for warping), but the units are only have 1 single traversable graph.
I think the last screenshot for nnConstraint not very clear. I print it out together this time.
The area code actually changes a lot, where everytime a navmesh cut happens/a graph update, the whole area seems to be assigned to a different area code.
I think the issue seems to be the startMultiTargetPath will start with area.code = 1 for example, but while calculating, a navmesh cut happens and the whole area becomes area.code = 2.
But the theory above doesn’t explain one scenario, some units might get stuck for a few seconds, where there is no more graph update during the period. My units repath every 0.5-0.7s.
Another theory is that the stuck unit’s area is out of date during a graph update, and it can only be updated when the graph updates again. This explains when I try to move something to cause a graph update, the stuck units will unstuck.
I haven’t figured out how the area of a unit get changed, do you think this could be the rootcause?
This is my repath logic. The navmesh cut enabled/disabled with the moving field. Meanwhile if the unit is already moving=true, reassign it won’t do anything to the navmesh cut, so no graph update would happen.
I am still digging into the issue. I have some finding that might help with this issue.
This is my current graph setup:
Where small medium large is for different sized agents. And the warp graph is to add navmesh cut onto moving units so that when warping, the unit can use the xxxWarp graph so that it wont warp on top of someone moving. (it is misspelled but consistent within the code base for now).
When I turned off all graphs except the Recast Graph Small, I noticed that navmesh cut/graph update won’t change the area code at all. I tried for a while but even with very small Max Nearest Node Distance, I couldn’t reproduce a stuck scenario.
Where if I enable to top two only, when doing cuts, the Recast Graph Small’s node area code will flip between 1 and 2. I noticed that the stuck unit will not move until its walkable graph’s area code flip back to the one it started pathing.
I also noticed that the chance of getting stuck is somewhat correlates to the system load. After I added those logs, it causes a lot of slow down in editor mode, and units stuck way more often with there area code being mismatched. And if I change from multithreading to single threading, it is also worse.
I still couldn’t find why the area of the StartMultiTargetPath won’t change even after the area it is standing on changed. I traced the code and I think when starting a path, it would GetNearest on the starting point, which should yield the latest area code. But in the testing above, the stuck unit’s starting point won’t change even I request pathing again.
Could you please provide some insight about this area in StartMultiTargetPath?
Is it possible for you to share a project in which I could replicate this issue?
Area codes can change pretty randomly during graph updates. The exact value doesn’t matter, only that nodes that are reachable from each other have the same value.
Hi, thanks for the responds. I can send you my project. I created a zip but it is like 20G (5G project file with 15G of some temp cache/packages). What is a good way to share it to you?
I also recorded a quick demo video on how to reproduce the issue. I can reproduce the issue every 5-ish times running with MaxNearestDistance set to 0.05. It would be harder to reproduce if I set it to 0.35. But I encounter it every 5-10 minutes of normal playing.
