Weld taking awhile to actuate?

Help and Feedback Scripting Support
#1

I’m trying to create a carry system where you can carry a players ragdoll, it’s handled by constraining the upper torso of the ragdoll to an attachment on the player.

However, when you drop the ragdoll and attempt to carry it any time that isn’t the first, it acts like this:

Is there a solution to this? I’ve tried debugging it for a couple days now, and I can’t seem to find the cause. I tried different constraints thinking maybe it was just how that specific constraint operated, but that didn’t fix it. I then thought maybe it had to due with network ownership, but that wasn’t it either.

Attached is the code used to run the carry prompt.

script.Parent.Triggered:Connect(function(player)
	
	if debounce.Value == false then
		
		script.Parent.Enabled = false
		
		local carry = workspace[player.Name].Humanoid.Animator:LoadAnimation(rs.AnimiFunctions.Animations.CarryBody)
		local pickup = workspace[player.Name].Humanoid.Animator:LoadAnimation(rs.AnimiFunctions.Animations.PickupBody)
		
		workspace[player.Name].HumanoidRootPart.Anchored = true
		
		pickup:Play()
		
		pickup.Ended:Connect(function()
			
			carry:Play()
			
			script.Parent.Parent.Parent:MoveTo(workspace[player.Name].HumanoidRootPart.BODY_SPOT.WorldCFrame.Position)

			for i, v in pairs(script.Parent.Parent.Parent:GetChildren()) do

				if v:IsA("MeshPart") or v:IsA("Part") then

					v.CanCollide = false
					
					v:SetNetworkOwner(player)
					
				end

			end
			
			local newconstraint = Instance.new("BallSocketConstraint")
			newconstraint.Name = "BODY_CARRY_CONSTRAINT"
			newconstraint.Parent = workspace[player.Name].HumanoidRootPart
			newconstraint.Attachment0 = workspace[player.Name].HumanoidRootPart.BODY_SPOT
			newconstraint.Attachment1 = script.Parent.Parent.Parent.UpperTorso.BodyFrontAttachment

			workspace[player.Name].IsCarrying.Value = true
			workspace[player.Name].IsCarrying.Body.Value = script.Parent.Parent.Parent

			debounce.Value = true
			
			wait()
			
			workspace[player.Name].HumanoidRootPart.Anchored = false
			
		end)
		
	end

end)
1 Like
#2

Hello.

You do remove the BallSocketConstraint each time you drop the ragdoll, right?

2 Likes
#3

Yes, I do.

Attached is a server event that gets called for dropping the body.

	if state == "drop_body" then
		
		local objvalue = workspace[player.Name].IsCarrying.Body.Value

		--workspace[player.Name].HumanoidRootPart.BODY_CARRY_CONSTRAINT.Enabled = false
		workspace[player.Name].HumanoidRootPart.BODY_CARRY_CONSTRAINT:Destroy()
		workspace[player.Name].IsCarrying.Value = false
		
		for i, v in pairs(workspace[player.Name].Humanoid.Animator:GetPlayingAnimationTracks()) do
			
			if v.Name == "CarryBody" then
				
				v:Stop()
				
			end
			
		end
		
		for i, v in pairs(objvalue:GetChildren()) do
			
			if v:IsA("MeshPart") then
				
				v.CanCollide = true
				
			end
			
		end
		
		workspace[player.Name].IsCarrying.Body.Value = nil
		
		wait(1)
		
		objvalue.UpperTorso.CARRY_PROMPT.Enabled = true
		
		objvalue.UpperTorso.CARRY_PROMPT.Debounce.Value = false
		
	end
#4

Huh, that’s weird haha. Try removing the animations and see if it persists.

#5

Try setting your BallSocket Parent after you set the other BallSocket Properties.

1 Like
#6

I can try, but I don’t think the animations are the cause. They don’t really have any impact on the carrying as it’s purely cosmetic.

#7

Unfortunately, this didn’t help. The same behavior persists.

#8

I’ve just discovered the issue,

script.Parent.Parent.Parent:MoveTo(workspace[player.Name].HumanoidRootPart.BODY_SPOT.WorldCFrame.Position)

This line was causing the problem, it seemed to be resetting the WorldCFrame to it’s original state for some reason??? Anyway, removing this fixed the behavior.

#9

What is the variable player? If it’s the player in the Player folder it’s location is 0,0,0.
If it’s the player in the workspace it should have the correct Position.
You could try printing all the variables in that line to see what the values are that you were calculating the Position from.

#10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.