Graph Areas not updated when OnGraphsUpdated() is called

Hi there,

I have a callback that is hooked up to AstarPath.OnGraphsUpdated. Whenever I move one of my graph blocker objects and update the grid graph such that multiple areas should be created where only one existed before, I still only see one area when I look in my OnGraphsUpdated callback. If I recalculate the graph again, it properly updates. Does area updating happen after OnGraphsUpdated is called? If so, what would be the best way to hook into when everything involving a graph update is totally complete? I used to do a FlushGraphUpdates() call after I moved my items around/destroyed them, but I have a lot of units pathing and it was tanking my frame rate pausing all of the pathing threads, so I switched to the OnGraphsUpdated callback.


Hey Eric,

You can read more about the callbacks in the Graph Modifier Base class:

Perhaps the OnGraphsPostUpdate would work better for you.

Kind regards,

Thanks Wolf, that worked perfectly for me!

1 Like

Actually it didn’t work, other code I had was forcing a flush. Looking at WorkItemProcessor, the flood fill is definitely happening before the PostUpdate event is triggered:


if (anyGraphsDirty) GraphModifier.TriggerEvent(GraphModifier.EventType.PostUpdate);

Yet, when I hook into that event and check the area of two nodes that were in different areas but should now be in the same area, the areas are still different. If I wait a few frames and check again, the areas match

GraphUpdateProcessor.ProcessGraphUpdates() is the culprit. It calls GraphModifier.TriggerEvent(GraphModifier.EventType.PostUpdate) without regard to EnsureFloodFill happening. I don’t think the event should be triggered in that method.

I agree that this should be labeled as a bug.
We’ll have to wait for Aron his return.

Any updates on this? I am having similar issues. OnGraphsPostUpdate seems like it is getting called but things are not ready. Areas not calculating properly. Wait a couple of frames and try same operation again and it works.

I couldn’t wait for a fix so I ended up just modifying the a* code to send an event when the areas were updated since it was the one thing I cared about knowing.

I think Cybereric is correct about this bug and where it is happening.

I am having various issues with area connections. Using NodeLink2 (even 2 way) and also issues with NavMeshCuts changing state. However, after a manual scan in the editor (not in play mode), things always look correct.

*** Problems in play mode are fixed when I go to the Astar component, click the gear icon, and click “Flood Fill Graphs”.

Cybereric, what specifically did you call and from where? (FloodFill…???)

Thanks everyone.

I ended up just calling AstarPath.FlushGraphUpdates() every time I modify my grid graph using GraphUpdateObjects and It’s definitely not the most performant option since it blocks the main thread until all outstanding paths are calculated and a flood fill occurs, but you are guaranteed to have everything up-to-date after the call. An asynchronous fix for this bug would be much appreciated as my game has a lot of moving agents and my grid graphs can update somewhat frequently.


I fixed this yesterday in the 4.3.7 beta. See the changelog here:

I finally got good results on my end by changing WorkItemProcesser.cs. I moved EnsureValidFloodFill() so that it gets called after GraphModifier.TriggerEvent. This fixed a couple of issues. Aron, did you do something similar?


Sort of… and a lot of other things. OnGraphsPostUpdate and many other events turned out to be very inconsistent. I have uploaded 4.3.8 now (literally just a minute ago) which makes these events more consistent and better documented.

I was thinking along the same lines. Thanks for this. Is the Beta fairly safe to use or is it meant more as an experimental version? I am on the latest official release but I see many improvements I can’t wait to get my hands on.

I have converted a lot of things to use burst which is bound to introduce a lot of bugs. But this latest beta is still fairly stable. I do not know of any critical bugs in it.

It does require the latest 2019.3 beta to run though, and some package manager dependencies.