Guide
OneSync Explained for FiveM Server Owners
What OneSync actually does on a FiveM server, which build to run, and the population and entity settings that keep a busy roleplay city in sync.
Kyros2 min read
OneSync is the reason two players can see the same crashed car, the same dropped gun, and the same ped. Without it, a modern roleplay framework is guessing. With it, misconfigured, the server spends its time tracking entities nobody needed.
What it is
OneSync is FiveM's server-side entity system. Vehicles, peds, and objects are owned and synced by the server instead of each client inventing a local copy. Scopes decide which players receive which entities. That is how a 100-player city works at all. It is also why a script that spawns a prop and never deletes it becomes everyone's problem, not just the player who used it.
Turn it on in server.cfg and leave old client-side sync tutorials in the archive. The cfg essentials cover where that line lives. Infinity is the OneSync mode roleplay servers actually want. Legacy is not a personality. It is a smaller cap.
Budgets are the setting that matters
Every vehicle a player owns in a driveway, every ped a job script spawns, every cone a traffic stop leaves on the road, sits in a budget. When the budget is full, the thing players notice is simple: cars popping in late, players appearing on foot, a gun on the ground that only one person can see.
Practical limits:
- Cap parked vehicles per player, and despawn ones nobody is near.
- Delete job props when the job ends.
- Keep NPC traffic and ped density modest. Players are the population.
- Do not run two scripts that both spawn ambient vehicles.
If the city feels empty, add scenes and players before you add density sliders. A crowded sync budget feels worse than a quiet street.
What goes wrong in the console
State bag errors, entity creation failures, and "no such entity" during a delete usually mean a script is touching objects it does not own or objects that already left scope. Update the resource. If it only happens near one MLO or one job, that resource is the lead. The performance guide is how you separate a sync problem from a script that is simply expensive.
Weapon packs are not the usual cause. They stream models. They should not be creating entities every tick. A bad inventory drop that spawns a world object per bullet is a different story.
Client build and artifacts
Run current server artifacts and tell players to use the current FiveM client. OneSync fixes land there. A server pinned to an ancient artifact because one leaked script demanded it will collect bugs the rest of the platform already closed. Legitimate resources, including escrowed packs, are built for the client people actually run.
Test it with two clients
Park a car. Drop a weapon. Walk out of scope and back. Have a second player pick the weapon up. If both clients agree, OneSync is doing the job. If they do not, stop adding content and find the script that spawned the object.
Set the budgets before opening night. A full server is the most expensive moment to discover the city can only sync half of itself.