Why a SCUM server stutters – and what it usually comes down to

Measure first, change second

Nearly every performance hunt on a SCUM server starts wrong: somebody reads about a value, raises it, nothing improves, so they raise the next one. A week later the configuration holds a dozen changes nobody remembers the reason for.

The only reliable starting point is an observation: when exactly does it stutter, and where? Evenings at full capacity is a different thing from always in the same spot. During a cargo drop is different from while exploring. And “the server stutters” is different from “my ping is high” – the latter is about the distance between player and server and no setting can fix it.

A second piece of realism belongs here: if your server runs on hardware shared with others, part of the answer lies outside your configuration. That is no reason to do nothing – but a reason not to expect everything.

Tick rate is a result, not a setting

Tick rate states how often the server computes the world in a second. When it drops, everything gets sluggish: hits register late, vehicles jitter, enemies move in stutters.

There are two values for it, a lower and an upper limit, 5 and 30 by default. Both are routinely misunderstood.

The upper limit is not a wish but a ceiling. Raising it produces no higher tick rate when the hardware cannot deliver one anyway – it merely permits the server to try harder, which can make things worse.

The lower limit is an emergency brake: the server does not fall below it but slows the game world down instead. Raising it sounds like more quality and really means demanding a promise the server cannot keep under load.

In other words: tick rate is the thermometer, not the heating. To improve it you have to reduce the load pressing on it.

What actually creates load

A SCUM server does not compute “the island” but a great many individual objects. Four groups account for practically all the load.

Base elements. Every wall, foundation and door is an object that has to be tracked, saved and replicated to nearby players. A map with fifty generous bases costs measurable tick rate. That is why the element limit per flag is not a matter of taste.

Vehicles. They are more expensive than base elements, because they can move and consist of many parts. A server with generous maximum counts and a long inactivity deadline accumulates vehicles over weeks that nobody uses any more.

Characters. Puppets, armed NPCs and animals. They are the most expensive group, because each of them thinks, moves and perceives noise. This is exactly where the encounter settings intervene.

Dropped items. The quietest item on the list and the one most often overlooked. Everything players drop stays for a while – and on a server running for months that is tens of thousands.

Virtualisation: why the server copes at all

To make those quantities bearable at all, SCUM keeps most objects virtualised: they exist as a record but are not continuously computed. Only when a player comes close enough does the record become a real object in the world.

This system has dials of its own, and they are among the most effective there are. The update period says how often the server checks who is nearby; the time budget limits how long it may spend on that per pass; the bounds define how far it looks.

The key idea: generous virtualisation means more things are ready when somebody arrives – but also that the server constantly has more to do. Frugal virtualisation relieves it while making it visible how things appear.

Almost every complaint about “enemies appearing out of nowhere” and “chests that only show up after a few seconds” leads here – and not to a bug.

The order to investigate in

1. Does it stutter everywhere or in one place? In one place almost always means: there is too much standing there. A very large base, a vehicle depot, a spot where things have been lying for months.

2. Does it stutter at a particular time? Evenings at full capacity is a question of player numbers. Always at the same clock time points to something scheduled – a restart, a backup, an event.

3. Does it stutter during events? Then it is the concentration: many players in one place plus the enemies the event brings along. That is the most demanding situation a SCUM server knows.

4. How much is standing on the map? Element limit per flag, vehicle maximums, decay values. These are the values with the largest effect and the longest lead time – they will not help today, but they stop it being worse in a month.

5. How many characters are active at once? The zone activation distance, the amounts per encounter and the caps for puppets, NPCs and animals. A change here takes effect immediately.

6. Virtualisation only at the very end. It is effective, but every change is also visible in the game. Starting here trades experience for performance without noticing.

What does not help

Raising the upper tick rate. It permits more; it produces nothing.

Lowering the maximum allowed ping. That throws out players on poor connections and changes nothing about the server's load. Below 100 you exclude entire continents.

Lowering the network cull distances for puppets, NPCs and animals. It does save replication – and produces exactly the complaint that enemies only appear once they are already close. Usable as an emergency measure, unpleasant as a permanent state.

Reducing enemy counts globally. That makes the island empty, not fast. The zone activation distance points the same way while keeping the world populated where somebody actually is.

Enabling low player count mode. It does the opposite of what is needed here, and the developers warn about it in capitals.

Leaving network object logging on. It answers precisely the question of which objects create the load – but on a busy server it writes several gigabytes within hours. Switch on, reproduce, switch off, evaluate.