The client and server disagree on the location of the player’s character immediately after respawning.
See the following image in Studio:
This bug happens when,
- NextGenerationReplication OR ImprovedPhysicsReplication are Enabled, AND AuthorityMode is set to Automatic
- The player respawns while standing on an unanchored assembly with the network owner NOT set to that player
This bug happens,
- In Studio and in live servers
- Regardless of R6 or R15 character
- Regardless of Streaming Enabled
- Regardless of workspace.PlayerScriptsUserInptuActionSystem
- Regardless of workspace.ImprovedAnimationConstraint
- Regardless of workspace.SignalBehavior
- Regardless of workspace.UsedFixedSimulation
- Regardless of StarterPlayer.AvatarJointUpgrade
- Regardless of StarterPlayer.CharacterBreakJointsOnDeath
First seen:
- in live servers on June 16, 2026.
Minimal reproducible example:
Replication Error Example.rbxl (61.2 KB)
To recreate, respawn the character repeatedly until a warning message is printed in the console.
Notes:
- More specifically, the server believes that the character is located at (0, 0, 0) after respawning, regardless of the location of the SpawnLocation.
- The client-server replication disagreement will last indefinitely, or until the player stands on a different assembly. (Even with ImprovedPhysicsReplication enabled.)
- This bug does not happen with workspace.AuthorityMode set to Server.
- Please don’t forcefully enable ImprovedPhysicsReplication on July 15, as it causes havoc in my games! Players are kicked due to anti-fly scripts, guns held by the characters fire from (0, 0, 0), distance checks are way off, etc.
System information:
- Microsoft Windows 10 Home, Version 10.0.19045 Build 19045
- Intel(R) Core™ i9-10850K CPU @ 3.60GHz, 3600 Mhz, 10 Core(s), 20 Logical Processor(s)
- Installed Physical Memory (RAM) 80.0 GB
- NVIDIA GeForce RTX 3080, Driver Version 32.0.15.9571
- Studio Version 0.729.597.7291029 (64bit), Channel: zmimallocmemcat4bit729, Latest version available: 0.729.597.7291029