Support Forum

RichAI's definitive state. pathPending and hasPath are confusing

I’m a bit confused by these properties.

Due to the constant repathing, pathPending and hasPath is frequently both false. Yet, RichAI still smoothly moves, apparently unphased by it appearing that it has no path. Clearly, it really knows what’s going on internally.

To me it feels like these variables are very useful for the internal workings of RichAI, but confusing to the outsider, because every few frames you’re going to get an indication that the agent isn’t pathing.

How can I definitely determine the agent’s true state? Specifically: idle, it is waiting for a path, it is actively moving toward the destination.

I really don’t want to do what I had to do with Unity, wrap their NavMeshAgent, and trial and error, guess and check, the “true state” of the agent via testing a dozen variables and hacky timers.

Hi

That’s odd, hasPath should always return true after its first path calculation unless you have explicitly cleared its current path using ai.SetPath(null). If that returns false it shouldn’t have anything to move along.

pathPending will return true during the duration in which the agent recalculates its path. It will continue following its current path while this is happening.

I am definitely not calling ai.SetPath(null), but I will try to find out if I am not stopping it somewhere else.

Admittedly, because of how kludgey Unity’s pathfinding is, I wrote an enormous amount of code to “tame” it, and this exercise has forced me to review all of that, which makes this all much harder.

Maybe you are disabling/enabling the component at different stages? That would clear the current path.

I did find a place where ClearPath was being called. A holdover from the conversion from Unity’s navigation to yours, a Teleport was being called unnecessarily.

That cleans up most of my jittering problems, except for hills, I believe.

image

One unit successfully drove up and down this hill. The second is just jittering like mad, unable to move.

Strangely, this is with the “separated” RichAI approach, where the RichAI is on its own game object, and my unit simply follows the RichAI game object. This would make me think that RichAI cannot go down the hill itself, but like most of my problems, it’s probably more “teething” problems due to the conversion from Unity navigation to this package. Just shows how troublesome Unity’s navigation is.

:+1:

What can happen on hills with a recast graph is that the navmesh is simplified so much that the navmesh is just a flat plane below the hill (because the whole hill is walkable, there’s no need to add extra triangles there). This can however lead to issues where it becomes hard for the agent to know where exactly on the navmesh it is, because the navmesh is so far away. That’s why I recommended earlier that if you have very open landscapes with many elevation changes then it might be better to go with a grid graph because it will handle it more predictably.

I have been trying to bake a layered grid graph, and it seems to have a lot of troubles detecting multiple floors. In fact, I can’t get it to detect the ground at all in an actual level. It also seems to block out under an overhang entirely. Am I doing something wrong? Or is this just not the right solution?

What is baffling about Recast graph suffering on the tiniest of hills is that I currently have the RichAI on a completely separate game object, meaning that the unit’s position shouldn’t hurt the RichAI’s position, thus the RichAI is exactly where it thinks it should be. I don’t have gravity enabled to add to that confusion.

Can you replicate this in any of the example scenes with just the standard RichAI?

This sounds like a topic for a new thread. If I were to guess, the ground level is due to the grid’s base being higher up than the ground itself (if it is at the exact same y coordinate it may in some cases also be missed due to floating point errors, though I think that particular issue has been fixed in the beta version).

I found an edge case where teleport was being called, yet again, and cleaning that up has seemingly greatly reduced the desire to avoid hills.

I think I am succeeding now with the recast graph, based on all your invaluable feedback. It’s been an uphill (ha, punny) battle, but it’s starting to function as it should.

Thank you again for attempting to answer all my questions and pointing me in the right direction!

1 Like