SCUM server lag, puppet caps and loot

A SCUM server's performance comes down to how much it has to simulate: players, puppets, animals, sentries, vehicles and every base element ever built, all on an Unreal server where one main thread does most of the work. Plan on at least 8 GB of memory for a small community and 12-16 GB for a busy 64-slot server with large bases, and on fast single-core speed rather than many cores. When it lags, the cause is almost always one of four things - too many players for the CPU, too many AI characters, a world clogged with bases and vehicles, or a long time since the last restart. Loot is a separate system you tune through the Loot override folder and two multipliers in ServerSettings.ini, and getting it right also helps performance, because over-generous loot fills the world with items the server has to track.

The settings referred to here are explained one by one in SCUM server settings explained.

What a SCUM server spends its resources on#

It helps to know where the work goes before changing anything:

• Players. Each connected player is a full character simulation - body state, inventory, metabolism - plus everything replicated to them. Player count is the largest single cost.
• AI characters. Puppets (the infected), animals, sentries and other armed NPCs all run AI. Puppets are the most numerous, and their count is the main dial you control.
• Persistent objects. Every base element, chest, item on the ground and vehicle exists in the world and the save database. A server that has never been wiped and has generous base limits has a lot of them.
• Saving. The world is written to SCUM.db, an SQLite database. A large database makes saves and start-ups slower.

The engine leans on one main thread. Additional cores help with networking, saving and asset streaming, but they do not make the simulation itself faster. That is why a server at "only 40% CPU" overall can still be lagging: one core is at its limit while the others idle. CPU vs RAM for game servers explains how to tell which resource is actually the bottleneck before paying for more of either.

Requirements by player count#

These are working figures from running Unreal survival servers of this kind; your SCUM server may sit lower or higher depending on base density and AI settings. Measure your own before buying.

• Disk: the server install needs well over 10 GB and grows with updates. The save database and logs add more over time. Keep plenty of headroom; a full disk mid-save is how databases get damaged.
• Network: modest per player, latency-sensitive, UDP. Distance to your players matters more than bandwidth - latency, jitter and packet loss explains the difference.

The biggest mistake is setting scum.MaxPlayers to 64 because the field allows it, on hardware sized for 30. The server feels fine at 4am and falls over at 9pm. Pick a number you can serve at peak and raise it when the server is consistently full and still healthy. How many players fit on a server covers the general approach.

Finding the real cause of lag#

"The server is laggy" covers several different problems, and the fix depends on which one you have.

Look at the memory and CPU graphs alongside player count over a full day before deciding. A server whose CPU line hits the ceiling at the same hour every evening has a player or AI problem. A server whose memory line climbs steadily from restart to restart has a state problem that a scheduled restart hides and a wipe or decay setting fixes. Reading a server load graph walks through those shapes.

The levers, in order of effect#

1. Puppet and AI caps

scum.MaxAllowedPuppets caps the infected across the world. Lowering it is the single most effective change on a struggling server, and players rarely notice a moderate reduction - most of the world's puppets are somewhere nobody is standing. Animal density (scum.AnimalGlobalDensityMultiplier) and the per-species prevalence multipliers add more AI; trim those before you trim player slots.

Raising puppet health or damage does not cost CPU directly, but it lengthens fights, and longer fights with more gunfire draw more puppets. It is a difficulty setting with a performance side-effect.

2. Player slots

If the main thread is at its limit with sensible AI settings, the server has more players than the hardware can simulate. Either reduce scum.MaxPlayers or give the server more CPU. A queue at peak is better than a full server nobody enjoys.

3. Bases, flags and decay

Base elements are persistent objects, and a mature server can hold tens of thousands. Three settings keep that in check:

• Flags per player. Leave scum.AllowMultipleFlagsPerPlayer off, or keep scum.NumberOfAllowedFlagsPerPlayer low. Every flag is a base.
• Decay. The base element decay multiplier decides how quickly unmaintained bases fall apart. Some decay clears abandoned bases on its own; zero decay means every base built is permanent until an admin removes it.
• Admin cleanup. Remove abandoned bases on a published inactivity rule, using the destroy commands described in SCUM admin commands and squads.

4. Vehicles

Each vehicle is a persistent physics object. The vehicle section of ServerSettings.ini caps how many of each type can exist and how long an unused vehicle survives. Generous caps plus long inactivity timers produce car parks at every base, and each car costs simulation and save time.

5. Restarts

Unreal servers accumulate state over a long session. Most SCUM servers restart twice a day, which also gives a predictable moment to apply settings changes and updates. Schedule it at the quietest hours, announce it in game, and make sure the stop is clean so the world is saved first. Restart schedules that help covers timing.

The save database and logs#

Everything persistent lives in SCUM/Saved/SaveFiles/SCUM.db, with SCUM.db-wal and SCUM.db-shm beside it. SQLite's write-ahead log (-wal) holds recent changes until they are merged into the main file, which is why the three files must always be copied together, and only with the server stopped. A copy of SCUM.db alone, taken while the server ran, may be missing the last hours of play or may not open at all.

Database size tracks world size. A database that grows steadily week after week is telling you that bases, items and vehicles are being created faster than decay and cleanup remove them. It is the most objective measure you have of whether your base and decay settings are sustainable.

The gameplay logs in SCUM/Saved/SaveFiles/Logs/ also grow constantly. They do not slow the game, but they fill the disk, and a full disk during a save is how a database gets damaged. Archive and prune them on a schedule.

Back up the database daily at minimum, and before every update, wipe or large cleanup. Backups that actually restore makes the case for testing one occasionally - a database that was copied mid-write looks fine until the day you need it.

How SCUM loot works#

Loot in SCUM is produced by spawners: points in the world, and examinable containers such as cupboards and lockers, each assigned a spawner preset that lists what can appear and how likely it is. Two global multipliers in ServerSettings.ini scale everything:

scum.SpawnerProbabilityMultiplier=1scum.ExamineSpawnerProbabilityMultiplier=1scum.EnableItemCooldownGroups=1scum.ItemCooldownGroupsDurationMultiplier=1.000000

The first scales open-world spawners, the second searchable containers. Cooldown groups stop the same class of valuable item from spawning again too soon after one was found; their duration multiplier lengthens or shortens that wait.

For anything finer - more food but not more guns, fewer rifles in police stations, a specific item in a specific sector - you use the loot customisation folder.

The Loot override folder#

Loot customisation lives under SCUM/Saved/Config/WindowsServer/Loot/:

Loot/  GeneralZoneModifiers.json  Nodes/Default/          Nodes/Override/  Items/Default/          Items/Override/  Spawners/Presets/Default/   Spawners/Presets/Override/  CooldownGroups/Default/     CooldownGroups/Override/

The Default folders are references: the game's own values, exported so you can read them. Only files in the `Override` folders change anything. Editing a file in Default does nothing, which is the most common reason a loot change appears to have no effect.

The defaults are produced by admin commands run in game chat:

The workflow:

1. Export the defaults for what you want to change.
2. Copy only the files you are changing into the matching Override folder, keeping the structure.
3. Edit the copies.
4. Run #ReloadLootCustomizationsAndResetSpawners, or restart.
5. Check in game, in a sector where the change should show.

A spawner preset lists items with a rarity, plus fields such as Probability, QuantityMin and QuantityMax, AllowDuplicates, InitialDamage and RandomDamage, ShouldFilterItemsByZone, and FixedItems for guaranteed drops. The exact schema is in the exported files; edit those, not an example from a guide written for an older build.

GeneralZoneModifiers.json applies modifiers by zone, which is how you make one region richer or poorer without editing every preset in it - useful for an event area or a deliberately dangerous high-loot zone.

Loot tuning that players thank you for#

• Boost basics, not weapons. Food, water containers, clothing and tools raised a little make the first hour less of a grind. Raising weapon and ammunition spawns ends progression in a day.
• Keep cooldown groups on. They are what stops the same high-value item from appearing in every second locker after a lucky streak.
• Move gently. Global multipliers of 1.25 to 1.5 feel generous. Doubling everything floods the world, and more items lying about is more for the server to track and save.
• Change one thing at a time and play for a day before judging. Loot spawns over time, not at the moment of a reload.
• Keep your overrides small. An Override folder holding only the files you changed survives game updates much better than a full copy of every default, which you would have to re-check after each patch.

Troubleshooting#

Loot changes do nothing. You edited a Default file, or the override is not in the matching path under Override, or the JSON failed to parse. Check the structure and validate the JSON.

Loot is everywhere after a change. A global multiplier was raised as well as presets. Remember the multipliers stack.

The server slows down every evening. Main-thread saturation at peak: lower the puppet cap, then the slots, before buying memory.

Lag around one base. Too many base elements in one place. Limits on flags and some decay help over time; an admin conversation helps faster.

Memory climbs until the server crashes. Restart on a schedule, and check base and vehicle counts. If the host stops the server at its memory limit, the world loses everything since the last save, so do not run at the edge.

The database is growing every week. Bases and vehicles are created faster than they are removed. Tighten decay, flag limits and vehicle caps, and plan a wipe if needed.

FAQ#

How much RAM does a SCUM server need?

Around 8 GB for a small group, 10-12 GB for a small community and 12-16 GB or more for a busy 64-slot server. Base and vehicle counts matter as much as players.

Why does my SCUM server lag with low CPU usage?

Overall CPU usage hides one saturated core. SCUM's simulation runs mostly on one main thread, so check per-core load, and reduce AI or player count if that core is at its limit.

What is the easiest way to improve SCUM server performance?

Lower scum.MaxAllowedPuppets, keep base and vehicle limits sensible, and restart twice a day. Those three cover most servers.

Why do my loot overrides not work?

Only files in the Override folders are read; the Default folders are exported references. Copy the file into the matching Override path and reload.

Can I reload loot without restarting?

Yes. #ReloadLootCustomizationsAndResetSpawners reloads the override files and resets spawners from in game chat.

Does more loot hurt performance?

Indirectly. More items in the world means more objects to track and save. Modest boosts are fine; flooding the world is not.