Shift lock character look at camera

Help and Feedback Scripting Support
#1

Quick question: Does anyone know where’s the code from the shift lock control module where it forces the character to look at the camera’s direction? Apparently I’ve been looking for it but I couldn’t find it, or it doesn’t exist in the module?

Basically the code that makes the character to rotate tot where the camera is looking at as the following:
this

3 Likes
#2

Some months ago, i made a 3th person shooter game, it uses forced shift lock as 3th person.
I saw a post similar to this to activate/deactivate the shiftlock: (SOLVED)Toggle Shift Lock On and Off with script

In the post they show a function that toggles shiftLock, and that function is in a module in game:
StarterPlayer >> StarterPlayerScripts >> PlayerModule >> CameraModule [line 537]

Once i made the script that calls the toggleFunction, i unchecked “EnableMouseLockOption” in StarterPlayer, so that players cant shiftLock just by pressing shift.

1 Like
#3

It’s not difficult to make your own. Just remember to preserve the RootPart’s position and exclude certain rotations.

Here are two relatively simple methods to get what you’re wanting to achieve if used in a LocalScript:

Defining variables 

local Camera = workspace.CurrentCamera
local RunService = game:GetService("RunService")
local RootPart = script.Parent:WaitForChild("HumanoidRootPart")

Method 1

You can simply get the Y rotation from the Camera's CFrame and apply it to the RootPart like so: 
RunService.RenderStepped:Connect(function()
	local rx, ry, rz = Camera.CFrame:ToOrientation()
	RootPart.CFrame = CFrame.new(RootPart.CFrame.p) * CFrame.fromOrientation(0, ry, 0)
end)

Method 2

Or you could define a LookAt position a thousand studs in front of the Camera and set the LookAt position's height the same as the RootPart position's height like so: 
RunService.RenderStepped:Connect(function()
	local LookAt = Camera.CFrame * CFrame.new(0, 0, -1000)
	RootPart.CFrame = CFrame.new(RootPart.CFrame.p, Vector3.new(LookAt.X, RootPart.CFrame.p.Y, LookAt.Z))
end)

Both would work. Though, I’d prefer using the first method.

5 Likes
Can't Rotate Without Holding Right Click + Stuttering
#4

Actually, let me get directly right into my problem right now,
when I use shift lock and walk backwards, it causes no problems, neat and smooth:
https://gyazo.com/1c479ed47f879287874b42aa6d54e1d4

However, when I use my own one, which is binded to RenderStepped, it acts weird. The character isn’t even able to walk backwards in a straight line:
https://gyazo.com/b9cba9c430d5b587c9a69a2f0e20cce9

When I set limbs and torso to massless, this doesn’t happen, however I don’t want them to be massless because they character will behave weirdly sometimes. This leaded me to discover the problem where the animation is causing the problem, despite that it’s just a simple weapon holding idle animation.

That’s why I’m trying to look for the source code of this behavior from the control module, or is there any solution to address this?

#5

Have a go with either of the methods I posted then.

#6

I tried both, they behave the same.
https://gyazo.com/5327a30993bac3d8221212eb51c13d0d

Actually it’s the same with my original one except I’m using Mouse UnitRay, we both set the HMR CFrame with position and look at, so all code have the same glitchy result, that’s why I’m wondering how did the shift lock performed this smoothly.

				local MDir = mouse.UnitRay.Direction.unit
				local RotTarget = Vec3new(MDir.x,0,MDir.z)						
				local Rotation = CFnew(char.HumanoidRootPart.Position, char.HumanoidRootPart.Position + RotTarget)
				char.HumanoidRootPart.CFrame = Rotation
#7

Have you made sure that the RootPart isn’t getting affected by any other scripts? That must be the case because it works perfectly in an empty baseplate place.

#8

I think it happens with a tool, I have massless and CanCollide on this test tool in a baseplate.
https://gyazo.com/26cc51eda43ad82b77c65196dbb6266a

Plus the tool in my scenario uses Motor6D that’s welded between the Root part of the tool (Handle) and the Torso, which the Torso is welded to the HMR, I don’t know is that related. Plus, not only the tool in my scenario has CanCollide false and Massless true, it’s also set to an collision group which can’t collide players and itself.

#9

This shouldn’t make a difference at all… unless the Part0 is set to be the Tool’s root(?)

#10

I found out the problem.
I was using BodyGyro for such rotation (Setting the calculated CFrame to BodyGyro) and it doesn’t cause this problem, the reason being the body gyro will constantly setting the Humaoid running state to Running. When I apply this without using the BodyGyro CFrame, it will glitch with the state Running.

However, if the Gyro is removed, the state will switch between Running and Running No Physics. And it will not glitch on Running No Physics.

I guess instead of forcing it to Running With No Physics, trying to fix the rotation will be a better solution… Still have no idea why Shift Lock can do this so smoothly.

#11

Maybe make sure it is all being handled on the client and it is running before the camera updates?

#12

Like how? FYI It’s in a RederStepped.

#13

You should be able to do this just fine without using a BodyGyro. What specifically is it for, though? What makes it necessary for you to use the BodyGyro?

#14

This is getting SO weird.
I ran the exact same code in a separate local script and it works fine, without BodyGyro. But it glitches when I ran it in my main client script.
What??
Edit: I don’t think I have any other client scripts that’s modifying the HumaonidRootPart, only referencing such as it’s CFrame, Position, LookVector etc. But it’s still weird to see it only works on a separate script…

Refer to your question, I used a BodyGyro because of fixing this problem, in 2 months ago.

However I don’t want to use BodyGyro now because it’s not giving out an instant reaction and for some reasons.

1 Like
#15

Ok, i not really was working yet with Cameras, but i belive you can find the code in game.Players.«YourPlayer».PlayerScripts.PlayerModule.CameraModule (Idk how it exactly was named, but something woth Camera).

Then, if it not work, why not try to use the same method as the method of the Head is looking in the same direction as the Camera? You can try something like this:

local Player = game.Players.LocalPlayer
local Character = Player.Character
local Camera = workspace.CurrentCamera

game:GetService("RunService").RenderStepped:Connect(function()
    local Angle = math.acos((Camera.CFrame:ToObjectCFrame(Character.HumanoidRootPart.CFrame)*Camera.CFrame).LookVector:Dot(Character.HumanoidRootPart.CFrame.LookVector))

    Character:SetPrimaryPartCFrame(CFrame.new(0, Angle, 0))
end)

But yet i really not am sure that this will work, just try and adapt it! Srry if i not know the exact code, but i hope this will help you further…

1 Like
#16

Then you will have to debug what’s causing that to happen. I’ve contributed as much as I can with the information you’ve provided and given you two ways to have the character face the same direction as the camera.

#17

I’ve debugged it and found out a solution, it’s being solved by turning off Humanoid.AutoRotate. However shift lock still perform smoothly with it being on, if anyone know the approaches for Shift Lock feel free to reply to this thread, I’ll take that it’s solved for now, thanks all for your time.

1 Like
#18

If Humanoid.AutoRotate was on, then it would only be a visual issue for other players and the server. The client shouldn’t notice it, so I don’t know why it did for you.