Question on ForceUpdate() Behavior

Basically what I’m having trouble with is trying to figure out ‘how long ForceUpdate() will take’ to ‘finalize’ the navmesh before I can safely start manipulating it again.

Essentially what my script is doing / looks like:

(after being in a ‘default state’ then enabling NavmeshCut scripts, followed by adjusting the ‘new tags’ data, and then calculating a path)

-NavmeshCut scripts are disabled.
-ForceUpdate() is called on the TileHandlerHelper.
-a ‘wait’ of some duration is used to hopefully give ForceUpdate() enough time to complete.
-a method is run that restores data to the nodes in the now ‘default’ navmesh (navmesh is restored to a ‘clean’ state).

Depending on the ‘wait value’, everything can either work out just fine, or end up with a problem where ‘there are more nodes now than the original navmesh had’ (which I take to mean that one or more of the NavmeshCut scripts has not been ‘fully de-activated’ yet) and therefore the node tag data cannot be properly restored.

This ‘timing’ problem is especially obvious when changing computers with the same project. For example, on my main desktop, a ‘wait value’ of 0.1 seconds works fine, however the same setup on a ~2008 laptop usually will result in the error, and of course the problem extends to the mobile devices as well.

I’ve been trying to figure out where in A* I can look to make sure I don’t do anything before it is safe to do so (but I’m going in circles at this point), and the only thing I can do right now is set a high wait time (which slows down the ability of agents to pathfind since they all sit in a queue).

Any ideas as to what I should be looking at would be greatly appreciated.

Additional Info:
As far as I am aware, I have no limits applied to graph updates and am only using one tread.

Hi

In the latest beta I have added some extra documentation clarifying what you should do to get that behavior.
See docs here.

In the current version FlushGraphUpdates with the default arguments really didn’t behave as you would expect previously (and not as it was originally intended). It just made sure the graph updates were started, not that they had actually been completed. I have fixed this in the latest beta. See changelog. So you likely want to download that.

1 Like

I see, thank you for the clarification.

At the moment, I’m trying out waiting for TileHander’s EndBatchLoad() to return before making any changes and it seems to work well (consistently safe across various hardware), are there any obvious problems with doing this that you can see?

Hi

If you want to wait until work items are complete then you can poll AstarPath.IsAnyWorkItemInProgress (only exists in the beta). Waiting for EndBatchLoad works as well I guess…