When a player gives an order to a unit, I got in the habit from Unity’s navigation to ensure I always convert that input into valid, on-navigation-mesh destinations, before passing it to the pathfinding system.
Since I am dealing with lots of hills, I am attempting to always us a distanceXZ constraint get using GetNearest. I believe I have succeeded in ensuring the clicked coordinate gets a on-navmesh position with the proper distanceXZ constraint.
Unfortunately, it appears that RichAI, and the underlying pathfinding system, will reassess the destination, even though it’s already on the navmesh. On hills, this causes it to jump frequently to the edge of the hill.
Inside of RichAI, I added a DefaultConstraint property, so that when it does its GetNearest check, it will use the same constraint as me. (Technically, since I’m giving it “clean” destinations, this lookup really isn’t necessary, right?)
I thought I had won the day, until I found yet another GetNearest call inside of the pathfinding thread itself. This is where I’m stumped. Each ABPath instance appears to have a constraint reference, but since the ABPaths are pooled and seemingly managed by the thread, I don’t see a good way to inject my “hey, use my constraint instead.”
Any ideas how I can ensure my NNConstraint is used throughout the pathfinding process? Note, that I have a variety of units with different sizes, so realistically, each unit archetype’s pathfinding process needs to use its own constraint.