Bug Report: AI controller / MoveToLocation not working when pawn is spawned

I want to report a bug in 4.25, when spawning an AI pawn via a blueprint the “Move to Location” function (or any other “move to” node) does not work.

However, when I place the pawn manually into the level, it works fine and the pawn moves to the set location. It only does not work when spawning it via blueprint (either via “spawn actor from class” or via “spawn AI from class” ).

I have set “Auto Posses AI” to “Placed in World or Spawned”.

flyingAI-problem3.png](filedata/fetch?id=1803847&d=1598112046)

As you can see from the screenshots, there is really no reason why this should not work. Especially since it works fine if the pawn is placed manually into the level.

I reproduced it in a new, clean & empty project and it’s still the same (not working when spawned), so there must be some bug with the AI controller when a pawn is spawned & not manually placed.

Could someone please look into this?

Thanks!

Everything is working fine. Are you using an ai controller or all the control is done in the pawn itself? Have you tried, inserting a delay between begin play and isvalid?

Also, are the return values of the moves nodes successful? Since you’re calling Move right from the begining and only once, then make sure to spawn the AI very close (touching the limit) or inside the nav mesh volume.

Did you see the screenshots I made?

A delay between “begin play” and “is valid” doesn’t fix it, I already tried that.

There is no navmesh and it isn’t needed anyway. It’s a simple MoveToLocation using FloatingPawn movement. As I have said, it works perfectly fine when the pawn is being placed into the level manually, but not when being spawned via blueprint.

The return value gives me a “successful” when the pawn is placed manually into the level, but a “failed” when being spawned. Therein lies the whole problem.

Sorry, still unable to replicate your problem.

UE4 4.23.3
Pawn: static mesh + floating component
No navmesh
All moveto logic in the pawn itself
“Placed in World or Spawned”, “AIController”
No delays

In editor or spawned (spawn actor or spawn ai), all working ok.

Am I missing something?

Thank you for trying to replicate it, but perhaps it’s that you are not using 4.25? I had a discussion in the Unreal Engine Discord yesterday and another user had the same problem, with the “move to” not working when spawned, so it’s not me alone.

Sorry my bad. It’s 4.25.3.

Did you create a seperate blueprint that spawns the flying pawn? Considering that another user on Discord had the same problem, and it doesn’t work in a new, clean project either, means something is broken.

Yes. Spawned both in the level BP and on a separated BP, all works ok.

Every problem I ever had with the move nodes, were caused by: trying to move before possession, no controller, no navmesh (no problem in this case) and invalid target or destination (also no problem in this case).

The only way I can make it fail is by using any other Move node (without a navmesh and with UsePathfinding set to false). But “Move to Location” always works.

Weird.

have you tried the node “Spawn Default Controller” on your spawn actor from class?

Just did, it doesn’t help.

Hello all,

That may be a bit of topic’s unburrial, but in case someone is still wondering:
On your pawn, you have “Auto Possess Ai” dropdown, allowing you to choose what behaviour you want.
image

I have the exact same setup and exact same configuration, but in 5.3.2, and it doesn’t work either when it is spawned in the world, but only works when manually placed in the level.

I know PawnFloatMovement is not being used a lot, but does anyone found a solution to this bug ?

1 Like

Having the same issue here on 5.4. This is frustrating. I need this floating movement

I got the smae issue like 4 years later. No way this still isn’t fixed

MoveTo methods require a valid Controlled Pawn.
Are you sure you’re calling them at a point where your Controller has successfully possessed its Pawn and GetPawn returns a valid Actor ?
Maybe try calling MoveTo inside OnPossess for example, and see if you still get the error.