4.12 -> 4.13 PathFollowingComponent doesn't start moving instantly anymore

Hi all,

I am in the process of jumping from 4.12.5 to 4.13.0 and in our game, our player’s controller uses a PathFollowingComponent to move around, we give it the end point of any tap/mouse-down as the destination, and in 4.12 and before, as soon as we do this our player starts moving as soon as any partial path is available (essentially immediately). Now, I have to leave the end-point stationary (presumably until the entire path computes) before the player will move at all. This is a huge problem in a mobile game as the player is constantly “dragging” their finger around and this was working great for us before. So far I have only tested in P.I.E. with the mouse button down and dragging the mouse around, but I assume this will be the same on devices. Is there a new flag I need to set on the PathFollowingComponent to allow it to instantly move again?

The only real change I noticed when integrating was OnMoveFinished is now OnRequestFinished & takes a full result struct instead of just the result enum; but I’m at a loss to the change in the actual movement here. Thanks!

Edit: I should point out, we do a FindPathSync call to the NavigationSystem, then do a RequestMove with that PathResult’s Path, it seems previously (if this is relevant) that this would return to us OnMoveFinished with an enum result of “Skipped” and now we get OnRequestFinished with the result.Code enum of “Aborted.” It appears it is in RequestMove that maybe things have changed? I’ll continue investigating, but any help is greatly appreciated!


So it’s always a little weird to answer my own question, but I’ll keep this here in case it helps others:


This seems to be the relevant flag to set (for us to false, defaults true) after looking at Marc Audy’s changes from May 3 to the PathFollowingComponent. So there you go! :slight_smile:

However, this shows you have your player movement set up wrong. The part requesting the movement I mean. It seems that as long as finger/mouse button is down you re-request movement. Setting SetStopMovementOnFinish to false will make your move seem to work, but you still pay a lot of CPU cost for finding paths every frame. I suggest creating a special invisible actor that you’d be putting wherever player wants to go, and depend on pathfollowing’s auto goal location update mechanics to update the path. This will be a lot more efficient.

Yes, good point–this is something we profiled some time back, and generally have very short paths: when the player is moving, we spend maybe 2ms (movement, physics, pathing, all together), so decided not to spend more time on it at that point (we can live with that as our actual A.I. only move towards the player or towards a fixed point and rarely re-path). That’s a good idea, though, about using the actor as we already have a “marker” actor that we place when moving to a location already, and we could simply use that in the same way we use a targeted enemy. Thanks for the tip, it should be a very easy change to make now. :slight_smile: