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
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.
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.