Parts with a client network owner can have replication halted with certain physics constraint configurations

If an unanchored part that exists on the server has its network ownership assigned to a client, and the client sets up local physics constraints in a certain way, it can completely prevent the part from replicating positional and rotational data back to the server.

Take the following scenario:

Parts A and B are created locally on the client. A remains anchored while B is attached to A via a constraint (this is a common setup for creating moving platforms). If, on the client, the player’s character were to be attached to B via a constraint such as a rope, rod, or hinge, their character would no longer replicate positional and rotational data to the server while such constraints are active. Note that for whatever reason, constraints such as AlignPosition and AlignOrientation will not cause replication to stop.

Below is a place file that demonstrates this bug. Just start a local test server with one player and observe.
CharacterReplicationBugRepro.rbxl (61.6 KB)

And here is a video of the bug in action:

Expected behavior

I would expect that physics replication could not be completely halted simply by configuring constraints in a certain way on the client.

8 Likes

Anchoring “Bob” fixes the issue for some reason. Using the “AreOwnersShown” debug visualization shows that anchoring it causes the client to lose physics ownership of the part it created, so there might be a clue there.

I tried checking whether the client parts were causing the AssemblyRootPart of the character to de-sync (which, if you didn’t know, are used behind-the-scenes to figure out who-controls-what, the de-sync of which is the cause of a bug nearly identical to this one), nothing out of the ordinary. I even tried manually setting the RootPriority of the HumanoidRootPart to 15, but it didn’t seem to affect anything.

2 Likes

That’s more or less what I found in my testing. It’s only when an unanchored local part is attached to an anchored local part via a mechanism constraint. In my case, anchoring “Bob” isn’t a viable workaround as it’s either a moving or spinning platform and has to keep moving.

However, I did find a temporary workaround for now. For whatever reason, normal constraints that don’t simulate mechanisms (AlignPosition, AlignOrientation, LinearVelocity, AngularVelocity, etc.) seem to keep replication alive. So I’ve just inserted a LinearVelocity into the HumanoidRootPart and gave it 0 MaxForce (making it contribute nothing to the overall physics sim) and it keeps replication going somehow.

4 Likes

Thanks for the report! Just to confirm, we have a ticket filed in our internal database for this issue.

3 Likes

Bug still isn’t fixed. Additionally, while this did sort of work, making a ton of LinearVelocity instances on each part that isn’t replicating, despite having 0 max force and 0 velocity, applies some small, minimal force, which adds up and causes big physics problems.

2 Likes

Gonna @kleptonaut since this still hasn’t been fixed, see if they can shed some light

1 Like

Thank you. This is a big problem for ragdoll focused games.

1 Like