Clarify Humanoid:MoveTo() Parameters

Help and Feedback Scripting Support
1

Trying to understand the exact mechanics of the parameters for Humanoid:MoveTo(). Can someone please help clarify?

An informative example of the Script that would generate the animated GIF on the Humanoid MoveTo API Reference Page would be great! Frankly, I’m disappointed the only code snippet on that page does not correspond to the obviously interesting and hopefully useful animated depiction, instead choosing to omit the Part parameter and ignore the idea of a dynamically changing WalkToPoint.

I’ve tried the following examples, which seem to produce contradicting results (?):

-- 1)
-- Walks to roughly 8 studs from finish.position
-- finish.position offset by 8 studs in the Z-axis
dummy.Humanoid:MoveTo(finish.Position - Vector3.new(0, 0, 8), finish) 

-- 2)
-- Walk to world space Origin (0, 0, 0) 
-- Why doesn't this walk to finish.position (offset by 0, 0, 0)?
local zeroVector3 = Vector3.new(0, 0, 0)
dummy.Humanoid:MoveTo(zeroVector3, finish) 

-- 3)
-- Walks to finish.Position literal world space
-- Why doesn't this walk to finish.Position offset by finish.Position?
dummy.Humanoid:MoveTo(finish.Position, finish)

Maybe this page could be more verbose about the logic used in the only two (2) possible combinations of parameters?

  1. Humanoid:MoveTo(location)
  2. Humanoid:MoveTo(location, part)

Is the location parameter a Worldspace location when part is nil or not specified, but then inexplicably location is an offset from part when part is provided as a parameter?

May seem like a noob question, but why do I still have this question at all after both reading the docs and trying it out myself?

3 Likes
2

This is really interesting, maybe the logic behind it has more rules that are not told in the wiki, for example maybe if the position parameter was set to (0, 0
, 0), then :MoveTo() doesn’t actually let you do that so it ignores the part parameter, and maybe the position and part parameter can’t be the same thing, just like CFrame; you can’t have a cframe that has the same position for the position vector and lookvector.

CFrame.new(part.Position, part.Position) --this doesnt work and has a weird behaviour.

Can you print the WalkToPoint, WalkToPart and the character’s position at each example, that could help us make some rules and explain the logic.

And this is totally not a noob question this is infact very interesting

1 Like
3

Print Snippet:

start.Position = Vector3.new(-20, 0.5, -10)
finish.Position = Vector3.new(20, 0.5, -10)
-- ...
print(
	tostring(dummy.Humanoid.WalkToPoint), 
	tostring(dummy.Humanoid.WalkToPart), 
	tostring(dummy.HumanoidRootPart.Position)
)
print()

Output:

0, 0, 0 nil -20, 0.5, -10

20, 0.5, -10 nil 19.0647449, 3, -9.99951077

0, 0, -8 finish 19.9117737, 3, -17.1045246

-20, -0.5, 10 finish 0.652632415, 2.99902248, -0.563219845

0, 0, 0 finish 19.2844601, 3, -9.64599419
4

Here is the test place I used to produce this output:

Test Humanoid MoveTo.rbxl (23.2 KB)

Script is painfully linear and verbose on purpose.

5

The name of the argument WalkToPart is misleading. I performed some tests on it years ago because I had the same question as you. As it turns out, WalkToPart is actually the part whose CFrame the WalkToPoint is relative to. For example, if you set the WalkToPart to the character’s HumanoidRootPart and told the Humanoid to walk to point (0, 0, 10), it would walk 10 studs forward.

6

If that’s true, why does

local zeroVector3 = Vector3.new(0, 0, 0)
dummy.Humanoid:MoveTo(zeroVector3, finish) -- Origin instead of finish.Position

walk to the Worldspace Origin (0, 0, 0) instead of to the WalkToPart.Position with relative offset of 0 studs which should reduce to the unaltered WalkToPart CFrame?

7

Hmm, sorry, I’ve forgotten some of the details since it has been so long. Only changes in the Parts CFrame matter, and it may be that only the rotation makes a difference. So to curve a Humanoid’s path while they walk, rotate WalkToPart.

8

Thanks for responding. I follow that changing the CFrame of the WalkToPart changes the WalkToPoint, but not clear how that answers my question.

1 Like
9

I am not that experienced In this type of stuff but here Is an article that could help you:

10

Yes, that’s the one I link to in OP in this thread. I’m saying that page is does not explain the answer to my question after reading the page and trying the examples I show here.

2 Likes
11

Found the source of weirdness in examples – 2) and – 3) in my original post above.

For some in unexplained and hard to imagine reason, the part argument is ignored until part’s CFrame changes in anyway.

Humanoid:MoveTo(location)
Walks toward Vector3 location as an absolute Position in World space.

Humanoid:MoveTo(location, part)
Ignores part parameter initially and walks toward Vector3 location in World space, until part CFrame changes, at which time the Vector3 location immediately switches from absolute World space Position into a relative position offset from part position.

Why this sudden change in behaviour? Why not initially treat location as a relative offset so that the function is consistent at all times?

5 Likes