BTTask MoveTo -> actor always fails in Lyra 5.4

Red line indicates although target actor is set, task fails to move to it.
Target actor is Object of base class Actor.
MoveTo → vector works for default Lyra bot behavior but fails in other tests which is one of the more confusing things.

5.3 Lyra works fine.
5.4 non-Lyra works fine.
5.4 Lyra fails.
5.4 Lyra 2nd project fails.
5.4 Lyra new project that’s never crashed fails.
Custom task with moveto fails.
MoveDirectlyToward works. (but fails for vector)
Cleared Lyra local content for fresh download project, also fails.

EQS that sets TargetActor

Alternatively, a custom task with SimpleMoveTo:
actor fails
getactorlocation fails
vector of that same location succeeds :confused: what!?

Any ideas? Anyone able to test this?

Something has changed. I recall from an old UE4 live stream that this “move to” node is not very reliable, if something blocks or interrupts the task, the AI will get stucked. Therefore, a custom task is preferred. A few notes:

  1. Try to add a wait task with a short delay before the move to task.
  2. Create a custom decorator with a Boolean "has target’ on top of move to. Also, in the sequence node, add a service ticking has valid target actor. Once target is set, use a Does Path Exist? to check whether or not the pawn should move, which will set the bool value.
  3. Check the search range of the EQS query and the actor criteria. I had better results with a custom EQS actor query, in which I added an actor tag.

Hope that helps.

1 Like

Thanks! Those seem like great tips to work with.

It got me testing more and I found it has something to do with pathfinding, but specifically I’m having success turning off Require Navigable End Location in a custom task. That sounds like it could be a problem perhaps if the target is somewhere it can’t reach, but it seems fine in that scenario.

As you can see it’s a simple path, from cube to cube.

RequireNavigableEndLocation
If set, require the end location to be close to the navigation data. The tolerance is controlled by QueryingExtent.

it’s good to see you’ve narrowed down the issue. Good work!