How to Force Enable Shift-Lock (Without changing the PlayerModule)

It does replicate, the client has control (Network ownership) over their character, therefore the BodyGyro rotates it just fine.


Why all this when you can easily make the HumanoidRootPart look towards the camera’s CFrame.LookVector? (It’s not to offend, but I just wanna know the reason you prefer using a BodyGyro and looking at the mouse’s pointer instead of where the camera is looking).

1 Like

The BodyGyro is what rotates the HumanoidRootPart, so we won’t have to do the CFraming. It also has properties so the turning can be customized (like how quickly, and etc), and is easy to disable from other scripts.

As I already “messed” with the mouse to put it in the center, it just came naturally to me to rotate to the mouse (since it’s already in the center).

It is most definitely possible with the Camera too.
Just for the sake of possibility, here you go :stuck_out_tongue::

rotation.CFrame = workspace.CurrentCamera.CFrame

Same result as:

rotation.CFrame = mouse.Origin

Don’t worry, none taken :ok_hand:


Often, when the mouse is in the center, and you rotate, the Mouse and Camera’s look Vector are often equal:

print(mouse.Origin.LookVector == workspace.CurrentCamera.CFrame.LookVector)


1 Like

I see, makes more sense. I prefer using CFrame instead of using BodyGyros, but it’s just a preference of mine. Great guide still, especially for new developers who wanna have an over-the-shoulders camera. :wink:


why does it show a weird rotation when walking:

Are you walking backwards? The rotation seems to be normal (I can’t determine as I don’t see the face).

Shift Lock is a state that makes the character face to the direction the Camera is facing, so the character is rotating on camera move.

What do you find weird in this rotation?

yes, look how the torso rotates…

1 Like

it rotates a weird angle rotation that is not supposed to rotate, try walking back wards its supposed to look straight, but thats not what happing here

1 Like

That’s strange, not 100% sure why. The character seemed to be rotated correctly when standing, but rotate strangely backward.

However, I do not think that is a replication issue. Probably just the force coming from the walk.
I’ll try to resolve it.

Edit (April 2022):
This issue no longer occurs with the new version of the tutorial.

1 Like

i never said it’s replication problem btw, tho i can’t wrap my head around how to solve it i tried change the angle based on the move direction but it would ruin forward walking.

I have a few ideas in mind to fix the issue. I will update the guide and let you know when I am able to try them.

July 7th update: Still no solution. However, the turning seems to just be visual, not actually changing the direction of the walking

1 Like

no this was old i was asking before i impelement it it was the first time me seeing this. this has nothing to do with my second questions like my first question doesn’t relate to my second one.

yeah sure good luck fixing it.

I like this but it would be better if you put it in a module

local LockModule = {}

function LockModule.ShiftLock(Active, Plr, Character)
	local mouse = Plr:GetMouse()
	local hum = Character:WaitForChild("Humanoid")
	local rotation ="BodyGyro")
	rotation.P = 1000000
	rotation.Parent = hum.RootPart
	local conn
	if Active == true then
		hum.CameraOffset =,0.5,0) 
		rotation.MaxTorque =, math.huge, 0) 
		conn = game:GetService("RunService").RenderStepped:Connect(function()
			rotation.CFrame = mouse.Origin
			game:GetService("UserInputService").MouseBehavior = Enum.MouseBehavior.LockCenter
	elseif Active == false then
		hum.CameraOffset =,0,0) 
		rotation.MaxTorque =, 0, 0) 
		warn("Camera has been Unlocked or has been unlocked")

		if conn then conn:Disconnect() end 

return LockModule

I’ve been criticized a few times for using ModuleScripts rather than functions in tutorials.

The module mentioned wouldn’t work as :GetMouse() and UserInputService only work in local scripts, making the player parameter meaningless.

You sould fire a remote event to the player instead.

Thanks for the suggestion :blush:

1 Like

But the module does work

The script would be called from the client


Ah, I see :slightly_smiling_face:.
Just letting you know there’s no need for the Plr parameter because it only works on the local player.

Does it also deactivate? (The connection variable you made is local, I do not think the connection disconnects properly).

(I do not mean to offend, just wondering whether it works properly with the module you sent and suggesting some)


Well you were right about the disconnecting any suggestion

(Also you didnt offend me lol)


You can create the connection variable outside of the function.

And instead of creating the BodyGyro every time the function runs (will work only when active is true), check if the humanoid root part has it (when active is false), because then you create a disabled BodyGyro, instead of disabling the current one.