Setting a Character's PrimaryPart Position offsets replication

(Let me first start off by saying, I know it’s bad practice to set a character/npcs humanoidrootpart position. :SetPrimaryPartCFrame() is the proper way. But this was happening to a friend of mine who is newer to Roblox scripting. I had him switch, but I still feel like this should be fixed so new people don’t run into dumb issues like this.)

Setting the Position on a Character’s RootPart (This includes NPCs too) has weird replication results. Players in the game when the change happens don’t see a problem, but players who join after a character has had the rootpart position set will see them visually offset in random places, but still can interact with the collisions in the place they actually are.

This bug happens in studio for sure. I’m not exactly sure if it happens as much in actual game. I tested this in Studio with a bunch of testplayer clients. I can’t seem to get consistent results. Sometimes all the players get offset, sometimes just one does. But the server always sees the visuals of the character in the wrong place.

This is what some players see.

This is what the server sees.

This is the video better showing it.

Can you provide a simple file with code that reproduces this?

Position Bug Repro.rbxl (20.8 KB)
There you go. For easiest results, just spawn a few test players in and have them walk onto the teleporter and not move, then take a look at the server studio window.

This is happening because you’re setting the Position property. When you set the position property of a part all JointInstance joints (including Motor6Ds) will have their C0/C1 properties updated to allow the part to move relative to any parts it’s connected to. We went with this behavior because it’s consistent with the behavior for WeldConstraints.

Layered on top of this is some weird Humanoid quirks that are re-rigging the character on the client and overwriting those C0/C1 updates from the server…

Setting the CFrame property of the root part should work just fine. The CFrame property setter doesn’t have this behavior. Basically, setting the Position or Orientation properties in scripts is usually a bad idea that has weird side effects. I’d try to deprecate them if not for a lack of tools for editing CFrame values in Studio.

Noticing our API documentation doesn’t describe this behavior… I’ll make sure those docs get updated.

12 Likes

Do you happen to know if there is a feature request outstanding for a CFrame editor?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.