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 :
One player always experiences movement lag/desync when both are connected.
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.
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)
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.
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.
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
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?