Help influencing node choice on a point graph?

Hi there! Love the A* Pathfinding Project. We used it in We Need to Go Deeper and are using it again for Camp Canyonwood.

I was wondering if I could get some advice on a particular problem I’m up against. Currently, our game utilizes 2 recast graphs, one for the exterior overworld, and one for all of the interiors of buildings. Those two recast graphs are connected by a point graph which sets up a new entry and exit node for each building as they are placed in our world.

Because the interiors of buildings are placed below our terrain in an order that doesn’t really correspond to their position above (just a simple 2D grid of interiors get filled up in array order), our agents are trying to follow our main character into interiors, but end up choosing entry nodes that will take them to an interior which is spatially close to the interior I’m in, but still not the right one. I suspect that what I need to change is any kind of penalty for distance between the agent’s current position, and the position of the interior node they actually want to be at. Essentially, in the player’s eyes, those distances are functionally zero. How can I get agents to buy into this belief as well?


One additional piece of information: I’m using NodeLink2 for graph traversal. Is this something I should be using NodeLink3 for? I’m admittedly a little stumped on how exactly to configure that type of traversal, but let me know if it’s more appropriate for my situation of bridging recast graphs at great distances (and especially bridging a specific point on a recast graph to one and only one specific point on another recast graph).

Update! I was able to fix this problem by waiting a full graphUpdateBatchingInterval before scanning the point graph. I had completely forgotten that I had an update interval for my graphs. Looks like it was just a time issue! Phew!

Edit: If I finish waiting until the recast graphs have done their updates, THEN scan my point graph, it works! If I change that point graph scan to a ScanAsync? The problem rears its head again. Why would this behavior come up if the bottleneck was waiting for the recast graphs, whose updates are already done?

1 Like