Desync is the most common complaint on FiveM servers. Players see different things, vehicles teleport, and actions don't register properly. Most desync is fixable with proper configuration and development practices.
Understanding Desync
Desync happens when the client's game state diverges from the server's game state. In GTA V's networking model, this occurs because:
- Network latency: Information takes time to travel between client and server
- Entity ownership conflicts: Multiple clients think they control the same entity
- State synchronization delays: Complex entity states (vehicle damage, player animations) take multiple packets to sync
- Server overload: When the server can't process events fast enough, state updates queue up
OneSync Configuration
OneSync is FiveM's entity synchronization system. Proper configuration eliminates most desync:
server.cfg
set onesync on
set onesync_distanceCullVehicles true
set onesync_forceMigration true
set onesync_logFile ""
Key Settings
onesync_distanceCullVehicles: Vehicles beyond render distance aren't synced. Reduces network load dramatically.
onesync_forceMigration: When a player disconnects, their entities migrate to the nearest player. Without this, disconnected players' vehicles freeze.
Entity Limits
set onesync_workaround340MaxPlayers 64
sv_maxclients 64
OneSync handles up to 2048 entities simultaneously. For 64 players, each player effectively gets ~32 entities in their vicinity. Beyond this, entities further away get culled.
Entity Ownership
The most technical cause of desync is ownership conflicts. Each entity has one "owner" - the client responsible for simulating it. When ownership is unclear:
Vehicle Ownership
The driver owns the vehicle. Passengers don't send vehicle state updates. Problems occur when:
- Driver disconnects while passengers are in the vehicle
- Two players enter the same vehicle simultaneously
- Server scripts change vehicle state without proper ownership transfer
NPC Ownership
NPCs are owned by the nearest player. As players move, NPC ownership transfers. If the transfer is slow, you see NPC teleporting.
Fixing Ownership Issues in Code
-- Server-side: Proper entity creation with ownership
local vehicle = CreateVehicle(model, x, y, z, heading, true, true)
local netId = NetworkGetNetworkIdFromEntity(vehicle)
-- Assign ownership to the requesting player
SetEntityRoutingBucket(vehicle, 0)
Network Optimization
Tick Rate
FiveM servers run at a default tick rate. Higher tick rates send more frequent updates but consume more CPU:
set sv_minClientRate 60000
set sv_maxClientRate 100000
Resource Event Optimization
Every event sent between client and server consumes bandwidth. Optimize:
-- BAD: Sending entire player table every second
SetTimeout(1000, function()
TriggerClientEvent("updateAllPlayers", -1, GetAllPlayerData())
end)
-- GOOD: Send only changes, only to nearby players
RegisterNetEvent("playerPositionUpdate")
AddEventHandler("playerPositionUpdate", function(data)
local source = source
local nearby = GetNearbyPlayers(source, 100.0)
for _, player in ipairs(nearby) do
TriggerClientEvent("updateNearbyPlayer", player, source, data)
end
end)
Server Performance Impact
Desync gets exponentially worse as server tick time increases. A server running at full capacity:
- Takes longer to process state changes
- Queues network updates
- Falls behind real-time
- Players experience delayed state
On Space-Node's FiveM hosting, the Ryzen 9 7950X3D keeps tick times low even at high player counts. Raw CPU speed is the primary factor in minimizing desync - faster processing means fresher state data reaching clients.
Checklist for Desync Reduction
- Enable OneSync with proper configuration
- Set appropriate entity limits for your player count
- Optimize resource events (reduce frequency and payload size)
- Handle entity ownership correctly in scripts
- Monitor server tick time (should stay below 33ms for 30fps tick)
- Use distance-based culling for entities players can't see
- Test with realistic player counts, not just development conditions
