Hi @aron_granberg , hope you’re well. It’d be very useful to be able to pass in a “penalty modifier” when requesting a path. By that, I don’t mean changing the penalty of nodes within the graph, only evaluating the node with the modifier applied. For example, the Construct function could have the following signature ABPath.Construct(Vector3 start, Vector3 end, OnPathDelegate callback=null, **Func<GraphNode, float> penaltyModifier=null**) and when evaluating a node’s penalty while computing the optimal path just do EvaluateNodePenalty(**penaltyModifier(node)**) instead of EvaluateNodePenalty(node.Penalty). It’d be something extremely useful and versatile.
I wanted seasons to affect my penalties. But I just figured that the extra calculation would wreck the speed of pathfinding, so not an option.
It feels like it would be super taxing on the AStar algorithm, although I learned lately that operators are now generally faster than table look ups / fetches (as of about 2010), so I do wonder. I think this would be moot, because a fetch is still required every node for the walkable bool.
You just got the same answer as me from a Aron about ItTraversalProvider. My situation was different, (not the season adjust penalty).
I dont know mutithreading, but have some theoretical understanding of the jobs system. Apparently, branching operations ate a no-no.
Thanks a lot, that’s exactly what I was looking for! @NeOmega in my case the navmeshes are quite small and static, on top of that, I only calculate the distance to my avoidance volumes (in a thread-safe manner using structs with data). I don’t expect it to have any visible impact on the pathfinding