Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

AI Behavior Tree never leaves MoveTo node

I have a behavior tree that always gets stuck on the MoveTo node, despite reaching the destination. The Acceptance Radius is set to a huge value (500), and the pawn reaches the the goal within .01 in each dimension. What am I doing wrong? edit: I should note that this is in 4.7 preview 8. alt text

Product Version: Not Selected
more ▼

asked Feb 23 '15 at 10:59 PM in Blueprint Scripting

avatar image

11 1 3 4

avatar image twodice Feb 23 '15 at 11:11 PM

FWIW it does move past the MoveTo node if I attempt to path outside of the navmesh volume.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

All works as expected. Here's what's happening:

  1. You request AI move to TargetLocation

  2. AI is moving to location

  3. AI reaches location

  4. Move task finishes with success

  5. BT reruns from root, looking for highest possible task to run

  6. Finds Move To node and runs it

  7. Since AI is already at location the task instantly returns with success

  8. Next frame goes to point 5

You need to add a test checking if AI is already at location.



more ▼

answered Feb 24 '15 at 11:07 AM

avatar image

MieszkoZ STAFF
7.3k 225 57 413

avatar image twodice Feb 24 '15 at 09:46 PM

Am I misunderstanding how sequence nodes work? I thought that they were supposed to run each of their children until one of them failed. (Most of my limited understanding of behavior trees comes from this article http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php)

avatar image twodice Feb 25 '15 at 01:55 AM

If I add a decorator to the MoveTo node that always returns true it gets stuck on the MoveTo node, and if it always returns false the entire sequence is aborted (as I expect). If I replace the sequence with a selector, and add a decorator to the MoveTo that fails if the actor is close enough, it runs the MoveTo on the first pass through the tree, completes, and then runs the sound node on the second pass. Is there a way to do this on one pass through the tree, without the delay?

avatar image MieszkoZ STAFF Feb 25 '15 at 12:32 PM

Wait! I'm wrong, you're right! I didn't notice it's a Sequence :/

So theoritically this should work exactly how you expect. I feel there might be a bug in how we treat node results if your root is a sequence. Yeah, that ROOT is not the real root - it's just a dummy editor-time node so that you can indicate which BB asset to use.

Can you try making that first composite node a Selector and then make your sequence it's child? Let me know if it still doesn't work. If it doesn't it may be a bug in BT move task :/

Sorry for the confusion!


avatar image twodice Feb 25 '15 at 01:26 PM

No problem, thanks for being patient with me. If I modify the BT so it goes selector -> sequence -> (MoveTo, Sound) it still only executes the MoveTo.

avatar image MieszkoZ STAFF Feb 25 '15 at 01:52 PM

Looks like a bug then. I'll file it and have a look. If it's serious (and sounds like it could be) I'll try squeezing it in for 4.7.1. Thanks for reporting it!

avatar image twodice Feb 25 '15 at 01:53 PM

Thanks for your help!

avatar image MieszkoZ STAFF Feb 25 '15 at 03:10 PM

I gave it a go and it did work. I've reused someone else's project exhibiting a bug to test it. I'm attaching it so that you can spot the differences in setup. Hope it helps! Let me know.

bttest.zip (3.7 MB)
avatar image twodice Feb 25 '15 at 09:33 PM

Could something be wrong with my navigation mesh/system/configuration? If I set the acceptable radius to 1000000000.0 it still moves the pawn to the target location and stays inside the MoveTo node.

If I add an obstacle to the middle of the navmesh, it seems to get stuck on the MoveTo only if the pawn didn't get anywhere near the obstacle. If I move it such that it stops near the obstacle (but not so close that it can't reach the desired position) it escapes the MoveTo node and plays a sound.

Is there a simple way to debug what's going on inside MoveTo?

avatar image twodice Feb 25 '15 at 11:12 PM

I figured it out using the visual logger:

Despite the fact that I set the target location's Z coordinate to the Z coordinate of the actor (it's constrained to a single plane), it seemed to think that it was about 100 units off in the Z direction each time it ran MoveTo. If I hard-code the Z destination to -94, it works fine. (Though it does seem to move the actor such that the edge lines up with the destination, not the center)

avatar image MieszkoZ STAFF Feb 26 '15 at 10:56 AM

One thing to note is that we project goal locations to navmesh before calculating paths - maybe that's what you're seeing as a Z offset.

Do you need more assistance with this? If so, can you supply us with a stripped-down version of your project? Or at least share your navigation system's configuration (like your ini files for example). Project would help more of course ;)

avatar image twodice Feb 26 '15 at 01:41 PM

It would help to know what it uses for the position of the actor. It seems to me like it's using the center-ish of the actor to calculate distance, but using the base of the actor to calculate its location in the editor. (The ~94 unit offset is almost exactly the distance between the arrow doodad in the actor to the base of the actor)

avatar image twodice Feb 26 '15 at 09:39 PM

I think I fixed it: 1. get the target location 2. project the hit result onto the nav mesh with Project Point to Navigation 3. path to that instead of the target location

I've got a much better understanding of how this stuff works now, thanks!

avatar image Xanen Mar 04 '15 at 08:44 PM

Hi Mieszko- Post-4.7 I believe I'm seeing a slight change in behavior in path building. As you mention "we project goal locations to navmesh before calculating paths". When I look at the pre-4.7 path, all of the path points are projected as expected. Post-4.7, all of the path points are projected except for the last one, which retains the original goal location Z. I believe that's why we may be seeing a variety of issues like this one and (https://answers.unrealengine.com/questions/182947/ai-actions-have-unneccessary-delay.html ), where move requests are failing out due to incorrect Z values. I'm fairly confident that projecting the goal location to the navmesh before issuing the move request will solve the problem, but it's unclear if this change in behavior is by-design or a bug.

avatar image MieszkoZ STAFF Mar 05 '15 at 04:04 PM

Thanks for reporting it, I'll look into it soon. Cheers!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question