RenderStepped is choppy when in shift lock switch

Help and Feedback Scripting Support
#1

You can write your topic however you want, but you need to answer these questions:

  1. What do you want to achieve? Keep it simple and clear!

I want to achieve a character carrying system so that characters can carry other characters including NPCs.

  1. What is the issue? Include screenshots / videos if possible!

The system is very choppy when the character doing the carrying goes into shift lock switch. The current system I have works essentially perfectly except for when the character doing the carrying is in shift lock switch. This issue also occurs in first person.

  1. What solutions have you tried so far? Did you look for solutions on the Developer Hub?

I tried using AlignPosition and AlignOrientation, but I had the same issue. I also used a Weld, WeldConstraint and RigidConstraint, but I had the issue of both characters dying when one character died. I also tried using .Stepped and .Heartbeat as well as a while task.wait() loop.

In the video below, the attachment is visible. I am setting the HumanoidRootPart CFrame of the character being carried to the attachment’s WorldCFrame, but as you can see in the video, there’s a weird delay when in shift lock (also in first person).

-- This is in a LocalScript responding to an OnServerEvent
if Request == "CarryCharacter" then
			local CarryTarget = Data.CarryTarget
			local Attachment1 = Data.Attachment1
			if CarryConnections[CarryTarget] ~= nil then
				CarryConnections[CarryTarget]:Disconnect()
				CarryConnections[CarryTarget] = nil
			end
			local TargetHumanoidRootPart = CarryTarget.HumanoidRootPart
			local SmoothInfo = TweenInfo.new(Data.SmoothTime or 0, Data.EasingStyle or Enum.EasingStyle.Sine, Data.EasingDirection or Enum.EasingDirection.Out)
			CarryConnections[CarryTarget] = RenderStepped:Connect(function()
				local S, E = pcall(function()
					TweenService:Create(TargetHumanoidRootPart, SmoothInfo, {CFrame = Attachment1.WorldCFrame}):Play()
				end)
				if not S then
					warn("Carry replication broken due to an error:", E)
					CarryConnections[CarryTarget]:Disconnect()
					CarryConnections[CarryTarget] = nil
				end
			end)
		end


			
		if Request == "EndCharacterCarry" then
			local CarryTarget = Data.Character
			if CarryConnections[CarryTarget] ~= nil then
				CarryConnections[CarryTarget]:Disconnect()
				CarryConnections[CarryTarget] = nil
				for _, Part in pairs(CarryTarget:GetDescendants()) do
					if Part:IsA("BasePart") then
						Part.Massless = false
						Part.CanCollide = true
					end
				end
			end
		end
#2

Hello, it looks like it may be because you are tweening the humanoidrootpart in RenderStepped. I would change it to

TargetHumanoidRootPart.CFrame = Attachment1.WorldCFrame

#4

Hey, thanks for replying. I probably should have mentioned this but I had that exact code before and still had this issue. (By the way, the SmoothTime is 0 so I don’t think it would make a difference).

#5

I dumbed it down and I had the same issues. I’m surprised I never knew this existed! I tried experimenting a little bit and found a solution, but I’m not sure if you want it in your game as it’s probably an unreliable solution. All you need to do is weld the carry character to the player, then set all of the parts to massless = true. I hope this helps.

#6

Thanks for the idea but it’s already mentioned why constraints are not used. It’s because if one character dies, both characters will die. I would destroy the constraint on death of one character, but I want players to be able to pick up dead bodies as well.

#7

I’ve never made a carry system before, but welds are probably your best bet. They’re simple and efficient. To solve that dying issue, one possible solution could be to use :SetStateEnabled(Enum.HumanoidStateType.Dead).

#8

It seems like welding is the only way. Also, you don’t need to set the state of humanoid as long as it is not parented to another player, when the carrier dies it finds all Humanoids and sets them to them dead, which is what I believe is why the other player dies as well.