Multiple unit types and multiple graphs

First off, this is a great system, many thanks to Aron for creating and maintaining it!

I am using 3.x to build a RTS-style mechanic where different types of units have different radii and slope climbing ability. EG: a dismounted infantry unit is about 0.5m radius and can climb a 60 degree slope; a wheeled vehicle has a 2m radius and can climb a 30 degree slope. So far, so good – sounds like I want to create two RecastGraphs per scene, one for each unique set of constraints.

How do I assign the Seeker component on instances of a wheeled vehicle to only use the “WheeledVehicles” graph? The tutorials and documentation I’m seeing deal with multiple graphs covering different pieces of a large scene, not different overlapping graphs with different trafficability for different entity types. Is this a situation where I’d assign tags? IE one whole graph’s nodes tagged “infantry” and one whole graph’s nodes tagged “wheeled,” and then trust the seeker to find the correct graph that way?

Bonus question: is there an easy way to cache and restore state from an in-memory copy of a recast graph? I’d like to remove and add connections at runtime, which is easy enough, but then I need to performantly restore the graph to its’ original state.

Edit: Looking at the docs, I see I can pass Seeker a graphMask, which is a bitmask referencing graphs in the order in which they are added to the Pathfinder. I am having trouble consistently controlling which graph is used with tags, but it at least seems like I can control the graph that is used with the graphMask. My current approach is to name the graphs based on string constants, and look up the index of the graph I want, then passing a bitmask based on that to the Seeker when requesting a path. Is this a reasonable approach or am I missing something nuanced about how to employ this library?


I’m glad you like the package :slight_smile:

Yes, that’s what I would recommend. Tags should work as well I think, but it may add unnecessary overhead as it also tries to search the other graph for a valid node.

That does seem like a nice utility function that I should probably add to the main package.

Well, you can save the whole graph to a byte array and then load it again, but it won’t be particularly high performance as it has to recreate the whole graph from that serialized representation. I’m afraid you will have to keep some custom data structure for this.