Getting a movedirection independent of the way the humanoid is facing?

I’m working on a climbing system that utilizes humanoid.MoveDirection to make the player climb in a certain direction

The issue is that climbing will lock the players model into one direction, which seems to affect Humanoid.MoveDirection (I want to keep players facing the wall preferably)

(For example, going forwards would normally climb the player upwards, but if the player looks to their right or left, they will climb significantly slower)

local PlayerCameraDot = (script.Parent.HumanoidRootPart.CFrame.LookVector:Dot(workspace.CurrentCamera.CFrame.LookVector)) --Gets the difference between the character lookvector and the camera lookvector
	
local negator = 1
if PlayerCameraDot >= 0 then
	negator = -1
elseif PlayerCameraDot < 0 then
	negator = 1
end
local ClimbDirection = (Vector3.new(Humanoid.MoveDirection.X, Humanoid.MoveDirection.Z * negator , 0))
print(ClimbDirection)
	
Holder.VectorVelocity =  (ClimbDirection * Vector3.new(Humanoid.WalkSpeed, Humanoid.WalkSpeed, Humanoid.WalkSpeed))

Sounds a bit like strafing. If this is not the case I apologize.
Default R15 Player Animations Now Include Strafing and Backpedaling [Beta] - Updates / Announcements - Developer Forum | Roblox

TL:DR.

Don’t entirely think that applies for this situation unfortunately (that and my game is R6)

Well… roblox is a physics engine, and physics are sometimes hard to emulate. It might be a floating point error.

It isn’t, I don’t think floating point errors would affect this

Is there division involved? Divisions are sometimes kinda broken. Also are you sure you used the correct set of data? There was some weird bug when I tried to find the CFrame.Rotation. Also errors also exists within rotation coordinates.

If I haven’t remembered incorrectly the first three were junk data. The other three was that real direction the player was facing.

There is no division, I’m getting vectors, multiplying, and doing dot and that’s about it

It’s that humanoid.movedirection is apparently locked to the character and not the camera

Vectors contain division which could lead to errors.

(Deleting to reword the topic)
NVM I can’t :sob:

Ok using Controller:GetMoveVector seems to work for my case

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.