FiveM OneSync, player slots and culling

Without OneSync a FiveM server is capped at 32 players by GTA V's own peer-to-peer networking. With set onesync on the server becomes the authority for entities, the ceiling rises far above anything a roleplay server can actually run, and players only receive what is near them. The two numbers that decide your real slot count are elsewhere: the slot tier attached to your Cfx.re key (the free tier has historically stopped at 48), and how much main-thread and sync-thread time your resources leave over. This post covers what OneSync changes, the convars that control it, culling and routing buckets, entity lockdown, and how to pick a slot count you can keep.

What OneSync actually changes#

GTA V's multiplayer was built for sessions of a few dozen players, where each client owns some of the entities and tells the others about them directly. FiveM without OneSync keeps that model: the server relays traffic, but the game's own sync decides who knows about what, and the 32-player limit is part of it.

OneSync replaces it with server-side state. Every networked entity - players, vehicles, peds, objects - is tracked by FXServer, which knows where each one is and which client currently owns it. Clients still simulate the entities they own, but the server decides who receives updates about what. Four practical consequences follow:

• Slots above 32 become possible. The engine ceiling with OneSync is in the four figures. Nobody should use it.
• The server can see everything. Server scripts can read any player's ped and coordinates with GetPlayerPed(source) and GetEntityCoords, which without OneSync only worked on the client.
• Clients see only what is near them. Players and entities beyond a culling radius are not sent to a client at all.
• The server can refuse entities. Because the server is the authority, it can block clients from creating entities, which is the most useful anti-cheat setting FiveM has.

OneSync is not optional for a modern server. Current frameworks, inventories and most resources from the last few years assume it, and many will not work correctly without it.

The convars#

set onesync onset onesync_population trueset onesync_forceMigration truesv_maxclients 48

legacy is the original OneSync implementation, kept for compatibility. It has a lower ceiling and sends more to every client; there is no reason to choose it for a new server. Very old guides use onesync_enabled 1 and onesync_enableInfinity 1. Those are the obsolete spellings of onesync on and should be removed if you find them.

Two things about how these are read. OneSync has to be decided before the server finishes starting, so changing it means a full server restart - restarting a resource does nothing. And txAdmin has its own OneSync setting in its FXServer settings page in the versions that offer it, which it passes on the command line; if your server.cfg says something different, one of them wins and you may not be looking at the one that did. Set it in one place. The rest of the file is covered in FiveM server.cfg explained.

sv_maxclients also needs a full restart. The hardcap resource from the default server data is what turns players away when the server is full; keep it in your ensure list unless a queue resource replaces it.

Slot limits: engine, licence and reality#

There are three limits stacked on top of each other, and the lowest one wins.

The licence tier is the one people trip over. For years, a free key has allowed up to 48 slots with OneSync, and higher slot counts have required a Cfx.re subscription tier (sold as Element Club) attached to the account that owns the key. Cfx.re has changed the names and thresholds of those tiers before, so check the current figures in the Cfx.re portal rather than trusting a number from a forum - including this one. If you set sv_maxclients above what your key allows, the server tells you at startup.

The reality limit is the one that matters. A slot is a promise that one more person can be on the server without making it worse for the rest. On a roleplay server with two hundred resources, each additional player adds work to every per-player loop, every event that is broadcast to all, and every entity they bring with them. The server will accept 128 connections long before it can serve them well.

Start lower than you think, watch the txAdmin tick chart and the console's hitch warnings at peak, and raise the count when the numbers say you can. Lowering slots after a community has got used to a number is far harder than raising them. How many players fit on a server has the general argument, and FiveM server performance shows how to read the tick data.

Culling: what each player can see#

With OneSync on, each client is sent only the players and entities within a culling radius of their own position - about 424 units by default. Outside that radius, an entity does not exist for that client.

This is the reason OneSync scales at all, and it is the reason a lot of older client scripts misbehave on it:

• Client-side player lists are partial. GetActivePlayers() on a client returns only players in range. A scoreboard built on it shows a handful of names on a sixty-player server. Build player lists server-side and send them down.
• Blips for distant players need the server. A client cannot place a blip on a ped it has not been sent. Police and EMS blip resources that work on OneSync send coordinates from the server on a timer.
• Client-side lookups of far entities fail. NetworkGetEntityFromNetworkId on a client returns nothing for an entity outside its range. Do the work on the server, or wait until the entity is in range.

FXServer exposes server-side natives to change the radius - SetPlayerCullingRadius for one player and SetEntityDistanceCullingRadius for one entity. They have their uses (a spectating admin, a helicopter that should be visible from further away), but raising them broadly sends more data to every client and costs sync time, so use them for specific cases rather than as a setting.

Routing buckets: separate worlds on one server#

A routing bucket is a separate instance of the world. Players and entities in bucket 3 cannot see or interact with anything in bucket 0, even standing in the same spot. Everyone starts in bucket 0.

-- server side: put a player and their vehicle into a private instanceSetPlayerRoutingBucket(source, 3)SetEntityRoutingBucket(vehicle, 3)-- an empty instance with no ambient traffic and no client-created entitiesSetRoutingBucketPopulationEnabled(3, false)SetRoutingBucketEntityLockdownMode(3, "strict")

Roleplay servers use buckets for character selection, apartment interiors that every player gets their own copy of, admin spectating, and events that should not disturb the main city. They are cheap: an empty bucket costs nothing, and players in different buckets do not sync with each other. Remember to put players back in bucket 0 when they leave the instance - a player stranded in a bucket sees an empty city and reports the server as broken. GetPlayerRoutingBucket(source) tells you where somebody is.

Population and entity counts#

Ambient traffic and pedestrians are entities, and on OneSync they are server-tracked entities. A busy city with sixty players can carry thousands of them, and every one costs the sync thread. The settings that control this:

• `onesync_population false` stops ambient population entirely. The city is empty, and the server carries only the entities scripts create. Several serious roleplay servers run this way and spawn traffic only where it matters.
• Density natives on the client. SetVehicleDensityMultiplierThisFrame, SetPedDensityMultiplierThisFrame and their relatives reduce population without turning it off. They have to be called every frame, which is one of the legitimate uses of a Wait(0) loop.
• Per-bucket population. SetRoutingBucketPopulationEnabled turns population off in specific instances.

Entities that scripts create are the other half. Vehicles spawned from garages and never despawned, props dropped by jobs and left behind, peds from missions nobody finished - all of them stay in the server's state. Server-created entities can be told what to do when nobody is near them with SetEntityOrphanMode on builds that support it; otherwise, clean them up yourself. If sync-thread hitch warnings grow over uptime, entity build-up is the first suspect, and a scheduled restart is the blunt fix while you find the resource responsible. Restart schedules that help covers timing.

onesync_forceMigration true matters here too. When a player who owns an entity disconnects, the server hands it to another nearby player instead of deleting it. Without it, a car somebody was driving can vanish the moment they crash out of the game.

Entity lockdown#

Because the server is the authority under OneSync, it can refuse to let clients create entities. That is sv_entityLockdown:

set sv_entityLockdown "relaxed"

The default is inactive, which lets a cheat menu spawn any vehicle, ped or prop it likes. relaxed blocks entities created by client scripts while keeping ambient traffic working, and it stops most of the spawn spam that defines a cheater's visit. strict blocks everything, so ambient population stops too, and every vehicle a player gets must be created by the server.

Lockdown is also a filter on your resources. A garage, job or admin menu that spawns vehicles client-side breaks under relaxed. The fix is to create the entity on the server and hand the network ID to the client:

-- server sidelocal veh = CreateVehicleServerSetter(model, "automobile", x, y, z, heading)local netId = NetworkGetNetworkIdFromEntity(veh)TriggerClientEvent("garage:vehicleReady", source, netId)

CreateVehicleServerSetter is the newer server-side creation native and is preferred over the older server-side CreateVehicle for vehicles; check that your server build supports it. Most current frameworks and garages already work this way. Turning lockdown on in a test instance, or per bucket with SetRoutingBucketEntityLockdownMode, is a cheap way to find which of your resources do not. The rest of the defensive settings are in FiveM anticheat options.

State bags#

OneSync also enables state bags: key-value data attached to an entity, a player or the server as a whole, synchronised to clients automatically.

-- serverPlayer(source).state:set("job", "police", true)   -- true = replicated to clientsEntity(vehicle).state:set("fuel", 64.0, true)GlobalState.weather = "RAIN"-- clientlocal fuel = Entity(vehicle).state.fuel

They replace a lot of hand-written "send everyone the new value" events. They are only as cheap as you make them, though: a state bag changed every frame on a hundred vehicles is a hundred updates a frame for the sync thread. Write on change, not on a timer. And a state bag a client can write is client-controlled data - server scripts must not trust values clients are allowed to set.

Troubleshooting#

`sv_maxclients` above 32 is ignored. OneSync is off, or set in a place that does not take effect. Confirm onesync on in the startup output and restart the whole server.

The server refuses the slot count at startup. Your key's tier does not allow it. Lower sv_maxclients or change the tier on the account that owns the key.

The scoreboard shows only a few players. It is built client-side with GetActivePlayers(). Move it to the server.

Garages stopped spawning cars after enabling lockdown. They create vehicles on the client. Update the resource or switch it to server-side creation.

Cars vanish when their driver disconnects. Enable onesync_forceMigration.

Sync thread hitches get worse every hour. Entity build-up. Count what scripts spawn and never delete, consider turning ambient population down, and restart on a schedule while you fix it.

FAQ#

Is OneSync Infinity still a separate setting?

No. set onesync on is what used to be called Infinity. The old onesync_enableInfinity convar is obsolete, and legacy exists only for compatibility with old resources.

How many slots can a free FiveM key use?

Historically 48 with OneSync enabled. Higher counts have needed a Cfx.re subscription tier on the account that owns the key. Cfx.re has changed these thresholds before, so check the portal for the current figure.

Why can players not see each other across the map?

That is OneSync culling working as intended. Each client receives only entities within about 424 units. Anything that needs distant players - blips, scoreboards - has to be built on the server.

Does a higher slot count make the server slower?

Not by itself; an empty slot costs nothing. Players filling those slots do, because per-player loops, broadcast events and the entities each player brings all add work to the main and sync threads.

Should I turn off ambient population?

On a busy roleplay server it is worth testing. It removes a large share of entities and sync work, at the cost of an empty city. Many servers reduce density with client natives instead, which keeps some traffic for a fraction of the cost.