Sorry in advance for the long post … this is about an issue I was having and how I went about trouble shooting it. It was a useful exercise, so I figured I’d share and hopefully someone else will save some time on their journey if they run into something similar.
1-line-summary for those not interested in reading all this:
Target actor set as waypoint can’t be more than 100cm Z delta to the nav mesh or pathing becomes impossible, creating a delay between waypoints.
If you’re still reading … this is how i figured it out 
After implementing the solution per the video, one issue that I noticed was that poor Steve and Harry were taking about a 5 second break at each waypoint before moving on.
First, the BT graph was showing what you would expect … most of the time in MoveTo, with small blips to the ChooseNextWaypoint.
Second the ChooseNextWaypoint BP showed normal execution both in speed an path ( I’m not sure it is covered yet, but using a debug filter on a BP to trace execution is pretty nifty and would be a good topic to cover if you haven’t already ).
Third, I tried all manner of things … adding more waypoints, taking away waypoints, adding guards back, and such. What even annoyed me further was that one of my guards ( although not the one i was mostly looking at ) at some point started to NOT have delays, and I couldn’t pinpoint the change that caused/fixed it because I wasn’t pay close enough attention.
In the end, it was just chance that I noticed the issue … I just happened to open up the BT graph in a separate window so that I could see it during simulation AND watch the actual in PIE behaviour. What I found was that even though the guard had stopped, the BT was still operating in the MoveTo state.
I deduced that this meant the AI controller didn’t think it had “reached” it’s destination, and I’m guessing the pause was some sort of timeout somewhere. Interestingly during my playing around with the targets I found that guard began moving normally, and a little comparison led me to start reviewing the height ( the Z location ) of the target points.
Based on some testing, it appears to me that if your destination location is more than 100cm away from the NavMesh the AI just stands there and continues to try. I fired up the visual logger ( Window->Developer Tools->Visual Logger ), and found that while on the last movement segment of the path, and there is about 6 seconds of the following entry ( after which the next waypoint is interrogated ):
LogBehaviorTree (Log) Execution request by Sequence[0] (result: InProgress)
LogPathFollowing (Log) Moving directly to move goal rather than following last path segment
LogPathFollowing (Verbose) [agent to segment end] dot [segment dir]: 0.000000
LogPathFollowing (Verbose) dist 2d: 0.000000 (agent radius: 42.000000 [88.199997])
LogPathFollowing (Verbose) Z diff: 4.024536 (agent halfZ: 96.000000 [196.799988])
LogPathFollowing (Log) OnPathFinished: Blocked[Blocked]
LogBehaviorTree (Log) Task Move To[2] finished: Failed
LogBehaviorTree (Log) Message observers removed for task[0:2] (num:2)
LogBehaviorTree (Log) Execution request by Move To[2] (result: Failed)
LogBehaviorTree (Verbose) Deactivate node: Move To[2]
LogBehaviorTree (Verbose) Testing node: Sequence[0]
LogBehaviorTree (Verbose) Ran out of nodes to check, looping tree.
Adjusting the Z height to be less than 100 away from nav mesh results in:
LogBehaviorTree (Log) Execution request by Sequence[0] (result: InProgress)
LogPathFollowing (Verbose) OnSegmentFinished
LogPathFollowing (Log) OnPathFinished: Success[Success]
LogBehaviorTree (Log) Task Move To[2] finished: Succeeded
LogBehaviorTree (Log) Message observers removed for task[0:2] (num:2)
LogBehaviorTree (Log) Execution request by Move To[2] (result: Succeeded)
LogBehaviorTree (Verbose) Deactivate node: Move To[2]
LogBehaviorTree (Verbose) Testing node: Sequence[0]
LogBehaviorTree (Verbose) Ran out of nodes to check, looping tree.
So based on this it would appear that internal pathfinding logic in the core of unreal somewhere, decides that if the z-diff is too great, it’s not “arrived” and therefore with no other bathing options it sits around doing nothing until the operation times out, at which point I have to assume that Finish execute is called, and the next it then has another change to choose another waypoint per the BT. Interestingly the acceptance radius for the MoveTo node did not factor into this z-depth comparison it seems.
Anyway, sorry for the long winded post, but I found the visual logger to be pretty interesting for tracking a pathfinding problem and hope it helps other people.
