Camera script causes running animation

I’m making a 2D side scroller game, and so I made a script that offsets the camera from the torso of the player. The script works fine, but the problem is that the player’s running is always going, even when standing still (affects both r15 and r6).

Heres the script (LocalScript in StarterCharacterScripts):

local Camera = game.Workspace.CurrentCamera
local Player = game.Players.LocalPlayer
repeat wait() until Player.Character
local Torso = Player.Character.HumanoidRootPart

local BodyPositioner = Instance.new("BodyPosition",Torso)
BodyPositioner.MaxForce = Vector3.new(0,0,math.huge)
BodyPositioner.Position = Vector3.new(0,0,Torso.Position.Z)

Camera.CameraType = Enum.CameraType.Scriptable
Camera.CameraSubject = Torso

game:GetService("RunService").RenderStepped:Connect(function()
     Camera.CFrame = CFrame.new(Torso.CFrame.X, Torso.CFrame.Y + 3, Torso.CFrame.Z + 19.5)
end)

And here’s the problem:

Why is this happening, and how do I fix it?

This is not caused by the camera but by the body position you are using the Dampening is set to high by default… here is the code to fix it Oh and the BodyPositioner.Position can be just set to Vector3.new() which is 0,0,0 and should still keep you in line where you are.

local Camera = game.Workspace.CurrentCamera

local Player = game.Players.LocalPlayer

repeat wait() until Player.Character

local Torso = Player.Character.HumanoidRootPart

local BodyPositioner = Instance.new("BodyPosition",Torso)

BodyPositioner.D = 100   -- this needs to be lower than like 1000 or change the P some

BodyPositioner.MaxForce = Vector3.new(0,0,math.huge)

BodyPositioner.Position = Vector3.new(0,0,Torso.Position.Z)

Camera.CameraType = Enum.CameraType.Scriptable

Camera.CameraSubject = Torso

game:GetService("RunService").RenderStepped:Connect(function()

Camera.CFrame = CFrame.new(Torso.CFrame.X, Torso.CFrame.Y + 3, Torso.CFrame.Z + 19.5)

end)
1 Like

Changes


local BodyPositioner = Instance.new("BodyPosition",Torso)
BodyPositioner.MaxForce = Vector3.new(0,0,math.huge)
BodyPositioner.Position = Vector3.new(0,0,Torso.Position.Z)

…to…

local BodyPositioner = Instance.new("BodyPosition")
BodyPositioner.MaxForce = Vector3.new(0,0,math.huge)
BodyPositioner.Position = Vector3.new(0,0,Torso.Position.Z)
BodyPositioner.Parent = Torso

Please don’t parent first and set properties later. Assume that the animation is still playing because of the BodyPosition. I don’t think it’s the best idea to use BodyPosition to force the player on the same Z position.

I don’t know, but I think you can disable the movement controls for the characters and leaving A and D as the player’s only option of moving(a 2D platformer, W can be set to jump while S to duck if you want).

^^ reasons for above changes is described in more detail here

1 Like

The API for creating objects has been updated if you read it parents last now by default. so the performance issue is not there anymore from my understanding

Where are you getting this information from? This is fairly inaccurate.

Lua does not implicitly delay the parenting of an instance, not can it when done in this fashion. As far as the first statement is concerned, you’re calling Instance.new with a class name and a parent. That chunk is ran and then the ones after it (setting it’s properties) are done.

The only way it could set the parent last is if the new method allowed you to specify the properties to set as well, which then the function could set properties first before parenting it. New does not support any other properties that parent however.

The performance issue still exists. So does this bad habit. It also hampers on affecting readability. Instance.new is cleaner read as “create an instance of this class”. Specifying a parent just makes it strange to read.

True I was thinking about Create that used to set properties they changed the API on that to parent last after all other properties were set. That has now been deprecated. I don’t think in this case this would be a large performance problem as he is only creating 1 object client side. Just a bad habit…

Create? Are you referring to RbxUtility.Create? The performance issue still exists regardless of the way you implement it. RbxUtility.Create happened to catch any parent indices and defer setting them by using a local variable. Once all functions had finished, it used the earlier variable to finally set the parent.

There’s even a warning in the source code of the function itself before it handles that bit.

The issue with setting parent isn’t only related to performance as far as technicality goes. It teaches a bad habit of using that argument if you intend to set properties after creating an instance and it’s quite frankly horrible as far as readability goes. Whether it’s on the client or the server, the scenario doesn’t change - it’s still bad for performance and practice.