Changing CFrame of Character is Inconsistent

[MuffinHandler]

Over the past few month I have been trying to accurately set the CFrame of the character to a part’s CFrame within my round-based game. Despite conducting various tests and sanity checks to ensure the reliability of my code, I’ve encountered a recurring issue where the character’s CFrame fails to update to that of the target part’s CFrame on certain occasions. This anomaly occurs despite all conditions seemingly being met, leading to a situation where the character’s CFrame is successfully set as intended only about 80% of the time, thus highlighting a significant inconsistency in the process.

To address this, I’ve been setting all CFrames for the character on the server side, employing methods such as :PivotTo and directly assigning the HumanoidRootPart.CFrame to the desired CFrame. Unfortunately, both approaches have resulted in the same unpredictable behavior regarding CFrame updates. This inconsistency poses a considerable challenge, impacting the game’s functionality and user experience.

Links to other people facing the same issue:

Updating CFrame of Character is Inconsistent

I’m trying to teleport a character when they press a button but it is inconsistent. This is an issue that I have had for the past year on a few different games. I’m wondering how I can solve it. The issue is the code runs fine but it just doesn’t actually teleport the player. Usually this occurs when the player is experiencing a lag spike and has poor WiFi. For me it probably occurs 1 every 500 times but for other players it seems to occur more often and I get lots of reports of it. I’ve trie…

How can i reliably and accurately position hitbox parts?

Hi, I’m making a fighting game and i was wondering what would be an effective way to position the hitbox correctly when and where it needs to be spawned at. I tried using PVInstance:PivotTo() so that the hitbox spawns in front of the player, which works, but gave inconsistent results in that when it is called while a player is moving, it is positioned incorrectly. I’m unsure if i’m doing something wrong here or if i have to use a different strategy. What can i do? Here’s the code by the way: lo…

Video of inconsistent CFraming:

[MuffinHandler]

There is no error messages. All CFraming for the characters is done on the server using PivotTo.

[MuffinHandler]

Here is the logic:

local tpCF = Selected_Map:WaitForChild("TeleportPart").CFrame
local teleport = tpCF * CFrame.new(0, 7, 0)
char:PivotTo(teleport)

[sicknoobie (Marioman73)]

I bet this is a network ownership issue, the client has control of their character’s physics, so if you set their position and they’re lagging or tabbed out, they might just flatout ignore it and end up teleporting themselves back to where they were.

[lolmanurfunny (lolman)]

You could use a RemoteEvent to tell the client where to go. Or temporarily set the network owner of the player’s HumanoidRootPart to the server.

[SpookerMe]

Have you tried this on the client yet? It should work just fine there. If you’re doing it on the server to avoid abuse, well, that’s sorta useless since players have networkownership of their character anyway.

Also, if you’re doing this on the server, I’m curious about what you mean by doing sanity checks on your code? Is the client sending information to your script? I can’t really think of any client information you would reliably need for this.

[index_self]

This happens very irregularly and especially with adaptive-timestep physics.

I usually remedy pivoting characters on spawn with this little trick:

task.defer(workspace.PivotTo, Character, CFrame)

If that doesn’t work, you could try waiting an extremely short amount of time with this hack:

script:WaitForChild("\0", 0.000001)

I’ve genuinely considered rewriting character spawning just because of how awful the engine treats it.

[MuffinHandler]

I tried these two workarounds before. I will try again if @index_self’s workarounds does not work.

EDIT
The problem is also figuring out if it still happens, as it is very inconsistent.

[MuffinHandler]

Hi, when I refer to sanity checks I meant the code is part of a bigger game logic. Sorry for the confusion, it was unrelated to the CFrames not being reliable.

[MuffinHandler]

Could you please explain how both workarounds work, I don’t quite understand. And is this on the server?

[SpookerMe]

No worries! That makes sense now. But I truly think the best way to handle this if you want consistent results is to just move the character via the client. Is there any reason you wanna do it by the server? The only method that might work with the server is temporarily setting the network ownership of the player character’s primary to nil, but I’m not sure if that even works, and it’s sorta hacky.

[thirdtakeonit]

Thanks for the report! We’ll follow up when we have an update for you.

[Ryguy903]

Did you ever find a fix? I have the same problem

[kleptonaut]

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. There are a couples ways you could overcome this, such:

• Temporarily anchoring the character when teleporting
• Temporarily setting it to be owned by the server via SetNetworkOwnership when teleporting
• Update the CFrame on the client
• Drive the motion physically (constraints, velocity)

Otherwise, this is expected behavior given the current networking model - we won’t address this issue directly so this ticket will be closed. However there will be future updates to the networking model that may make this behavior more consistent in the future.