Adapt your scripts to OneSync

OneSync is FiveM's entity synchronization system, enabled by default since 2020. It changed fundamental rules: entities are owned by specific players, the default culling radius is 424 units (entities beyond it are not synced to a client), and events must target the right players. If your resource predates OneSync or you learned from an old tutorial, this lesson fixes the patterns that silently fail.

You'll build: A resource updated for OneSync: entity ownership checks, routing buckets, and scoped events.
Time: ~20 minutes
You need: A local FiveM server, a resource that creates or manipulates entities.
You'll learn: What OneSync changed (entity ownership, scoping), how to check if you own an entity before modifying it, routing buckets, and scoped event triggers.

BEFORE YOU START

Build it

Check entity ownership before modifying

You only modify entities you own.

The wrong way:

code

-- WRONG: may fail silently if another player owns this vehicle
local veh = GetVehiclePedIsIn(PlayerPedId(), false)
DeleteEntity(veh)  -- only works if YOU own it

The right way:

code

-- RIGHT: check ownership first
local veh = GetVehiclePedIsIn(PlayerPedId(), false)
local netId = NetworkGetNetworkIdFromEntity(veh)
local owner = NetworkGetEntityOwner(veh)

if owner == PlayerId() then
DeleteEntity(veh)
else
-- Ask the server to request ownership transfer
TriggerServerEvent('myresource:requestDelete', netId)
end

Server-side:

code

RegisterNetEvent('myresource:requestDelete', function(netId)
local entity = NetworkGetEntityFromNetworkId(netId)
if entity and DoesEntityExist(entity) then
    DeleteEntity(entity)  -- server can always delete
end
end)

Adapt your scripts to OneSync

Build it

Check entity ownership before modifying

Use scoped events instead of broadcast

Use routing buckets for instances

Keep reading the full lesson