In 4.7.1 AAIController::MoveToActor() doesn’t really automatically updating its moving target position like it use to.
I’ve tested using AAIController::GetImmediateMoveDestination() and it seems to only be updating once it reach the first partial target in its path. Wierd yet, after that my AI running back and forth between its original position and next points along its path.
Will this be fix soon?
Hey -
Could you elaborate on how MoveToActor() is broken? Are you seeing different behavior between projects when using it? Is it a difference from one engine version to the next?
Additionally, how are you making the call to MoveToActor()? Knowing how you are using the function will make it easier to reproduce what you’re seeing versus what is expected and help us find the cause of the problem.
Cheers
Yes, .
This function worked very well in 4.6, but severely bug as mention above after we moved to 4.7.1. To sum it down, My c++ MoveToActor(Actor* TargetActor) is called once on each of my AI monster when they see a player. After that HasReached() is called to check and see whether target has been reached.
Best,
Hi,
I can confirm this, I´m running into this problem, also.
The result of the MoveToActor() returns “RequestSuccessful” after the AIController stops the moving Pawn. In 4.6 it returned “AlreadyAtGoal” if the target AActor was already reached.
EPathFollowingRequestResult::Type MoveEnum = MoveToActor(BestUnit, UnitData.AttackDistance);
I had some strange circumstances where “AlreadyAtGoal” was still called. I´ll post two screenshots of my Debugging.
For Debugging I´m printing “AlreadyAtGoal”, if the return is appropriate.
In my game I got some units running to a building (to attack it).
First they pile up (which is fine) but “AlreadyAtGoal” is never called.
Then after a bunch of them piled up, some of them get shoved near the building and they call it then.
Edit: I´m only running into this, when the AI moves to this specific building. I also got a smaller actor with a box instead a cone as mesh where MoveToActor() works fine. The cone uses a “Box Collision”.
Edit 2: Atleast in my case the MoveToActor() seems to have a problem with the size of the cone Static Mesh. Scaling it up or down resolves the mentioned issue for me. Still no clue why tho.
How did MoveToActor() changed with 4.7? I could only find a change regarding MoveToLocation()
Fixed AI Controller’s MoveToLocation misusing “Stop on Overlap” while testing if AI is already at the goal location
Could it change the behavior as mentioned?
Awesome explaination!
In my case though, I used MoveToActor for a movable actor. So I’m not sure if this is the same bug. Wish you luck on your case though. 
I found the 4.7 Bug!
It seems that when you set bUsePathFinding=false in MoveToActor(), the AI will no longer update its destination on Moving Actor.
Spent the whole day rewriting our AI code to find the bug. Hope someone help clear this bug soon.
Hi ,
Sorry for the delay in responding to your post. A ticket was recently created that should address the issue that you described (UE-11891). We hope to have this ticket completed and added to a release version of the Engine very soon.
Hi ,
I am trying to get a reproduction of this in 4.7.2, but I am getting different results. I am using blueprints to make simple tests where an AIController uses a tick event to trigger a Move to Actor function with Use Pathfinding on false. I then make the goal an object in the scene that I move during simulation. The actor is following the object as I move the locations. Does this seem like a similar test to what you are doing when the bug occurs? Any details on what I may be missing or steps I have reproduced incorrectly may help.
Could you tell me what you meant by “it seems to only be updating once it reach the first partial target in its path.” What is the partial target and what is its purpose? Are you using Behavior Trees or just AIControllers?
To add some further info on this. I have a simple behavior tree setup where I use the MoveTo task, passing as the target an object blackboard key with an object type of an ACharacter-derived class. This branch of the tree is currently the only one which can execute, so as soon as the MoveTo completes, it reenters the branch with the same target still set in the blackboard. I’ve put debug tasks either side of the MoveTo (in a sequence) which draw a sphere at the location of the target before the move, and a sphere at the location of the AI after the move. The target is in constant motion.
The AI is just moving to the location where the target was at the point MoveTo was invoked. Only when the branch is reentered and MoveTo is called again will it update it’s destination. So the result is, it chases the target, but in a delayed fashion, each time moving to a point somewhat behind the target’s current location.
I’m using 4.7.3
Thank you for that additional information. We believe this will be fixed in an upcoming hotfix. Please let us know if this is still occurring for you after 4.7.4 is released. If so, we will be happy to further assist.
In 4,7.4, when you set bUsePathfinding=false, the whole MoveToActor() function stops working.
Hi ,
Do you still see this same behavior in 4.7.6? I ran some tests in 4.7.6 and 4.7.4 and the AI moved towards its target Actor, but didn’t avoid obstacles in the way. I believe this is to be expected with bUsePathfinding set to false, since the AI isn’t able to find a path around the obstacle. When you say the function stops working, do you mean the AI doesn’t move at all?
Hi ,
We have not heard back from you for a few days. If you are still having trouble with this issue, could you please provide more details of the results you are seeing? I will be marking this post as resolved for internal tracking purposes, but please feel free to add a comment and re-open the post at any time.
