What's a good way to create and save additional information during path search?

Suppose I have an implementation of ITraversalProvider that modifies node costs depending on several conditions which cannot be easily expressed as penalties assigned to grid (e.g. when calculating path for AI, we want it to avoid attacks of opportunity, which means we should check whether entering a cell would trigger an attack of opportunity, but the character might have a feat that prevents it from triggering such attacks, always or in some circumstances, e.g. “ignore first attack of opportunity every turn”).

After the path is calculated, AI wants to know information about some of these conditions (e.g. how many attacks of opportunity will it trigger). We can, of course, post-process the found path (or all cells found in ConstantPath) and once again do the same checks we already performed in TraversalProvider, but this seems wasteful, since some of those checks can be somewhat costly.

So, what I want to do, ideally, is to save some information that TraversalProvider calculated, and associate it with a node of path. One approach would be to implement a custom Path, with its own type of PathNode, which would contain both the usual information, and my additional information, but this requires deriving all my paths (ABPath, ConstantPath) from this new Path, and a lot of copying of code.

Is there a better way to save this information?

Additional question: I want a custom cost for movement on the grid (e.g. axis-aligned movement is 2 points and diagonal movement is 3 points). TraversalProvider doesn’t know if movement is diagonal, and there is no way to customize this in graph settings. What’s the best way to do this, then?

Hi

I think re-evaluating it will be the best way. The ITraversalProvider is evaluated on every visited node, which can often be more than an order of magnitude more than the number of nodes in the final path. Storing this data would take up a lot of memory, and all to just save 1-10% of the execution cost of the ITraversalProvider.
For a ConstantPath it’s different, I suppose, since the result will be the exact number of nodes visited. Still, for simplicity I think re-evaluating the ITraversalProvider is much simpler, and I would recommend profiling first to see if this is an actual performance issue.

This cannot be done with the ITraversalProvider. However, you can modify the gridGraph.neighbourCosts array at runtime to apply different costs.
The default cost is 1000*(world distance between the nodes).

Thank you for confirmation, I’ll take a deeper look at the performance then.