Can only path once. Subsequent pathing always fails

General Recast graph
1

I bought the package just a few days ago, after immense frustration with Unity’s pathfinding.

I have made a few test projects with this package, and they seem to work as expected.

But now swapping out Unity’s agents with this package’s RichAI in the actual game, and the units only will do a single move order correctly. All subsequent moves send a warning:

Path Failed : Computation Time 0.000 ms Searched Nodes 0
Error: Couldn’t find a node close to the end point

Stranger yet, is I can recreate the same situation, with the same starting points and destinations, and it will always work the first move, but not the second, despite them being the act same situation.

Any ideas?

2

That’s odd. Can you show a screenshot of your graph?

3

Thanks for the quick response.

I don’t think a screenshot is necessary, as this test is happening on effectively a flat map.

Though, there are numerous graphs, for different sizes of units. I run a scan for all graphs before the gameplay starts, so I don’t think that should cause any problems.

I used to have a NavmeshCut component on the units, only enabled when completely stopped, but I have temporarily disabled that for a while now and still having the same problem with the second move always saying the second path always fails.

RichAI’s isPathing property shows false, even after setting a new destination. Reviewing your code, it appears that the destination isn’t checked until at least one frame later. To help get an accurate isPathing value, between the setting of the destination, and the actual pathing calculation starting, I have called SearchPath() immediately after calling the destination setter, and that seems to have solved that issue. Would that be any cause for alarm? I had not done that in my tests prior to the implementation in the game.

Do you think it could have something to do with the fact I disable the RichAI between each movement order? Update: I removed nearly all the disabling of RichAI, and also put breakpoints to see if I could spot anything awry with enabling and disabling. It still fails on subsequent attempts to generate paths.

I have confirmed that the destination position is indeed on the nav mesh, not that it was really necessary, seeing as the first and second attempts assigning the destination uses the exact same method.

I am really stumped at this point, and I am incredibly behind my due dates, which is what led to me radically changing pathfinding solutions this late in the game… :frowning:

(On a side note, I did note one issue with BaseAI’s movement: if you have a kinematic rigidbody it still tries to use rigidbody.MovePosition, which only works when kinematic is false. I added a “&& !rigid.isKinematic” in BaseAI’s movement code to ensure it uses transform.position instead in this situation.)

4

image
image722×385 94.1 KB

Only the logs on the left actually have collision for the navmesh right now. This is a testing level.

I am experimenting now with the AI Destination Setter, just to see if I can get it to work, removing most of the game logic.

It works… more often-ish… but there seem to be sweet spots where it works, and many times when it doesn’t. Sometimes the unit just drives to the edge of the map and gets stuck, ignoring the green line.

I’m really lost.

5

If you have multiple graphs you need to make sure the seeker is configured to only search that graph.

1 Like
6

I never saw the Raycast Ground Mask property before. Previously it always said “Handled by Rigidbody” there, but now it’s there, and that seems to answer SOME of the weirdness that’s happening. It appears to have been raycasting onto itself.

Weirdly, the Gravity field in the editor seems to be freaking out. It jumps between “Handled by Rigidbody” and letting me choose where gravity is from. As a wise man once said, “it’s whack.”

That still doesn’t answer why I am very clearly telling the unit to move on top of the navmesh, I confirm it’s effectively on it, and yet it says, “couldn’t find a node close to the end point.” I’m not doing anythign tricky, just trying to move around the open plane area without any NavMeshCuts or other obstacles.

One strange thing about this project is that everything is scaled up by ten, meaning one meter is actually ten units, due to the scale differences in the game. I really doubt that’d cause a problem, but throwing it out there.

7

Hmm, can you check if your A* inspector -> settings -> Full Get Nearest Node Search toggle is enabled?

8

If you have multiple graphs you need to make sure the seeker is configured to only search that graph.

That seemed to be the crux of the biscuit.

More testing to go, but that was a golden nugget of information. Thank you.