Disclaimer: This post is for educational and informational purposes only. It does not encourage or promote any unauthorized activities. The content is strictly intended to explain technical concepts and improve understanding.
Hey everyone!
I’ve noticed that many people struggle to fully understand this topic and find it difficult to explain the underlying mechanics. Because of that, I decided to dive deeper into this subject and provide a clear, detailed explanation. My goal is to help more people grasp the mechanics behind desyncs.
To begin with, Roblox experiences are multiplayer by default and operate on a client-server model. In this setup, the server acts as the central authority, ensuring that all connected clients remain synchronized. However, due to network latency and processing delays, there will always be some level of desynchronization.
This means that your position on your own screen, your position as seen by the server, and your position on other players’ screens will rarely be perfectly identical - especially when moving. (see the image below for reference)
And as strange as it may sound, even the positions shown in the attached image are delayed. In short, latency is everywhere.
As you can see in the image, all three positions are different. The target’s position on the server will always be more up-to-date than the one displayed on your screen. But why am i showing this to you?
Personally, I categorize desyncs into two types: useful and useless. This might sound strange, but let me explain.
Type 1) Client-Side Ghosting (Low-Impact Desyncs)
This type of desync has been publicly available for a long time, is the easiest to create, and offers the least benefit. Today, we’ll go over some variations of code for these desyncs and explain why and how they work.
The core idea is that this type of desync allows you to manipulate the position that gets sent to the server. In simple terms, you could be standing at (0, 0, 0) in XYZ coordinates but tell the server that you’re actually at (0, 5, 0). I’m sure you get the idea.
But why is this of little use? The problem is that it doesn’t significantly affect how your position is perceived by other players, as their clients still rely on server data. This is because your position on other players’ screens will still try to sync up with the server’s position. (example below)
As you can see, even though my client’s position is desynchronized from both the server’s position and the position shown to other players, the position displayed to others is still ultimately based on the server’s data.
Why does this happen? Understanding Basic Client-Server Replication
In a client-server model, all movement data follows a specific flow:
- Your client calculates your new position and sends it to the server.
- The server processes the new position and validates it.
- The server then sends this updated position to all other clients.
- The other players’ clients receive the position update and adjust their view accordingly.
However, this process isn’t instant. There’s always a delay (latency) between:
- When your client sends the position update.
- When the server processes and sends it to others.
- When other clients receive and display your new position.
By the time other players see your updated position, you’ve already moved again. This is why positions never perfectly match - there’s always a small delay, causing slight desynchronization between what each player sees.
Type 2) Phantom Positioning (High-Impact Desyncs)
This type of desync allows you to fully desynchronize the position displayed to other players from the actual server-side position. Let me explain how this works:
Normally, after the server receives and validates your new position, it sends that data to all other clients, where it is then rendered visually. However, high-impact desyncs disrupt this process - the server successfully updates your position, but for some reason, other players do not see this update on their screens.
This means that while your actual position (as recognized by the server) is in one place, the position displayed to others remains outdated. Below is an example demonstrating this effect.
Sorry for the lag in the recording - im having some internet issues. But I think you still get the idea!
Now, let’s analyze how to achieve the first type of desync.
Understanding Frame Segmentation in Roblox
Each frame in Roblox can be broken down into multiple stages/steps:
- RenderStepped – Executes first, mainly for rendering-related tasks.
- Stepped – Part of the rendering process, runs before physics updates.
- Heartbeat – Executes after physics updates.
As you can see, RenderStepped occurs first, followed by Stepped, and then Heartbeat. In more recent versions of Roblox, additional stages have been introduced, such as:
- PostSimulation (fires every frame, after the physics simulation has completed)
- PreAnimation (fires every frame, prior to the physics simulation but after rendering)
- PreRender (fires every frame, prior to the frame being rendered)
- PreSimulation (fires every frame, prior to the physics simulation)
However, these new stages do not alter the core process we aim to analyze.
Frame Segmentation for Desyncs
The key insight is that after the Heartbeat step, the engine sends property updates and events to the server. This means that the position of our character, along with other key properties, is only transmitted at this moment.
This allows us to perform a seamless switch by following these steps:
- Maintain a normal position throughout the frame – This ensures that everything appears natural.
- Right before the Heartbeat update, modify the position – This alters what gets transmitted to the server.
- Immediately after the update, revert back to the normal position – Ensuring that local physics and rendering remain unaffected.
Why This Desync Is Invisible Locally
A crucial detail is that Heartbeat is not part of the rendering process. This means that any position change made just before Heartbeat and reverted immediately afterward will never be visible on our screen. The desynchronized position only affects what gets sent to the server, while our local view remains unchanged.
This technique is useful for game developers to create unique mechanics, such as:
- Custom movement systems
- Ghosting mechanics
Now, let’s look at an example implementation:
local runService = game:GetService("RunService")
local players = game:GetService("Players")
local findFirstChild = game.FindFirstChild
local bindToRenderStep = runService.BindToRenderStep
local localPlayer = players.LocalPlayer
local newCFrame = CFrame.new
local newVector3 = Vector3.new
-- function to check if the local player is alive
-- (ensures the player has a character, a humanoid, sufficient health, and a humanoid root part)
local function localPlayerIsAlive()
local character = localPlayer.Character
return character
and findFirstChild(character, "Humanoid")
and character.Humanoid.Health > 0
and findFirstChild(character, "HumanoidRootPart")
end
-- function to get the local player's current position (CFrame)
local function getLocalCFrame()
return localPlayerIsAlive and localPlayer.Character.HumanoidRootPart.CFrame
end
-- table to store position data
local cframes = {}
-- heartbeat event: runs just before the engine sends property updates to the server
runService.Heartbeat:Connect(function()
cframes.client = getLocalCFrame() -- store the local player's actual position
local realCFrame = cframes.client
if realCFrame then
local desyncCFrame = realCFrame
-- apply any modifications to the CFrame (e.g., move the character up by 5 studs)
desyncCFrame = desyncCFrame + newVector3(0, 5, 0)
-- set the humanoid root part to the modified (desynchronized) position
localPlayer.Character.HumanoidRootPart.CFrame = desyncCFrame
cframes.desync = desyncCFrame
else
-- if something goes wrong, reset the stored positions
cframes.desync = nil
cframes.client = nil
end
end)
-- render step event: runs before the frame updates on our screen
-- we need to restore the original position before rendering to prevent visual issues
bindToRenderStep(runService, "New Frame Start", Enum.RenderPriority.First.Value, function()
if cframes.client then
localPlayer.Character.HumanoidRootPart.CFrame = cframes.client
end
end)
