Unexpected Behavior with PhysicsConstraints, MeshParts and Parts

[Grersh]

This issue is very complicated, but I will do my best to explain it.

Originally I discovered this bug without having the ability to post in #bug-reports and instead made this topic. Please note that our results of debugging were rather inconclusive.

Broken/Unexpected Network Ownership Behavior

Hello. Today I was working on a custom character system in which the server only stores information for the Humanoid and the HumanoidRootPart, whereas the client(s) are responsible for all other information (eg. on the server only the Humanoid and HumanoidRootPart exists, whereas on the clients all the limbs are present). I chose to do this as I wanted to experiment with simulating ragdolls and animations for my upcoming game only on the client, however I came across two roadblocks. The first …

After attempting these client-side ragdolls that are connected (via Weld) to a Server created RootPart, I have made this observation.

The rigs that are made using a MeshPart (like in the original post) have the unexpected and strange network-ownership behavior. RootParts are out of sync between Clients, Server, etc.

Attempting the same methods, but using a rig that is assembled with Parts (as opposed to MeshParts) you get these results. RootParts are in-sync with clients and the server but physics updates do not happen on the Limbs that are made on the client.

Swapped out the usage of a weld with usage of an AlignPosition and AlignOrientation and the results are still the same.

Expected behavior
The expected behavior is for the ragdoll to behave like a proper ragdoll on the client, with the instances (limbs) created on the client behaving like proper physical bodies.

The Solution

For those of you who want to achieve client side ragdolls still, here is the best way I found. When the character is ragdolled, have an Attachment in workspace.Terrain and set AlignOrientation and AlignPosition Attachment1 to that attachment. On Heartbeat, set that Attachments CFrame to RootAttachment CFrame. This should however not be considered to be a permanent solution, as it does not move as fast as Humanoid physics resulting in internal lag.

[Grersh]

Please refer to my original post for a file to test this out. It demonstrates the behavior of MeshPart Client Ragdolls.

[Howimetted]

Thanks for the report. We’ll follow up when we have an update for you.

[kckhem]

Hello, thanks for your question. The engine does not support inconsistent assembly structures between the client and server. Replication expects that the same parts comprise the assembly on both client and server.

[Grersh]

What solution would you propose if I want to go about creating my character model on the client and allowing for Ragdolls to still simulate.
Currently it looks very grim, and my only option being Custom physics.

My ideal workflow is to have the CharacterModel only exist on the client, with the RootPart existing on the Server alone.