How does climbing work for X Position?

[Wyzloc]

I don’t understand what you’re saying

[KJry_s (MalleoZephyris)]

You’ve to make a transition between the movement, because the player is now just teleporting 1 stud to the left/right.

[Weldify]

Do you go in the right direction with my method?

[Wyzloc]

I can show a gif real quick here it is:

[Weldify]

Is this the same error you had before?

[Wyzloc]

Nah after the latest code you sent it stopped erroring, now it just does that every 5 seconds. Here’s code now:

while wait(5) do
			local CheckPart = Ray.new(Root.Position, Root.CFrame.LookVector*1.5)
			local Part, Pos, Pos2 = workspace:FindPartOnRayWithIgnoreList(CheckPart, Root.Parent:GetChildren())
			if Part then
				local up, left, down, right
				if UIS:IsKeyDown(Enum.KeyCode.W) then
					up=1
				end
				if UIS:IsKeyDown(Enum.KeyCode.S) then
					up=-1
				end
				if UIS:IsKeyDown(Enum.KeyCode.A) then
					right=-1
				end
				if UIS:IsKeyDown(Enum.KeyCode.D) then
					right=-1
				end
				BP.Position += Root.CFrame:PointToObjectSpace(Vector3.new(right or 0,up or 0,0))
			else
				Hum.AutoRotate=true
				PlayerClimbing=nil
				BP.Parent=nil
				break
			end	
		end

I’m pretty sure it’s just the setting part for the bodypositions position, because it happens every 5 seconds and the bodyposition is literally the only thing manipulated in that loop.

[Weldify]

Replace += with ==, this should fix it.

[Wyzloc]

That doesn’t work == isn’t a way of assigning the code. It’s just used to compare statements, I tried that though and got the expected error.

[dthecoolest]

Analyzing the video it seems the “fling” is actually the body position moving in one direction particular point which seems to be the origin (0,0,0), to confirm it you could continuously print the BP.Position to further debug it or use the Lua debugger to monitor the variable.

More information will be needed especially on how you create the BodyPosition when you first begin the wall climbing.

In fact, this entire chain of replies can be solved if you debug the vectors of the change in position via print statements yourself to see if the positions being set to make sense or are changing drastically.

[Wyzloc]

No, because when I changed from PointToObjectSpace, to PointToWorldSpace, it worked the way it was supposed to. Just for some reason it doesn’t want to work for PointToObjectSpace no matter what.

[dthecoolest]

Ok, I think I understand the issue with the point to object space. The position of the Root.CFrame is affecting the PointToObjectSpace since Point to object space is just as the wiki on CFrames:

Vector3 CFrame:PointToObjectSpace ( Vector3 v3 )
Returns a Vector3 transformed from World to Object space. Equivalent to [CFrame:inverse() * v3]

When you inverse a CFrame you also inverse the position of the CFrame. This causes the BodyPosition to go back to the origin. To prevent this from happening we subtract the position to the CFrame before inversing it.

local RootCFOrientationOnly = Root.CFrame -Root.CFrame.Position
local movementWorldVector = Vector3.new(right or 0,up or 0,0)
BP.Position += RootCFOrientationOnly:PointToObjectSpace(movementWorldVector)

This will make the additional vector relative to the orientation of HumanoidRootPart and not the position.

Honestly, I believe using @Luacathy method of using the HumanoidRootPart Rightvectors would be easier but eh your choice.

[Wyzloc]

Alright, that actually worked which is very helpful. But since this topic is ‘How does climbing work for X Position?’ I can’t put it as solved until this one last issue is fixed.

So the last problem is that each side is different for A, D keys. D/A is always supposed to move Right/Left, but sometimes they switch around.

Also by “Sometimes they switch around” what I mean is on each surface of the wall sometimes you move left instead of right when pressing D, and same for A.

[dthecoolest]

Sorry, no idea what “right” and what “left” you are talking about.

Currently, “right” and “left” are relative to how the humanoid root part is facing the wall.

Are you looking to make it relative to the camera like in a 2d platforming game? then you can get the movement direction in camera space using this function I nicked from @ThanksRoBama or something like that.

@ThanksRoBama

local function getWalkDirectionWorldSpace()
	local walkDir = camera.CFrame:VectorToWorldSpace( getWalkDirectionCameraSpace() )
	walkDir *= Vector3.new(1, 0, 1) --Set Y axis to 0

	if walkDir.Magnitude > 0 then --(0, 0, 0).Unit = NaN, do not want
		walkDir = walkDir.Unit --Normalize, because we (probably) changed an Axis so it's no longer a unit vector
	end

	return walkDir
end

[Wyzloc]

right/left is the direction you go when you’re climbing up the wall.

[StrategicPlayZ (Strat)]

Just use CFrame.

(Root.CFrame * CFrame.new(1,0,0)).Position

[dthecoolest]

What right or left the current code should be defined right as the following vectors relative to how the humanoid root part is facing like below.

Also, I think you have a typo “right” should be either 1 or a negative one.

@Wyzloc

				if UIS:IsKeyDown(Enum.KeyCode.A) then
					right=-1
				end
				if UIS:IsKeyDown(Enum.KeyCode.D) then
					right=-1
				end

[Wyzloc]

yeah I already fixed that, if it weren’t fixed you’d always go in 1 direction. But yeah for some reason going right goes left and going left goes right on specific surfaces of the wall. And I’m not really sure how to fix this.

[dthecoolest]

Nice, more debugging. What do you notice about these

@Wyzloc

specific surfaces of the wall

Any video to share the issue with us?

[Wyzloc]

I mean if I showed a video it would just be as described. When you walk on one side of the wall then start climbing on it, you go right/left normally. But on specific sides it makes you go the opposite direction.

And by right/left I mean → and ← directional. X axis, like just 1 for right, and -1 for left.

[Weldify]

Whoops, just do a =. I misstyped…
It didn’t work because I told you to add on to the BodyPosition (+=), and by default BodyPosition.Position is Vector3.new(0,0,0).