Physics replication showing parts in different positions

Bug Reports Engine Bugs
#1

Reproduction Steps
This issue is extremely simple to reproduce but also having a major impact on using accurate physics in our projects.
When you anchor or weld a part, it will appear in different positions to different people (depending on who the owner is)

Repro: Create an anchored part and move it into the air
Insert a serverscript with the following code

script.Parent.Touched:connect(function()
	script.Parent.Anchored = true
end)
wait(3)
script.Parent.Anchored = false

When you run the game, you’ll see the part fall and freeze in midair. But when you check the server the part is actually on the ground.

Expected Behavior
Parts should appear in the same position across servers and clients (especially once anchored)

Actual Behavior
The part seems to skip a step once anchored and never updates to its correct (final?) position.

Workaround
We are working on a custom physics system to ensure parts match up across the server/client

Issue Area: Engine
Issue Type: Other
Impact: Critical
Frequency: Constantly

8 Likes
#2

I’m enabling an old flag that should fix this particular case. Will update once that’s set.

Before the part is anchored it’s position is changing from smoothly interpolated physics motion. Physics interpolation tends to be a tiny amount of time behind other replicated property updates, because it’s a separate network channel and more importantly interpolation necessarily adds some delay (you’re not instantly applying the latest result, but moving to it over time).

Anchoring the part disables interpolation instantly before it reaches it’s final position. We don’t send a CFrame update after anchoring the part, so it ends up locked at whatever position it was at on that machine when it was anchored. The “fix” just also sends a CFrame update when anchoring things, so when anchoring the client will always snap to the position the server had. Discontinuous, but you should get consistency.

Building your own physics system is going to be overkill to address this, since this issue is specifically around anchor property changes.

In terms of consistency I know there’s some other problems related to intrinsic ordering issues related to weld/assembly configuration changes and cframe assignments moving whole assemblies together, mostly only an issue when things are anchored. I had a larger change addressing this that I had on ice during a brief period we thought another networking change would obviate the need for it, which it didn’t. I’ll be trying to revive and ship those changes by sometime early next year as well.

8 Likes
#3

Awesome! I figured this was some kind of out-of-order scenario.

By “custom physics system” I meant that we would do exactly what your proposed fix is, and have the server get sent the proper offset for our projectiles once they land. But if this flag fixes the issue we won’t need to implement this!

1 Like
#4

Can confirm a bug with anchoring and client syncing with the server, unsure if it is related.

Part is in Position A

Freeze the client briefly (ping spike or somehow freeze your entire Roblox client)

Move a part anywhere (Position B)

Anchor the part

Unfreeze client

On the client that was frozen, the part will be frozen at Position A and will not update to Position B until the part is unanchored.

This bug occurs at times in one of my projects and causes confusion with players.

Unsure if there’s an alternate fix to it, I’ve tried manually updating on the client through the use of remotes but that doesn’t seem to work effectively.

1 Like
#5

Change should be enabled and effective in Studio and all live servers by now.

2 Likes
#6

Do I need to restart all instances of studio?

I remade the repro in a new instance and the issue seems to persist

#7

My bad, it didn’t actually get enabled. Try now.

One side effect of this change is that on the client it may now more consistently see the anchored part with a larger non-zero velocity than before, though this did occur before this change as well. That velocity should be consistent with the server. In some cases this may cause the humanoid to sink into, vibrate, or conveyor belt on the platform. You may want to explicitly zero out velocity after anchoring a part that was previously moving with physics.

5 Likes
#8

Looks to work now!

1 Like
#9

Just a heads up, we had to disable the fix for this since it had an unintended side effect. Once we fix that issue we will re-enable it.

1 Like
#10

The linked issue below was caused by the flag that fixed this case. I know this change as is may cause issues (it sends a CFrame assignment any time something is anchored) when things are only temporarily anchored. I’m not sure if that is why this issue occurred though.

2 Likes
#11

This issue still exists, is the flag never going to be re-enabled?