On this page
An event puts more players, more entities, and more script work in one place at one time, which is the exact load your server was never tested against. Events that go wrong usually go wrong for that reason rather than because the idea was bad, and the fix is scheduling, testing, and a plan for stopping.
What an event actually costs the server
Four separate costs, and they stack:
- Players in one place. Concentration is the cost, not the head count. Forty players spread across the map is a lighter server than forty players in one car park, because in the car park every player's state is relevant to every other player.
- Networked entities. Each one is state the server tracks and replicates. A hundred vehicles staged for a race cost you whether or not anyone is sitting in them, and they cost you from the moment they spawn, not from the start signal.
- The event script. Event resources are written quickly and under a deadline, so they are frequently the worst-performing code on the server. A loop that walks every player, or every entity, multiplies against both of the costs above.
- Client frame rate. Props, particles, and pyrotechnics are mostly a client cost. That still ends your event, because a player at 15 fps leaves.
Measure before you plan. Watch server frame time in txAdmin's performance chart,
and use resmon 1 on a client to see what a resource costs there. See
Optimising a FiveM server for what the numbers
mean and what to do about them.
Schedule around your peak
Run the event when your players are already online. An event at 03:00 gets the people who would have connected anyway.
That means accepting the tradeoff: peak plus event is your worst-case load, and it is a case you have never run. If frame time is already marginal at peak, deal with that before the event rather than during it, or cap the number of participants and entities so the combined load lands somewhere you have seen.
Two scheduling details that ruin events:
- Check your restart schedule and move it. Automatic restarts are set once and forgotten, and a restart in the middle of an event is the worst possible outcome. Leave a clear window afterwards too, for cleanup.
- Announce in a fixed time zone. Give the time in UTC alongside your local time, several days ahead and again about an hour before. People do not convert time zones reliably, and the ones who get it wrong are the ones who complain.
Test on a staging server first
A staging server is a second FXServer with its own port, its own database, and its own key, since a keymaster key identifies one server and is tied to an IP address. Two rules make it useful rather than decorative: never point it at your production database, and give it a name and a port that cannot be confused with production, so a test never lands on the live server by accident. See Configuring server.cfg for the keys involved.
What to test there, in order of what actually catches problems:
Spawn the real quantity
Not one of each. If the event needs 80 vehicles, spawn 80 and watch server frame time in txAdmin with nobody else connected. This part scales without players, so you can measure it honestly with a staff-sized group.
Start and stop the resource repeatedly
Most event resources have never been stopped. Stop it mid-event on staging and see what is left behind and what errors.
Restart the server mid-event
It will happen eventually. Find out now whether the event survives it, whether players lose progress, and whether anything spawns twice.
Try to break the reward path
If the event grants money or items, try claiming twice, disconnecting mid-claim, and joining late. Duplication bugs found on the live server cost you an economy.
You cannot reproduce player concentration with three testers. Approximate it by measuring the entity load separately, then keeping the player-driven part of the event capped the first time you run it.
Running it
Freeze other changes
Stop deploying anything unrelated in the hours before. A surprising share of failed events are caused by a change made the same day that had nothing to do with the event.
Restart shortly before
A clean restart clears accumulated state and gives you the full window before the next scheduled one.
Stage the arrivals
Opening the gate to everyone at once produces a connection burst and a load spike in the same minute. Let people arrive over 10 to 15 minutes, or admit them in groups. If you run rate limits in front of your server, check them before an event, because a hundred clients connecting at once is a traffic shape worth knowing about in advance. See How protection works.
Have someone watching, not playing
One staff member does nothing but watch server frame time and the console for the whole event, and has the authority to stop it without asking.
Decide the stop plan in advance
Write down what you do when the server is struggling: remove entities, split the group across locations, or end early. Deciding this while frame time is climbing produces the wrong answer.
Cleaning up afterwards
Entities created by a server-side script belong to the resource that created them, so stopping that resource is the normal way to remove them. Entities created on a client do not behave the same way. Confirm which case you are in on staging: stop the event resource, look at whether the props and vehicles are still standing there, and plan the cleanup around what you saw rather than what should happen.
The rest of the list:
- Restart after the event. It is the cleanup that works regardless. Announce it so nobody is halfway through something.
- Put the config back. Slot count, whitelist state, and the restart schedule you moved.
- Remove the event resource from
server.cfg, not only from the running server. Stopping a resource that is still listed in the config starts it again at the next restart. - Reconcile what was handed out. You should be able to list exactly what money or items were granted and to whom. If you cannot, add that logging before the next event, because it is also what you need when someone claims they did not receive a reward.
- Write down what broke while it is fresh, including the worst frame time you saw and what was happening at the time. That number is the most useful thing you will have when planning the next one.