Why would you want to move at (0.5,0,0.5) instead of (0.7,0,0.7)? Assuming that you want to move at one stud per second, the speed of the first one is sqrt(0.5^2 + 0.5^2) ~~ 0.7071 while the second one is sqrt(0.7^2 + 0.7^2) ~~ 0.9899
I do not want the player to move at that speed, I only want the movement vector to be (0.5,0,0.5) diagonally because I’m using it to blend 4 directional animations (Forward, Backward, Left and Right) by setting their weight to the direction. The problem I’m having is that when the player is moving diagonally, two animations have a weight of 0.7 which makes the diagonal animation look barely different from the sideways animation, if they were both at 0.5 it would look much better.
Yes, this works fine, but the vector can only be 1, 0.5 or 0, for example even if the player moves forward slightly your function sets vector.Z to 1 immediately instead of 0.1 or whatever the actual speed of the player is. Is there any way to fix this without lerping/tweening?
@buildthomas yeah, but the problem with that is if the vector is (0,0,0.2) and I divide by the sum, it returns 1 instead of 0.2, giving the problem described above.
This is impossible, since MoveDirection works on the unit circle, we can prove that using the following:
Let x = 0, y = 0.2
x^2 + y^2 = 1
0.2^2 = 1?
That’s incorrect, so (0, 0.2) does not lie on the unit circle.
Now that we got that out of the way, using the method @buildthomas mentioned.
local notMoving = Vector3.new()
local function unitCircleRatio(v3)
if v3 == notMoving then
local x = math.abs(v3.X)
local z = math.abs(v3.Z)
local sum = (x + z)
return Vector3.new(x/sum, 0, z/sum)
local humanoid = script.Parent:WaitForChild("Humanoid")
while wait() do
What I’m trying to say is that when the player moves even a little bit, with your function it snaps the vector to 1 immediately, but without it it doesn’t do that. I want to know if there is another formula to make the speed go up incrementally instead of snapping to 1 or 0.
With your function:
Without your function:
As you can see it does not snap to -1 immediately when the player moves forward, but also has steps inbetween.
(sorry for the low quality, giant video, it was made with gyazo gif)
I assume by length you mean .Magnitude and the movement vector is the one before it is passed into the unitCircleRatio() function in @Darkmist101 post. If so then that defeats the purpose of me doing this calculation in the first place since multiplying it by the length of the original movement vector reverses the calculation and multiplying by the length of the new movement vector does nothing.