With no apparent explanation we’re getting a null-ref exception out of NavmeshBase.GetNearestForce(), where the tile’s bbtree is null, but the tile has hundreds of triangle nodes inside it.
This hasn’t been an issue previously, and we haven’t updated AStar since September. We want to update, but we have to work around modifications that were made (not to the core areas).
I know this isn’t much to go on, but I was hoping anyone had an idea of what this could be?
Rescanning all graphs has zero effect on the issue, and it seems to randomly work sometimes.
Hi
Are you doing any graph updates of any kind? Are you calling GetNearest from a different thread?
You could try updating to the beta version, it might have fixed this.
Thanks for taking a look!
Yes we update graphs (not when this problem is occuring though), yes we call GetNearest from a different thread.
I am upgrading, I’ve had some different issues now.
Had to adjust our code to get rid of any references to the recast graphs we’re using since the graph objects are not maintained in this new version.
Right now I’m trying to find out why this message pops up, I’ve never seen it before.
Has anything changed with how paths are scheduled?
Edit: Now that I look into it more I see that error is coming from old code on our side… I’m still not experiencing expected behaviour though.
One or both of these issues seemed to have been caused by a bad graphmask being passed in (refactoring oversight due to implicit cast in constructor). Can’t guarantee that was the issue with the original error.
Hi
You’ll not be able to use GetNearest from a separate thread. The pathfinding package only guarantees that GetNearest will be safe to call at any time from the main thread. If you happen to call it from a separate thread while a graph update is happening, you may end up reading partially initialized data.
You can access it in jobs, though. By using AstarPath - A* Pathfinding Project
What do you mean by this?
Ok we can fix that.
It might be ideal to add some #if UNITY_EDITOR guarded thread index checks on the outer API layer.
The graph reference issue was that when AStar deserializes graph data, it just recreates the graph array internally.
In our situation we are forced to load astar with cached data, after which we grabbed references to the recastgraphs we’re using. Then we load our save data and deserialize new graph data, which silently overrides our references.
This didn’t happen in the version we used to be on, but I’ve since removed my references entirely as I don’t need to fetch them too often.