Welding locally completely destroys replication!

[vsnry]

PLEASE DO NOT TL;DR THIS IS AN IMPORTANT BUG

.
.
.
.
.

I have finally found a repro for a bug me and a few other people have been encountering for a few months!

When you weld a part, or a model (I haven’t done enough testing to know exactly what as this bug is really hard to reproduce) to a player, or yourself locally sometimes the whole position replication stops working, not just for you but for the whole server.

It is very hard to explain what exactly is going on, but in my case, explained here a couple of months ago Character position stops replicating after welding? I have been making a system where all characters run locally. The server only sees the HumanoidRootPart and each client creates the rest of the model (The arms, legs, head, etc.) and welds it to the server side HumanoidRootPart, but for some reason when this is done the position of the HumanoidRootPart stops replicating completely for both, the player who welded the model and the player who got the model welded to him.

I have spent some time doing research and I managed to find the least amount of code possible to reproduce this bug, although it isn’t as severe where it stops replicating position completely, it still does stop replicating some of the humanoid states, or features like jumping. Here is a video of what I mean:

VIDEO 1

As you can see, like 99% of the jumps which the player on the right did, the player on the left didn’t even see.

Here is what it looks like when it’s more severe and the whole position stops replicating, although I was not able to find a repro for this (I know I can just send the whole game where this happens in as a repro, but I’ll only do that if one of the staff members asks me for it since it also contains a bunch of other code for my game):

VIDEO 2

As you can see the player on the left is moving, but the server on the right can’t even see if the player is moving or not and when the locally welded model is destroyed the position starts replicating again.

Attached is the repro for the half broken replication seen in VIDEO 1, all you have to do is open up the .rblx file, start up a 2 player server and walk around. You will see that some actions do not replicate at all, if you’re lucky it might stop replicating completely for you, but I have yet to encounter that with this specific code.

Replication Bug.rbxl (21.4 KB)

[FieryEvent]

You’re sending invalid physics data to the server, as a result, it cannot replicate the player system.

16:02:13.462 - Physics-in of unidentified 3DB1_6756 (x69)

but… Why?

Parts are connected

It would be inneficient for the physics engine to replicate on individual parts and the other clients would have undesired imprecisions. Think of it as if your character had it’s members scattered, and each going on their own way. The network variations cause desynchronization, for example, it’s common to know a player is riding on top of the car or inside a train, but to see them appearing near the vehicle, being just behind it, because the engine doesn’t accounts a relationship between them.

Constraints

They set connections between parts, in which depend on the type of the constraint and which attachments were used. They are calculated by the physics engine, and so they are carried to the replication, keeping systems, like the player character model, coordinated, just like other necessary info used by other clients to perform proper interpolation.

Read more about the error here:
Physics error: Unknown Part

To check if your place have other physics errors, on studio:

1. Open "Settings..." (Alt+S)

2. Go to the "Network" setting

3. Enable the "PrintPhysicsError" diagnostic.

[vsnry]

How would I stop it from erroring? Is it even possible to weld without erroring?

[FieryEvent]

It doesn’t seems to be possible to weld (make a reference to a local part) without erroring, because of the nature of local parts:

• Local parts are in no way supported by Roblox. They exploit unspecified replication behaviour - at any given moment, the development team could release an update that changes how Camera and Message instances behave, preventing you from making local parts.
• Another thing to note is that scripts, local or not, will not run inside the camera. If a local part is to be scripted, the script controlling it must reside elsewhere.
• Local part physics may run weirdly, and they can be inherently glitchy.
• They will not react to any server objects such as superballs, rockets, or NPC (Non playing Characters) Humanoids.

However, it’s possible to achieve similiar effects to welding, by using AlignPosition and AlignOrientation, because they seem have looser rules on the HumanoidRootPart, that allows replication to flow.

function weldParts(playerCharacter)
	--Check if HumanoidRootPart exists
	local rootPart = playerCharacter:WaitForChild("HumanoidRootPart")
	local a0 = rootPart.RootRigAttachment
	--If not return
	if playerCharacter:FindFirstChild("localCharacter") then return end
	--Clone localCharacter model and weld it to the player
	local localCharacter = script.localCharacter:Clone()
	localCharacter.HumanoidRootPart.CFrame = rootPart.CFrame
	local localRootPart = localCharacter.HumanoidRootPart
	local a1 = localRootPart.RootRigAttachment
	local alignP = Instance.new("AlignPosition")
	alignP.Attachment0 = a1 --local char
	alignP.Attachment1 = a0
	alignP.RigidityEnabled = true
	alignP.Parent = rootPart
	local alignO = Instance.new("AlignOrientation")
	alignO.Attachment0 = a1 --local char
	alignO.Attachment1 = a0
	alignO.RigidityEnabled = true
	alignO.Parent = rootPart
	localCharacter.Parent = playerCharacter
end

• HingeConstaint seems to make the character trippy (for weld-like effects, set LimitsEnabled to true and an angle margin of 0)
• Ultimately, you can teleport the HumanoidRootPart to the local character on every physics step.

[Khanovich]

Roblox expects everyone’s view of the same mechanism to look the same. Replication requires this. When you weld an object to a mechanism that other players already know about, you run the risk of breaking all physics replication for anything attached to this local object. You start sending updates about a structure that other clients don’t know anything about, causing packets to be thrown out.

If you actually have ever managed to get this work you were getting lucky.

Local parts like this are not a supported behavior.

[ContextLost]

Unfortunately, this is a classic example of the type of thing that FilteringEnabled is supposed to prevent. Things like a hacker welding things to themselves or other players.

Working as intended.

[Maximum_ADHD]

So if I’m understanding correctly, the problem here is that the parts you’re welding to the character have a physical influence on the HumanoidRootPart while in FilteringEnabled.

This puts the physics replication into a state where it isn’t sure how to safely translate the mechanism state it’s receiving from the server onto the mechanism state you have it set to locally, so it just gives up and doesn’t bother applying the change. This is expected behavior.

You might be able to work around this by instead creating a mirror part that follows the HumanoidRootPart, and then weld to that instead. That will let the HumanoidRootPart keep updating because it isn’t being physically impacted by the parts you are welding.