How to get GASP Mover player character to move to specific location (i.e. the front of a chest or door)? Simple move to location doesn’t seem to work, and AI Move To works only on AI.
the reason simple move-to does not work: GASP’s player character is a Mover actor driven by the Mover component, not a Pawn with CharacterMovement, so AIController/PathFollowingComponent machinery (SimpleMoveTo, AI MoveTo) has nothing to drive. the pathfollowing system attaches to UCharacterMovementComponent; Mover sidesteps it entirely.
your options in 5.6+ GASP-style setups:
- do the pathfind yourself, steer the Mover with the result. call Find Path (AStarGridPathfind or the NavSys node: Project Settings still build a navmesh) to get a point list from the player to the chest, then feed the Mover movement intents along it: set the movement modes/input the same way player input does (the GASP input handling ultimately sets an intent/direction that Mover consumes — drive that from your path instead of input). each tick, direction = next waypoint - actor location; clear when close.
- if motion warping is what you actually want (approach + interact with a specific point), skip pathfinding: GASP 5.6/5.7 ships with motion warping — add a MotionWarping component, expose a warp point at the chest (set motion warp target from the chest socket/actor), and play the interact/loot montage with the warp so the character glides to the exact spot. for interaction-with-thing gameplay this is the pattern GASP was designed around and it looks far better than walking a path to a point.
- hybrid, which most action games ship: pathfind with option 1 until within N units of the target, then trigger the option 2 interaction montage for the final approach. avoids the ugly stop-on-a-dime at the chest.
practical notes: make sure a NavMeshBoundsVolume exists and the recast navmesh generates (Mover actors do not create it for you); for grid pathfinding in a small level, the AStarGridPathfind node with a configured grid is often simpler than full navmesh. and use the Mover’s own movement modes (walking, flying etc.) rather than fighting it with AddActorWorldOffset, or you break the simulation/authoritative split the component is built on.