Reproduction Steps
Attached is a file with a bunch of contraptions I would like to use in my game. They include rope bridges and lamps connected via ropes.
I have found that in multiplayer they are very unstable, bouncy and underdamped. I thought maybe it had something to do with distributed physics, so as an experiment I set the NetworkOwner for all the BaseParts in my level to be nil, forcing server physics, but that actually didn’t help as far as I can tell.
Expected Behavior
I expect to be able to use ropes to make components for a multiplayer game and have them work similarly to how they work in Play Solo in Studio.
Actual Behavior
They freak out.
Workaround
No.
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly
I’m pretty sure this is how they’ve always been and since they have a good chunk of distance, and the objects they’re restraining are quite heavy. The calculation of the weight plus the strength of the rope is the issue. I’ve had an idea that I’ve spun around in my head for a while now, they’d be different types of Rope to make it so you can do certain things with certain types of items.
I may be wrong but I’m 98% sure this is the typical reaction of the ropes.
EDIT: The ropes and items do calm down after a while of waiting; however, they’ll most likely return to their unstable state after a player jumps on them.
I’ve seen them blow up when no one is touching them. I think it has to do with half/all the assembly being passed from player to player as they move around the map and the latency that causes.
Ropes probably simulated at hundreds of Hz and then you throw it across a network with 200ms latency.
The mass isn’t that high and is not changing over time, so it seems like in theory Roblox could come up with a reasonable guess at a spring constant to use that would be stable. In general, the system should not gain energy while just sitting there with no one interacting with it.
If players don’t directly interact with the ropes, just have them be client-sided, as roblox physics with fairly complex object calculations is pretty wacky.
I see your isssue. You can’t make them client sided or anything like that, as many players will go on them at once. I recommend probably to just not use as many rope objects.
This will not happen. Mechanisms (sets of movable rigid bodies joined by constraints) are the unit of distributed physics simulation, so each of the rope bridges must be simulated on a single peer. (In fact, connecting two bodies using a rope of infinite length is a common trick to force two objects to be simulated on the same client)
I’m pretty sure that the issue is simply that the energy has no-where to go: There’s no wind resistance on Roblox (yet), so there’s zero damping anywhere in the rope bridge system to absorb the energy and bring it down to a stable equilibrium.
Compound that with the fact that a rope bridge is a super hard case for the physics engine to simulate in the first place (thanks to being made up of a whole bunch of boundary conditions rather than nice continuous constraints), and I’m guessing energy ends up being added during the network handoff and never removed so the simulation eventually blows up from having too much energy in it.
Try manually applying damping with something like this (more efficiently / to specific things like each ladder segment for a practically usable solution) and see how it performs:
while task.wait() do
for _, ch in ipairs(workspace:GetDescendants()) do
if ch:IsA("BasePart") then
ch.AssemblyLinearVelocity *= 0.99
ch.AssemblyAngularVelocity *= 0.99
end
end
end
The whole thing is also compounded by the fact that there is a whole bunch of initial energy thanks to the bridges starting high up and falling into position rather than starting in a relatively relaxed position – You could remedy this by using the draggers in Physical mode to drag the bridges into a more relaxed position (The simulation team is actually investigating “warm starting” of places to do that automatically in the future).
Yeah, this is pretty standard rope behavior. Roblox should absolutely fix it of course, but even on some simple things ropes have a tendency to go nuts (we have a bead curtain that doesn’t touch the floor, but a few of the strings enjoy getting themselves wedged into the ground and aggressively jittering- for some reason, it also enjoys acting like a ladder or truss).
I’d love to mimic rope bridge physics using actual ropes as much as the next person does, but they’re really better done with models because of how buggy ropes can be.
Until rope physics become less like stringing beads together and then swinging the string around and more like real-life, proper restraining ropes used for bridges and mountain climbing and whatnot, it’s really just better to use models. You could probably simulate the physics better with a script on a static model, anyway, as to avoid the variables rope physics throws in.
I will try adding dampening and see if that improves things. I thought Roblox already had a small dampening factor, but maybe that is [no longer true]/[was never true]. Is there a way to only dampen on the client that is currently doing the simulation? I don’t want to spam property updates and flood the pipes. I guess I could force server physics.
I have also tried increasing the restitution of the ropes, to make the boundary conditions more Lipschitz, but I can’t say that I noticed a difference.
I have wanted to be able to physically drag chains that I have made around in the Workspace, is there a tool for that? The physics/geometric toggle on the dragger didn’t do what I expected (i.e. run physics for the assembly I’m dragging and anything it touches).
One follow-up question is, if this level plays fine in Solo mode in Studio, why does it perform poorly online after I force the NetworkOwner of all the parts in my level to be the server? Those situations should be the same, sim-wise?
I have been experiencing issues with ropeconstraints for the past 3 years and figured out what some of the causes are for the weird behaviour, they might help you figure out a way to solve it.
the length will exceed the max allowed length and when it exceeds too far, it will apply an extreme force to try and counter it.
low fps can have a massive impact on ropes and will cause them to bounce around and shake like crazy, it will look like the ropes will totally ignore the boundaries of the max length or move too far due to the lag and keep doubling the extreme force to counter the length change until it eventually flings itself into the void.
I think (a/the) root issue is that there is no dampening/air resistance and no performant way for developers to implement their own.
That can be seen in Studio.
Online mode definitely exacerbates it, I assume due to network latency, but not sure. This might point to a secondary issue of who is simulating the rope, across which boundaries, who is standing on the same platform, etc. As a developer, I’d rather these physics all happen server-side because it’s easier to deal with and more fair from a game perspective. It’s not ideal for one player to have a silky smooth experience while the others deal with 2-network-hop latency. I’d rather everyone deal with 1-hop latency.
Something I made recently that shows both issues: Red Tower 2.rbxl (243.2 KB)
