Help on moving part relative to HumanoidRootPart

Im trying to make a system using Ik controls. Everything has gone smoothly, except I struggle to find a solution on how to make a part (attachment) move in the same direction as the humanoid root part

I have a Move Offset (x,y,0) that works successfully as listed below.

HumanoidRootPart.CFrame * CFrame.new(MoveVector).Position)

However, using this approach on my attachment will have a different outcome, and instead the direction of the attachment varies depending on where the player is facing.

Im requesting a solution to this problem. I believe It’s probably an easy solution, but Ive been stumped on this for a bit.

Here’s an example resembling the effect I want:

image

Thanks!

You seem to be multiplying a CFrame and a Vector3, maybe that causes some issues?

It seems to work fine for the Hrp?

Can you send the full line of code for more context?

Its quite a big chunk of code, but here’s some of it

local HrpPos = WallCast(Player,(HumanoidRootPart.CFrame * CFrame.new(MoveVector).Position)) -- Returns a RaycastResult
			
			
			if HrpPos then
				local Side = Sides[GetActionState(Player).Other.Side]	
			
				--//CurrentFoot,Hand,etc just returns a table with a IKControl, and Attachment
				local CurrentHand = PlayerIKs[Player.UserId][Side.Hand]
				local CurrentFoot = PlayerIKs[Player.UserId][Side.Foot]
				
				local AlternateHand = PlayerIKs[Player.UserId][GetAlternatePart("Hand",Side.Hand)]
				local AlternateFoot =  PlayerIKs[Player.UserId][GetAlternatePart("Foot",Side.Foot)]
				
				local Strafing = false
				
				if MoveVector.X > MoveVector.Y then
					Strafing = true
				end
				
				CurrentHand.Target.CFrame *= CFrame.new(MoveVector) --// What im trying to do, not working.
				
				Part.CFrame = CurrentHand.Target.CFrame --// To visualize, same bug
				
				
			
				TweenService:Create(HumanoidRootPart,TweenInfo.new(0.7),{Position = HrpPos.Position}):Play() -- I just tween it

You use ToObjectSpace to Apply the CFrame Relative to HumanoidRootPart

1 Like

You might have misplaced the end of a pair of brackets here. Try this:

local HrpPos = WallCast(Player, (HumanoidRootPart.CFrame * CFrame.new(MoveVector)).Position)

I dont think this matters much, since this is the part thats working as intended

Could you please provide an example?

It should something like this (As far as i know)

yourCFrame:ToObjectSpace(otherCFrame)

The CFrame properly of Attachments is relative to the BasePart it’s parented to, while the CFrame of a BasePart is relative to the world.

You might not need to move the Attachment: if it’s parented to the HumanoidRootPart it will move with it already.

If you do need to move it, here is some code I think should work:

-- code should replace attachment.CFrame = attachment.CFrame * moveByCFrame

local attachment
local moveByCFrame

local relativeToCFrame = attachment.Parent.CFrame
local endCFrame = attachment.WorldCFrame * moveByCFrame

local relativeCFrame = relativeToCFrame:ToObjectSpace(endCFrame)
attachment.CFrame = relativeCFrame

Seems to have an identical outcome when changing the MoveByCFrame to CFrame.new(MoveVector)

This might be an x,y problem scenario so let me just state what im doing

Im trying to make a climbing system.

I get the moveVector from the client via:

local Vector = -PlayerModule:GetControls():GetMoveVector() / 10

Then I Manipulate this so it works how i want it (since we dont want the player going in the wall)

MoveVector = Vector3.new(-MoveVector.X,MoveVector.Z,0)

Then I make the humanoidRootpart positioning,etc. the positioning of the humanoidRootPart appears to be accurate and doesn’t change according to the side the wall is on etc. However, the Attachments do.

(Attachments are parented to Terrain)

Edit, might be useful to say that there are 4 attachments ( 2 legs and arms) which start in positions similar to where the limb is, but higher

1 Like

I’m not sure what the problem is.

I think it would be easiest to just put the attachments inside their own parts. Putting them in Terrain might end up a little messy with a lot of players anyways.