Welds and WeldConstraints causing failure in server to client replication

[Mystifine]

I believe this issue was mentioned in a couple of posts and was said to be fixed but the issue still occurs.

Thie bug occurs when welding parts on the server to another part. I believe this issue happens usually when there are “Mass” quantities of parts causing failure to replicate the correct positions of parts. Here’s an image of the client-sided view:

Now here’s an image from the server-sided view:

File With The Bug:
ServerSide Weld Replication Bug.rbxl (64.9 KB)

Yesterday, I made a scripting post regarding this issue but got no feedback at all. After some research, I found out this was more or less a problem in the past.

I’m not exactly sure how to reproduce this bug but I believe it maybe when there are large numbers of base parts being welded OR when unions are present. If the file location is needed, please let me know. I will try my best to reproduce this bug.

If Roblox were to be able to address this issue, it would help my development experience as I would be able to display clean visuals to the clients with the use of Welds and WeldConstraints.

Here’s the post I made:

Roblox Weld Constraints and Welds having client replication issue

So; basically I model each “Piece” (Head, Torso, Left Arm, Right Arm, Left Leg, Right Leg), set a primary part and then use :SetPrimaryPartCFrame() on a template to put accessories onto a dummy. So sometimes, it seems like when there are many welds, some parts have an offset like so: [image] My other models are fine but when it comes to certain ones that seem to use unions or meshes will seems to have an offset. My setup is welding every part to a core piece, then putting it into a folder (…

Other posts regarding this issue

WeldConstraints created on the server should replicate their offset to clients

As a developer, it’s impossible to reliably create WeldConstraints attached to moving bodies on the server. Because of latency, the offset on the server/client end up being different: [image] It seems this happens because WeldConstraints are simulated disjointly on the server/clients. They each calculate their own offsets between Part0/Part1. This makes WeldConstraints too unpredictable to use on moving bodies. For WeldConstraints to be reliable when in use with moving bodies, the server woul…

[RVVZ (Emperor)]

Can confirm this is still happening:

Client:

Server:

[Mystifine]

Important

To those who’ve came across this issue, I’ve found a solution. The solution is to use Motor6D's to create the welds for now. Until roblox fixes the issue Motor6D’s are the only instances that don’t create a visual offset.

local weldConstraint = Instance.new("Motor6D")
weldConstraint.Part0 = primPart
weldConstraint.Part1 =  modelchildren[i]
weldConstraint.C0 = primPart.CFrame:Inverse()
weldConstraint.C1 = modelchildren[i].CFrame:Inverse()
weldConstraint.Parent = primPart
weldConstraint.Name =  modelchildren[i].Name..":"..primPart.Name

EDIT: NEVER MIND; the solution above does not work, it seemed like it was working but it didn’t work in the actual game.

[Mystifine]

I’m not exactly sure when engine bugs get fixed but I have updated information regarding this issue.

My original thought was that because only the client saw the offset I thought everyone else (besides yourself) would see the proper offsets but that was not the case.

To every single client, the offset is visual which is really not visually appealing to the players. My current option is to manually try to update the offsets on the client just to make it visually appealing. Hopefully this bug get’s fixed soon. If you are having this issue your only solution is as of right now is to try to reposition the pieces on the client.

[Hippie_ofDoom]

Thanks for the report! We’ve filed this internally and we’ll follow up here when we have an update for you.

[Hippie_ofDoom]

I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved?

[Mystifine]

Personally, I believe the bug has been resolved as similar tests has resulted in appropriate behaviour. Thanks for looking into this.

EDIT: I’m unsure if others still have this issue.

[Hippie_ofDoom]

Perfect. We will consider this issue resolved then. If it starts up again please file a new bug and we will take a look.