Okay so, I want to make a Gliding feature with my character, but I’m having trouble with getting the HumanoidRootPart to rotate towards the Camera’s Look Direction on the X and Y Axis, here is the code I have for it
local function SetGyro(state)
if state then
Gyro.MaxTorque = Vector3.new(1e5, 4e5, 1e5)
Gyro.D = 2e3
Gyro.P = 3e5
Gyro.CFrame = CFrame.new(HumanoidRootPart.CFrame.Position,
Vector3.new(Camera.CFrame.LookVector.X, Camera.CFrame.LookVector.Y, 0)*2e4)
elseif state == false then
Gyro.MaxTorque = Vector3.new(0)
Gyro.D = 0
Gyro.P = 0
Gyro.CFrame = CFrame.new()
end
end
local function returnDistanceFromGround()
local R = Ray.new(HumanoidRootPart.Position, (-HumanoidRootPart.CFrame.UpVector)*500)
local _, hitPosition = workspace:FindPartOnRayWithIgnoreList(R, ignoreList, false, true)
return (HumanoidRootPart.Position.Y - hitPosition.Y)
end
RunService.RenderStepped:Connect(function()
if pressingKey then
local DistanceFromGround = returnDistanceFromGround()
if DistanceFromGround > 20 then
Humanoid.AutoRotate = false
SetVelocity(true)
SetGyro(true)
else
Humanoid.AutoRotate = true
SetVelocity(false)
SetGyro(false)
end
else
Humanoid.AutoRotate = true
SetVelocity(false)
SetGyro(false)
end
end)
So there’s actually a built-in way to do this, but it’s slightly obscure and appears to have been hacked in at the last minute when Roblox was porting the camera system into Lua back around 2014
UserGameSettings.RotationMode lets you overload the rotation behavior of whatever Humanoid happens to be the CameraSubject of the client’s camera, which is typically the humanoid being controlled by the player.
When set to “CameraRelative”, the subject Humanoid will automatically rotate to mirror the Y-axis of the camera’s rotation.
You can access the UserGameSettings via: UserSettings():GetService("UserGameSettings")
Note that this value is updated during each frame of the camera’s step, and running a loop to overwrite it each frame won’t make the camera rotate with the mouse’s movement in third person. You may have to hook into Roblox’s PlayerModule to overload this behavior.
I use Body Gyros for my flight system in my Dragon Ball game, and I typically do stuff with camera & rotating the character. What you want to do is have the body gyro point to a vector which is the Camera’s lookvector and multiply that value by something high, like 100000 I’ve tried math.huge and it does not work, so this will be more precise. BG.CFrame = CFrame.new(RootPart.Position, Vector3.new(Camera.CFrame.LookVector.X, Camera.CFrame.LookVector.Y, Camera.CFrame.LookVector.Z) * 10000000) This is the normal way I would do it. Also, why not just use math.huge for things like maxtorque etc? Incase you just want more info or something, here’s my main code for updating everything in a RenderStepped event:
Instead of using a BodyGyro to make the character look up and down, I would advise altering the Motor6D CFrame based on the Y-axis of the camera’s LookVector.
Although this “works”, it doesn’t work for the reason you might think.
You’re using this constructor:
CFrame.new(Vector3 origin, Vector3 lookAt)
The 2nd argument isn’t a LookVector, it’s a literal world-space position for the CFrame to look at from the provided Vector3 origin. Projecting it out that far will cause floating point errors due to rounding.
If you want a CFrame to face a specific direction precisely, you’d be better off doing something like this:
local cf = CFrame.new(origin, origin + lookVector)
Dude, that’s actually the solution and it worked, I never thought of it that way, I should’ve paid more attention to the BodyGyro wiki, thanks a lot for your help
My solution works or his solution works? I’m mentioning this because he’s using the CFrame constructor incorrectly. Sorry if I’m mixing up what you meant.
I said you wanted to make the Body Gyro point to a Vector, which is the Camera’s LookVector. The LookVector of a CFrame is just a normal Vector with x,y,z coordinate values that make up the direction the CFrame is facing foward, Never issued that the second argument is a LookVector.
I’m not using the constructor incorrectly, in a systematic standpoint. However in a logical standpoint you could say so based on your solution you have addressed:
