Issue With ChooseNextWaypoint

Unreal Courses Ask
,
#1

@ben @sampattuzzi
Hey guys!
I’m really loving the course so far! Right now I am having an issue with Choose next waypoint. I got to the Sub Behavior Trees lecture and realized my guys have an issue when patrolling. This issue has actually been happening for me since we first started using choose next waypoint it just never caused a problem till this lecture. When patrolling, once they reach their target, they wait on their own for a few seconds even though I haven’t given the command before cycling to the next target. Well the real problem is that it isn’t allowing me to execute any animations they just keep patrolling. When I check on the black board data it isn’t showing that the waypoint indexes are being cycled. However if I break the link to choose next waypoint in the behavior tree they wont move. I put a print string in the choose next waypoint blueprint, one for initiated and one for succeeded, neither are being triggered. What is funny is I downloaded your repo and checked out to the same lecture copy and the issue with waiting is fixed but what is interesting is that I put the same print commands in that version of choose next waypoint as I did in mine and it still isn’t reporting that it is being initiated. I am curious as to what I did different in my version to cause the self waiting issue and why in niether my version or yours that the choose next waypoint blueprint isn’t reporting any activity when print commands are put in the execution flow. Here is a link to my github repo:

Thank you so much.

#2

They can’t get to the target points because they’re in the air. If you put them on the ground (select it and press the “end” key) then it works fine.

Also I had trouble cloning your repo, however I found the solution here

// Skip smudge - We'll download binary files later in a faster batch
git lfs install --skip-smudge

// Do git clone here
git clone ...

// Fetch all the binary files in the new clone
git lfs pull

// Reinstate smudge
git lfs install --force
#3

Ok I just tried that and the blackboard keys seem to be cycling between target points and indexs now but the animations still are not being executed. Were you able to clone it? I am right about to push the last couple changes I made.

#4

How are you intending to execute them? With the BehaviorTree? Because this is what I’m seeing in your behaviortree

2016-12-10 17_08_09-TestingGrounds - Unreal Editor.png727×426 27.1 KB

1 Like
#5

Yes I am trying to push the changes that reflect that but source tree is giving me a bit of trouble randomly. Here is a screen shot of it.

Patrol.png786×528 50.5 KB

#6

Seems to be working fine on my end

1178×424 95.6 KB

#7

That is directly from the clone of my repo? How Strange because on mine they just keep patrolling and never execute the animation. I wonder what is different on my end that could be causing this. I tried running a get clean (ignoring the starter content and the character I added) and still the same issue.

#8

What exactly is the problem with git? Is it pushing it to github?

#9

fixed my issue with source tree just had to restart. Pushing changes now. I have to go to work now but ill be back in 6 hours. Can wait to see what every body has to say about this!

#10

Your targetpoints are still in the air, putting them on the ground enables the animations. However Prone_To_Stand is set up to be Link’s Prone_To_Stand and Stand_To_Prone is set to the UE4_Mannequinn’s Stand_To_Prone. So both will be in a T-Pose during the other ones animation. i.e. Link will be T-Posed during the STP and UE4_Mannequin will be T-Posed during PTS.

#11

Ok I see what you mean. I thought you meant the characters needed to be on the ground. Target Points are now on the ground and as you said they now execute animations but are doing the thing with T-pose you mentioned. How can I work around this.
I pushed the changes to git hub.

#12

Also I just Went and tried taking the UE4_Mannequin out of the scene and Link is still doing T-Pose. So dose the UE4_MAnnequin when I put it back in and take Link out. What is odd is they are doing the T-Poses in different order. i.e. Link gets to his Target point and skips the “stand to prone” animation and goes right to “prone to stand” then does the T-Pose then starts moving to the next target. Whereas the Mannequin gets to the target and goes right to the T-Pose then executes the “stand to prone” animation then skips the “prone to stand” and starts moving to the next Target.

#13

I think you should re-read my reply.

It’s late so I’ll go over it tomorrow morning but I suggest you look into the skeletal meshes and the anim blueprints

#14

Got it. I’ll look into that tonight and we’ll collaborate tomorrow. Thank you for all your help.

#15

SOLVED!! The problem was that the behavior tree was running the animations specifically for the Mannequin skeleton. I added a separate Behavior Tree for link that calls for his skeletons specific animations and I used the Retarget Manager to Prefix all Link’s animations with Link_ so I could tell them apart. Then to distinguish which tree to use I added a script to NPC_AI_BP to determine which skeleton the possessing pawn is using it looks like this:

992×503 85.6 KB

I added the yellow.

It’s not pretty especially if I want to add any more characters. I’ll work on trying to find a more dynamic way that dosn’t require any static string references that I type or multiple behavior Trees.
Any suggestions would be great.

#16

Yeah, that’s what I meant by

#17

Thanks for all your help Dan

Privacy & Terms