As of now constraint property replication is very hard to do and creates a lot of lag.
A “Enable physics constraints replication” button would help me out so much as i wouldn’t have to make my own custom physics replication then, which would use 3 times more replication updates and slow down the game by a lot.
To make RopeConstraints not fling other players, i have to send a remote event for every change to the server and make the server update the property value’s and then i have to check .Changed on the client again to overwrite the offset from the server so that the client doesn’t teleport back.
This is impacting the performance by so much in my game, people can crash because they get triple the amount of updates because of the replication changes + remote event updates + processing.
My game doesn’t really need security as there is no way a player can cheat his way faster to a goal, in my game the goal is to experience physics.
If security is a must need, there could be something like a combination of automatic physics replication as a runservice event maybe which you could use to check physics replication updates or set a limit for certain items / disallow certain items.
I can’t describe how frustrating and infuriating it is to deal with this behavior, not only that but using Remotes and NetworkOwnership wouldn’t solve the problem or create another one.
Network Replication can be described as a can of worms
We know this is a huge pain point and something we need to address eventually. It comes up regularly internally.
To a lesser degree, this is even a problem with a simple car, where the owner’s steering angle disagrees with the constraint values the server and all the other clients see.
It’s pretty tricky to figure out a way to implement this that is easy to use, secure, and works together with network ownership and physics replication and interpolation (which actually operates on a separate, slightly delayed, timeline from normal property replication).
I’d really like to get this on our roadmap, but I can’t promise anything!
But…
You said 3 times more replication updates and I’m wondering if that needs to be the case.
To deal with this I think at a minimum you’d need to:
Player action changes constraint. Property changed locally, fire remote event, start listening to Changed events for that property.
Server receives remote event. Changes the property on the server, which queues a normal property change broadcast.
OP client sees property change coming from replication, knows that changed event isn’t from a player changing it right now, reverts the value to the last value the client set (if more recent), and does not fire the remote again.
That last part is complicated to implement, but I think that’s all it should take, overhead wise.
The only additional network overhead is the RemoteEvent from the one player to the server, along with the processing overhead for the initiating client to “debounce” the property change that it initiated from the server, and only in the case of a more recent subsequent change. For any other observer it’s just a vanilla property change from the server.
This is more than any developer should have to do, but I also don’t think the cost should be prohibitive? How are you getting 3x the cost, and can you simplify this?
This looks like some classic mechanism desyncronization when you use the Throw tool on Player1.
Our physics replication relies on consistent mechanism structure, and assumes the server and all clients have the same set of unanchored root parts and constraints for forming consistent network ownership units. This needs to be consistent for it to replicate correctly.
Do you have some local-only parts or constraint changes involved here? It looks like what I’d expect if the server and other clients didn’t have the ragdoll constraints. For ragdolls in general it’s kind of important that you create the ragdoll constraints and disable the Motor6Ds from the server so all clients see the same configuration. If they don’t, physics can’t replicate.
I think doing it from the server shouldn’t result in any delay in your case, but in case you do need to have ragdoll initiated from the character owning client without a round trip to the server you can do that but it’s much trickier. If you need that you might want to check out some of the comments in the code for this ragdoll death module I wrote for Roblox to use by default in some markets that don’t like dismemberment death.
I have set this up already, but there could be 0 to 3000 constraints in my game. (yes that much)
It’s a sandbox game where you can build anything with physics and people can create massive creations or lag machines.
About the 3X cost,
The player sends a remote event to the server for each update the player makes.
The remote event needs to get sent to the other clients aswell because for some constraints its just too messy to be set on the server.
For most of the constraints, the properties are set on the server, but that causes another replication update back to the player.
The player has to fix the update from the server, changing the properties and making a change to the constraint, which i think should update the server again because something was changed (maybe cframe or velocity / rotvelocity).
In my game i always see issues with the physics, i get tons of complaints telling me to fix the physics because its so broken, people get flung constantly with their jetpacks and parachutes and there is barely anything i can do against it that easily.
I think physics updates could be done much faster and efficienter with this feature rather than using remote events for it and making the dev himself create literally everything for every single update on any physics object.
