You’re going to have to use the second method: Render the rope and cube on the client only (the cube was just levitating to where it was dropped for the other players)
And write the functionality to attach the cube and rope on each client
Unless the sync between each client to be the same is required, have each client render their own version of the cube and attach it on its own. Else, you will need a replication system to sync the cube from the player who controls the cube if the positions are strict.
Or, try this, I don’t know if it will work though: Have the cube’s network owner set to the one who is carrying it, and only that rope constraint will be enabled. For every other’s cube that the client isn’t carrying, try setting the rope to be only visual. The cube will only be controlled by the player holding the cube.
Your not the only one with this issue. I’ve noticed similar behavior in other games which makes me believe that Roblox has done something with their rope physics.
The Altitorture game isn’t so smooth. Have you ever fallen with your friend in that game and looked at how you get thrown around? That’s because of ping and because Roblox’s physics are extremely random. Try using the methods I wrote above.
I tried your place and just like in mine, the other player’s parts do not move, although I tried absolutely everything to keep it as simple as possible but what worked at the end was:
Creating a part that gets teleported to the player’s hand every frame then putting a RopeConstraint and Attachment in that part. Make the RopeConstraint’s Att0 the new Attachment in the part and the Att1 the Ice Cube (In my case). All this in a LocalScript.