Chained Players & RopeConstraint

Hey everyone,

I’m currently working on a “Chained Together” style game, where two players are physically linked via a RopeConstraint. Everything works great visually, but there’s one main issue :

:warning: One player always experiences movement lag/desync when both are connected.

:mag: What I’m doing:
Each player enters a zone (Red / Blue sides).

Once both are in, I pair them :

They are TP’d to a spawn point.

A RopeConstraint is created between their HumanoidRootPart attachments.

I tried SetNetworkOwner(nil) on both → but now both players lag.

My question is, is there any way to fix this and how ? Or a new way that does same as a RopeConstraint.

1 Like

You could try adding the rope constraint on both clients, and not the server at all. It should have the same behavior, since they both have a separate rope constraint, and it should also remove the lag issue (in theory)

1 Like

This is actually a great question,

First of all, I just want to confirm, you want the code to figure out which player is leading the movement?

If Yes

You could do something like this:

humanoidRootPart1:SetNetworkOwner(player1)
humanoidRootPart2:SetNetworkOwner(player1)

Which would set the owner of both players HumanoidRootParts to the Player1.

3 Likes

I know wich lead but the other player get delay and i try to fix that.

Well thought out, I’ll try that right away and let you know if it works.

After testing it just removes the player’s movement making it so he can’t move.

Are you saying that the rope doesn’t pull anymore, It only restricts movement? Like, you can still move, but the rope doesn’t pull and you cant get any farther?

I can see that happening. If that is not the case, and your player really cannot move at all anymore, something is probably wrong with your setup

Im doing it correctly but one of the player cannot moove at all, if you have something like discord i can screenshare what is happening when i’m doing it.

Hey sorry for the delayed response. I’ve been doing some testing after discovering that you are correct.

I found a setup that seems to work without lag on either end. Instance the rope on the server like you originally had, and call SetNetworkOwnershipAuto() on both HumanoidRootParts. The server will then dynamically adjust the network ownership of those parts.

I try SetNetworkOwnershipAuto() and that change nothing to the fact that one player is still lagy and the other not, any idea ?

Wait a second. Are you talking about the framerate of the Roblox Studio player? That is perfectly normal. Background apps tend to have reduced framerates to save on performance

No, i mean i experience an input lag with one client that i don’t have with the other client with a bit of searsh there a lot of devs that have this problem on this system.

Weird, I could not get that behavior to replicate in my Roblox Studio. It looked and felt perfectly normal to me. This is my code:

local firstChr = firstPlayer.Character or firstPlayer.CharacterAdded:Wait()

local secondChr = plr.Character or plr.CharacterAdded:Wait()				


local firstRootPart : BasePart = firstChr:WaitForChild("HumanoidRootPart")

local secondRootPart : BasePart = secondChr:WaitForChild("HumanoidRootPart")


local firstRootAtt = firstRootPart:WaitForChild("RootAttachment")

local secondRootAtt = secondRootPart:WaitForChild("RootAttachment")




local RopeConstraint : RopeConstraint = Instance.new("RopeConstraint")

RopeConstraint.Name = "ConstrainToPlayerRopeConstraint"

RopeConstraint.Parent = firstRootPart


RopeConstraint.Attachment0 = firstRootAtt

RopeConstraint.Attachment1 = secondRootAtt


RopeConstraint.Restitution = 0.2

RopeConstraint.Length = 10


firstRootPart:SetNetworkOwnershipAuto()

secondRootPart:SetNetworkOwnershipAuto()

Weird i mean,

did you make sure to include the following?

firstRootPart:SetNetworkOwnershipAuto()

secondRootPart:SetNetworkOwnershipAuto()

yeah it’s after the “rope.Parent”

Create 2 anchored invisible parts always staying at the players root position, then create 2 spring attachments

1st attachment will be connected to the first player and the anchored part thats always at the other players location, and the other attachment will be the exact opposite

Thats already the reason it lags for 1 player

1 Like

This is a good solution. Might I ask why there needs to be 2 spring attachments? Your solution means the Server has network ownership of those created parts, so only one would be needed, right?

No

SpringAttachment 1:
1: Player1HRP
2: Player2AnchoredPosition

SpringAttachment 2:
1: Player2HRP
2: Player1AnchoredPosition

Ah! I see, now it makes complete sense. This is definitely the solution for OP

1 Like