Agent got stuck before an unwalkable node even if I set repath.mode = Dynamic

version 4.3.79
First I let an agent go to a destination, While he is on halfway, I updated the graph that his front tile to unwalkable. I thought the agent will repath when he is trying to walk into an unwalkable node as I’ve set the mode to dynamic with Maximum Period = 2 and Sensitivity = 10. But he’s just stopping moving.
is there some configs that will trigger repath when the agent is finding his path is blocked?


Only the RichAI movement script can currently detect if its path is blocked by an unwalkable node. The AIPath script doesn’t keep track of the nodes in its path as such. Though you could get the current path from the seeker and iterate over all the nodes in it regularly, and if you find a non-walkable or destroyed node you could issue a path recalculation manually. However, if you are using modifiers such as the raycast modifier, the agent may not walk over exactly the same node as was in the calculated path.

okay, I am trying to do it myself: I think I can get the PathList by seeker.GetCurrentPath().path, but what’s the current index for the agent in the PathList, because it is better to issue a repath manually only when the untravelled node is updated to unwalkable.

That’s the thing. The AIPath or AILerp scripts do not keep track of the current node. They follow a list of points, not a list of nodes. So any such check will have some approximations.

Okay, so I think I can get the GraphNode by graph.GetNearest(AIPath.position).node, and loop the PathList to find the GraphNode which the agent is in (ignore the situation that the agent is pushed out of the PathList by other agents with RVO), should definitely find exactly one GraphNode which is the agent position. Then just check whether the following GraphNodes (including the GraphNode which the agent is in ) are updated to unwalkable.
As for the situation that the agent is pushed out of the PathList, just use the fallback situation: check all the PathList to see if any of them are updated to unwalkable.

Is there anything wrong with the above solution?

That should work fine.