Well, this can be achieved in any game. Calling the function ‘MoveTo’ on Humanoid makes the humanoid go to the position; however, it stops before reaching the exact position.
Currently I have a code that tells the Humanoid to walk to a Target and if the distance between the NPC and the Target is less than a certain distance, then he just stops moving and attacks. However; the issue here lies on the NPC never reaching the Target’s position and just stops prior reaching it.
This issue is not caused because of the 8 seconds timeout, neither is anchored.
Code:
if (NPCPosition - TargetPosition).Magnitude > Radius then
Humanoid:MoveTo(TargetPosition) --> This is useless since the Humanoid literally just doesn't move, it stays there.
else
print("Attack!")
end
Expected Behavior
I expect the Humanoid to reach the exact position, if possible, in the axis X and Z.
Actual Behavior
The Humanoid never reaches its goal position. It stays at some “random” studs from it and is tedious since I am expecting it to move in that exact position and stop at the right spot. Sometimes is even 1.5 studs behind the actual position and even if you call MoveTo again it just doesn’t work because the Humanoid decides to not move.
Look at the distance, between the Position passed to MoveTo and HumanoidRootPart’s position:
Workaround
I just extend the distance checks, but this literally breaks the behavior I want since sometimes the Humanoid does reach its goal position making it an issue if I do this.
Issue Area: Engine Issue Type: Other Impact: Low Frequency: Often
(I tried searching for this issue and nothing related to it showed up; please link me a post if you found it to delete this)
No, is not anchored, the humanoid is following me, and he is supposed to stop right before reaching me and attack. However, since the distance between me and him is never accomplished because he stops prior reaching the exact distance, he just doesn’t attack.
She is supposed to reach that position (red mark), however, is stopping prior reaching it. Is a Humanoid bug since this issue does not occur with AlighPosition.
The behavior of MoveTo still remains the same. The last time I recall it being updated is when they stopped requiring the “Part” parameter. Does adding the parameter fix the issue?
Additionally, the Humanoid will move to the part or position just enough to get the model in-bounds with the target.
However, I cannot determine whether this is intentional or not due to the documentation being unclear. In other words, it is up to the software engineer to decide whether this is intentional or not.
For a workaround, you could attempt to use the newer Move instead of MoveTo.
Since Move kinda works like if you were applying a velocity to a part. (Just that WalkSpeed is already the one used * the direction provided). The Humanoid could move depending on how high his speed is passed the target position(meaning I would have to teleport him all the way to the position). I also have to track until he reaches there to stop him, instead of a MoveToFinished.
Is there a work around for the Target passing it’s position because of his speed (without teleporting him back)?
I haven’t tried that parameter for it, but if I were to do so I guess I will have to create a part every time I want to make any Humanoid move to a position then. (Since they just follow the part and using the same one for everyone would cause issues)
This is what I thought at first, but I hope it isn’t and is just a precision bug. Just like Constraints (AlignPosition for example) that can have sometimes some really small studs in difference.
Ok so, let’s say you make it move to that direction and the speed of the Humanoid is 60. If you make a code that checks every heartbeat if the humanoid has “reached” that position by using Magnitude, it won’t be accurate since physics already made him move even further. You know what I mean? Like he is running 60 studs per second (It depends on how many times Heartbeat triggers per second), and he can pass the point you want him to reach.
In the main post I said: “I just extend the distance checks, but this literally breaks the behavior I want since sometimes the Humanoid does reach its goal position making it an issue if I do this.”
In other words, he could get closer to me if he decides to move completely, which is what I don’t want.
By the way, I just tried with a Part and the issue persist. I wish it were to behave like AlignPosition and stop right in the position you want it.
If the Humanoid’s speed is too high, he will pass the position with MoveTo: WalkSpeed = 120
With AlignPosition is not an issue at all, he goes right to the part. I am wondering on whether to make a feature request instead…
I see what you mean, but it is also possible to calculate this out, since Move doesn’t need to use all of the walk speed if it is lower than a unit vector.
Let’s say you have a Humanoid with a walk speed of 60, and it is 1 stud away from the part. Instead of calling Move(Vector3.new(0,0,1)) you do Move(Vector3.new(0,0,0.015)) and it lowers the walk speed for only the movement.
However, it seems to be more accurate if I change the density of the body parts up. Maybe try that?
You could try, but you would probably need to request for a new method or for a change of functionality.
Hi, is there an update regarding this bug? It is also happening to me in my experiences and the only workaround is to just increase the distance checks… making character path finding less precise and accurate.
same this bug sucks… (for the character limit)