ANavigationData::RequestRePath no longer works correctly if the target is a FVector rather than an AActor. (i.e. it was set up via FAIMoveRequest::SetGoalLocation rather than FAIMoveRequest::SetGoalActor, before being passed to AAIController->MoveTo).
That change in NavigationData.cpp means that it’s no longer sufficient to have bUpdateEndPointOnRepath set to true to force a repath; GetGoalActor() must return a non-null value, which won’t happen when the target is an FVector.
The workaround involves forcing a manual update of the EndLocation for the repath, and will look a bit like this, before any relevant call to RequestRepath:
Unfortunately I can’t share the code publicly. But all the important details are above - the code simply won’t recalculate EndLocation if there’s no GoalActor, so it can’t work.
Yes, that is the change in question, specifically the addition to the if statement on the first line. I don’t know the exact version we were on when behaviour was different but it would have been a year ago or so.
I’m not sure I understand your issue. Auto-repathing is done when underlying navmesh changes, or when the move goal moves. Vectors (as move goals) don’t normally move on their own, so if you want to reuse path object by changing path’s goal location and repathing you’ll have to do it on our own. Your workaround is actually a proper way of implementing it.
In our case, the goal has moved, just that there’s no way to represent that without making it into an actor, which we don’t want to do. We’re happy with using the workaround, but it feels wrong that ShouldUpdateEndPointOnRepath() can be true and yet nothing happens, or that the constructor will fix up EndLocation for us in one circumstance (actors) and not the other (vectors), and that GetGoalLocation() is out of sync with EndLocation in the vector case.