Path pooling and multiple AStarPool objects

Hi guys,

i have designed a level when i cross a threshold it loads in a new AStarPool object and meshes etc and unloads the old AStarPool and the game continues, when i go back to the first area i get an error…

When i leave the first level i disable all the AI objects and i try and clean them up like this:

void OnDisable()
{
Debug.Log(this.gameObject.name + " : script was disabled");
if (path != null) path.Release(this);
path = null;
}

i get this error after afew seconds of going back onto the 1st AStar terrain:

ArgumentException: You are releasing a path which has not been claimed with this object (A__056 (AstarPath)). Are you releasing the path with the same object twice?

Q1) is it possible to clear the path pool of all paths ?

Q2) i noted that AStarDebugger says Pool Sizes (size/total created) ABPath 1/3. Even after i have moved onto the new AStar - does that mean i am missing a path release or my OnDisable() is not working ?

Thanks,
J

The path pool is global and is kept between scene reloads (it’s a static class). Releasing all path instances when the AIs are disabled should be the right way to do it.

ArgumentException: You are releasing a path which has not been claimed with this object (A__056 (AstarPath)). Are you releasing the path with the same object twice?

That looks like it might be a bug. Do you have a simple example scene in which you can reliably trigger this exception?

Hi Aron,

I have multiple AstarPath objects for each terrain tile in my scene.

When the player crosses onto a new tile it will disable all AI elements/bots, then it will disable the gameobject with the AstarPath component on it, then it will enable the AstarPath gameobject and component for the terrain tile where the player is wandering.

Is this approach wrong ? Should i have only 1 AstarPath component then assign the new Navmesh to it when the player enters, instead of having multiple AstarPath components ?

Unfortunately this is in the core scene of my game and its like nearly final i cant really send you a demo, at the same time i might by going about this all wrong.

Hi Aron,

I have made you an example.

Hi

Do you mind sending that as some other archive type (e.g zip). I tried several different decompression programs, but they all failed for some reason on that archive.

Hi

It looks like you are using a 3.x version. I am not sure, but it is very likely that this bug has been fixed in 4.x. There were a lot of bugfixes between 3.x and 4.x.

In any case, is it not possible for you to use a graph for the whole world at the same time (I recommend having only a single AstarPath component in the scene at any time)? Considering you already have everything loaded, you just use different disabled/enabled GameObjects.

Hi Aron,

Thanks for the reply. the reason i am not using version 4 was because of this issue: ( that was me ages ago )

The demo i sent you was to illustrate the bug. I have over 128 tiles some that are over 65000 vertices some less. They are fairly complicated geometry. 3.x version seemed to be most efficient when i tried first vs 4.x.

Having all the tiles loaded in is not an option because the geometry is so complicated i have to completely load / unload terrain tiles depending on the position of the player. Which works pretty well apart from this issue…

I will create a branch and retest with v4.x but i am also looking at the procedural example this may be what i can use, can you tell me if the ProceduralGridMover script benefits from pre-existing graph data that has been cached i spent many nights making my 128 tiles ? Also is the ProceduralGridMover mobile friendly its seems to only have a memory footprint of 50 megs just like a single full navmesh.

Thanks for your help man ! Awesome product btw!

Cheers
J

You can use the procedural grid mover with any grid graph graph that you load from a file (or using the cache) if that’s what you mean. It will continuously recalculate the necessary parts of the graph as the player moves around.

The procedural grid mover does not cause any additional memory footprint increase over what a grid graph normally uses.