Server-side PivotTo on player character causes Motor6D joint breakage on remote clients
Category: Engine Bugs
Repro Rate: Intermittent (~10-30%)
Summary
When using Model:PivotTo() on a player character from the server, other clients occasionally see the character’s Motor6D joints break — body parts detach, float, or scatter — while the teleporting player’s own client displays correctly. This persists across multiple mitigation strategies.
Environment
- Roblox Studio & live servers
- R15 character rig
- StreamingEnabled: both on and off tested
- All tests performed with server-authoritative
PivotTo
Steps to Reproduce
- Two players (A and B) in the same server
- Player B walks into a trigger zone that calls
character:PivotTo(targetCFrame)on the server - Observe Player B’s character from Player A’s client
Expected Behavior
Player B’s character appears at the target CFrame with all body parts intact, identical to what Player B sees on their own client.
Actual Behavior
On Player A’s client, Player B’s character occasionally has its Motor6D joints broken — body parts (arms, legs, torso) detach from the HumanoidRootPart, scatter, and remain at the old position. Player B on their own client sees the character correctly. Player B can still move, but the detached parts persist as debris on Player A’s screen.
Mitigation Attempts (All Failed)
| Approach | Result |
|---|---|
| Anchoring all BaseParts before PivotTo, un-anchoring after | Still breaks, slightly less frequent |
| Anchoring + PlatformStand before PivotTo | Still breaks |
SetNetworkOwner(nil) before PivotTo, restore after |
Player freezes permanently after teleport |
| Client-side PivotTo first, then server-side PivotTo | Fixes local view, but remote clients still see breakage |
| Pure client-side PivotTo (no server involvement) | Fixes breakage, but other clients don’t see the teleport at all |
TeleportTo (simple PivotTo, no Anchoring/PlatformStand) |
Worse — breaks more frequently than with Anchoring |
| Client-side prediction + server-side authority (RemoteFunction) | Still breaks intermittently |
Suspected Root Cause
Network ownership conflict. The client has simulation authority (network ownership) over their character’s physics. When the server performs PivotTo, the client’s local physics simulation may send conflicting positional data. Remote clients receive both the server’s authoritative PivotTo and the owning client’s physics updates, and the physics engine fails to reconcile them, causing Motor6D joint limits to be exceeded and the joints to break.
This aligns with the official response in Changing CFrame of Character is Inconsistent:
“This should be related to how the client has simulation authority (network owner) of their character. Depending on the client’s network speeds or the last input time, CFrame changes sent from the server could be overwritten by the client.”
Related Reports
- Changing CFrame of Character is Inconsistent
- Server character PivotTo() inconsistencies
- HumanoidRootPart becomes disassociated from rest of character model after teleport
- Character flops after Teleporting the character
Request
A reliable, engine-level mechanism for server-side character teleportation that guarantees joint integrity on all clients. The current workarounds (anchoring, PlatformStand, network ownership transfer, client-side prediction) are either insufficient or cause other issues.