Here’s what I noticed when debugging the path following component code:
In UPathFollowingComponent::UpdatePathSegment() there is the following conditional statement
else if (MoveSegmentEndIndex > PreciseAcceptanceRadiusCheckStartNodeIndex && HasReachedDestination(CurrentLocation))In the case I mentioned above the MoveSegmentEndIndex is 1 and the PreciseAcceptanceRadiusCheckStartNodeIndex is 0 so we also check HasReachedDestination(CurrentLocation).
Within that function, GoalLocation is set as follows
FVector GoalLocation = *Path->GetPathPointLocation(Path->GetPathPoints().Num() - 1);but there was a recent change to the engine code which then sets GoalLocation equal to the CurrentDestination which is the end of the current segment. The current segment will not be equal to the location of the goal actor if we’re not on the last segment of the path yet. So HasReachedDestination(CurrentLocation) will return true if the character is within the acceptance radius of the end of the current segment instead, not within the acceptance radius of the goal actor.
Maybe I’m misunderstanding the goal of these recent changes but this logic seems incorrect to me.
That is odd behavior. Would you be able to share more of your setup that reproduces this issue? I have been attempting to repro it, but so far I have not seen the issue in my testing. Are you using the default pathfollowing or crowd following?
As for why the change was made, it came from Lego FN to test reachability of the actor prior to setting the goal as the actor’s location. I do not see any changes in the function since this change was introduced on our latest in UE5 Main.
I am also running into a similar issue with the same line of code. In my case, I have a simple path from X = -330 to X = +330, with 3 path points (start, (0,0,7.5), end).
My acceptance radius is large at 400, which is to cause the pathing to stop when in range of a ranged attack. The character is supposed to path from their start until they are in range, then attack.
However, HasReachedDestination() returns true, because as part of pathing along that path, it checks against CurrentDestination, which at the start is set to the middle point near the origin. Since they are within 400 units of that, the path completes early without being in the proper range of the destination.
CurrentDestination checking, from what I can tell, is supposed to be (and is properly) checked in HasReachedCurrentTarget(), so I am not sure why it is used in this case.
@James.Keeling Hi. I was the original poster of the issue through Epic Pro Support which I no longer have access to, but glad I’m able to follow up here. Sorry for the delay. I can confirm the issue reported by @cranney-prophecy is the same one I encountered. The repro steps they posted worked flawlessly for me to repro the issue again.
Create a new empty level with just a floor
Place a nav mesh bounds actor and cover the floor
Build paths
Place an NPC at 330, 0, 0
Place a target actor at -330, 0, 0
In the middle place a box that bisects the direct path causing the shortest path to be 2 segments/3 path points (beginning, middle, and end)
In the level BP on Begin Play use the AI Move To task and tell the NPC to move to the target actor with an acceptance radius of 400
Simulate the level
Notice how the NPC will not leave its spawn location even though it finds a complete path to the target and is greater than 400 units away
The issue is due to checking the distance to the upcoming path point because in UPathFollowingComponent::SetAcceptanceRadius we determined that PreciseAcceptanceRadiusCheckStartNodeIndex should be 0. This makes sense because node index 1 is within the acceptance radius and node index 0 is not. So we should be checking if we reached the target after passing index 0 (the start of the path) but the issue is that we’re checking the distance to index 1 not the goal actor location/index 2.
Since the NPC is within the acceptance radius (400) of index 1, UPathFollowingComponent::HasReachedDestination returns true.
This is caused by this commit. I was able to fix it locally by rolling back the changes to UPathFollowingComponent::HasReachedDestination since they were not applicable to my project.
