Config.json Items Section Reference
The Items section of an Unturned dedicated server Config.json controls the item economy: how many items appear on the ground, how long they stay there, how fast they come back after being picked up, what quality they spawn at, whether that quality decreases with use, and how much ammunition guns and magazines hold when a player first picks them up. Twenty keys govern this entire surface. If you are running a server and want to tune whether your players are scavenging desperately for scraps or tripping over piles of pristine loot, this is the section that makes that happen.
Every key in the Items section is optional. When a key is absent from the config, the server applies its own hardcoded default silently. An empty Items section is not a broken config -- but it is a config where every supply-side decision has been deferred to the game's general-purpose baseline. The baseline was chosen to produce a consistent item economy across every official map. It was not chosen for a specific server community, a specific play style, or a specific loot-pressure vision. Every key in this section is a point of deliberate control.
This article documents all twenty keys individually, but its real subject is the interactions between them. Item scarcity is not one slider. It emerges from the relationship between how many items spawn (the spawn cap), how fast they return after being taken (the respawn timer), how long they persist before being cleaned up (the two despawn timers), and what condition they are in when a player reaches them (the quality and ammo systems). Change one key and the effect is linear. Change four keys together and the effect reshapes the entire tempo of scavenging on your server.
Each key description is based on the game's internal documentation of what the key does, restated in plain language for a server operator who has never edited this file before. No numbers are invented or estimated beyond what the game's own field descriptions provide. No key is described in terms of a specific map or playtest; the article focuses on what the key does mechanically so that you can apply it to your own server's design.
What this section governs
The Items section is one of several top-level sections in Config.json. Its scope is specific and bounded: it controls the lifecycle of items that exist in the world as spawned ground loot. It does not control what items spawn -- that is the domain of the map's spawn tables. It does not control where items spawn -- that is the domain of the map author's spawn-point placement in the level editor. It does not control item stats such as damage, range, or capacity -- those are defined in each item's own asset file.
What the Items section does control is what happens after the spawn table and the spawn point have done their work. A spawn table selects an item to place at a given spawn point. The Items section then decides, for every such item in the aggregate, how many can be present at once, how long each one stays before expiring, how fast the system replaces items that have been removed, what quality the item has when it appears, whether that quality will degrade through use, and how much ammunition firearms and magazines carry when found.
Think of the relationship between spawn tables and the Items section as a factory and its output channel. The spawn tables are the factory floor: they determine what gets made. The Items section is the output channel: it determines how much of it can be in circulation, how fast it moves, and what condition it arrives in. A server with aggressive spawn tables that list rare weapons at every spawn point will still have a scarce economy if the Items section caps the active count low and sets respawn timers to an hour. A server with deliberately restrained spawn tables will still flood its players with gear if the Items section sets the spawn cap to maximum and the respawn timer to ten seconds. The two systems work together; the map author designs the menu, and the server operator controls the pace at which the kitchen sends it out.
The section also governs items dropped by players, which bypass the spawn table system entirely. When a player drops an item from their inventory -- whether intentionally, through death, or through a game mechanic -- that item enters the world as ground loot. The Items section's despawn timers apply to that item the same way they apply to naturally spawned items, with the distinction that dropped items and naturally spawned items get separate timers. This means the section controls not just the baseline item field but also the persistence of player-generated loot, which has significant implications for post-death gear recovery and for the accumulation of abandoned equipment in high-traffic areas.
How the Items section is loaded
When a server starts, it reads Config.json from its configuration directory. The Items section is a top-level JSON object. The expected structure at the file level looks like this (other sections omitted for clarity):
json
{
"Easy": { ... },
"Normal": { ... },
"Hard": { ... },
"Items": {
"Spawn_Chance": 0.35,
"Despawn_Dropped_Time": 600.0,
"Despawn_Natural_Time": 900.0,
"Respawn_Time": 60.0,
"Quality_Full_Chance": 0.1,
"Quality_Multiplier": 0.5,
"Gun_Bullets_Full_Chance": 0.1,
"Gun_Bullets_Multiplier": 0.3,
"Magazine_Bullets_Full_Chance": 0.15,
"Magazine_Bullets_Multiplier": 0.3,
"Crate_Bullets_Full_Chance": 0.15,
"Crate_Bullets_Multiplier": 0.3,
"Has_Durability": true,
"Food_Spawns_At_Full_Quality": false,
"Water_Spawns_At_Full_Quality": false,
"Clothing_Spawns_At_Full_Quality": false,
"Weapons_Spawn_At_Full_Quality": false,
"Default_Spawns_At_Full_Quality": false,
"Clothing_Has_Durability": true,
"Weapons_Have_Durability": true
},
"Players": { ... },
"Vehicles": { ... }
}The example values above are for illustration only and do not represent any specific configuration. They show valid JSON syntax and the correct nesting level for each key.
If the Items section is present but individual keys within it are absent, the server applies its hardcoded default for only those missing keys. The section does not require all twenty keys to be present to load correctly. A partial Items section is valid. A section that contains only Spawn_Chance and Respawn_Time will work: those two keys are applied, and the other eighteen keys use their internal fallbacks.
Keys with the type float accept decimal values. Where the game describes a key as accepting a percentage in the 0-to-1 range, a value of 0.5 means 50%, a value of 0.1 means 10%, and so on. Keys with the type bool accept true or false (lowercase, without quotes in the JSON).
The default for every key in the Items section is not documented publicly by the game. The game's internal field descriptions report each default as a dash, meaning the server applies its own hardcoded fallback when the key is absent. Server owners who want to know what the baseline is for a specific key should start the server with the Items section entirely absent, observe the behaviour, and then add keys to override the defaults they want to change. This is a deliberately slow approach, but it is the only reliable one when the published defaults are not available.
Keys whose default column shows a hyphen in the table below follow this same pattern: they use the game's own internal fallback value, and that value is not stated in the publicly available field descriptions.
There is no validation beyond type checking by the server. A float key assigned a string value will be ignored. A bool key assigned a number will be treated as false or may cause a parse error for the section. The server does not automatically reload Config.json while running. Any change to the Items section requires a server restart to take effect. Server owners should validate their JSON syntax with a linter before deploying a config, and should check the server console on startup for any parse warnings that reference the Items section.
Complete key table
The following table lists every key in the Items section, its data type, and its default value as reported by the game's internal field descriptions. Copy this table exactly when referencing the Items section. Do not add keys that are not listed here.
| Key | Type | Default |
|---|---|---|
Spawn_Chance | float | - |
Despawn_Dropped_Time | float | - |
Despawn_Natural_Time | float | - |
Respawn_Time | float | - |
Quality_Full_Chance | float | - |
Quality_Multiplier | float | - |
Gun_Bullets_Full_Chance | float | - |
Gun_Bullets_Multiplier | float | - |
Magazine_Bullets_Full_Chance | float | - |
Magazine_Bullets_Multiplier | float | - |
Crate_Bullets_Full_Chance | float | - |
Crate_Bullets_Multiplier | float | - |
Has_Durability | bool | - |
Food_Spawns_At_Full_Quality | bool | - |
Water_Spawns_At_Full_Quality | bool | - |
Clothing_Spawns_At_Full_Quality | bool | - |
Weapons_Spawn_At_Full_Quality | bool | - |
Default_Spawns_At_Full_Quality | bool | - |
Clothing_Has_Durability | bool | - |
Weapons_Have_Durability | bool | - |
If a key does not appear in this table, it is not part of the Items section. Do not invent keys or copy keys from other sections into this object. The game will ignore unrecognised keys, but they clutter your config and may mislead anyone else who reads the file.
Understanding the float-type keys: the 0-to-1 convention
Ten of the twenty keys in the Items section are of type float. Eight of those ten are described by the game as accepting a value in the range 0 to 1 that represents a percentage or a probability. This convention shows up across multiple Config.json sections and it is worth understanding clearly before you tune any individual key.
A value of 0 means "zero percent" or "this thing never happens." A value of 1.0 means "one hundred percent" or "this thing always happens." A value of 0.35 means "thirty-five percent." Every float key that follows this convention uses the same scale. There is no hidden multiplier, no engine tick conversion, no normalisation step. If the key says it accepts a percentage from 0 to 1, then 0.25 literally means 25%, and that is the end of the calculation.
Three of the other float keys in the section -- Despawn_Dropped_Time, Despawn_Natural_Time, and Respawn_Time -- represent time in seconds and do not use the 0-to-1 convention. They are direct values: 300.0 means 300 seconds (five minutes), 60.0 means 60 seconds (one minute), and so on. Reading a time key as a probability (interpreting 0.5 as "50% chance of despawning" rather than "half a second") is a common mistake and will produce wildly wrong behaviour.
The ninth and tenth float keys -- Spawn_Chance and Quality_Multiplier -- each have their own interpretation rules. Spawn_Chance uses the 0-to-1 scale but its meaning is a cap, not a probability per spawn point. Quality_Multiplier is a scaling factor applied to a random quality roll and is not inherently bounded to the 0-to-1 range, though most configurations keep it there. Both are explained in detail in their respective sections below.
The distinction matters when you are scanning the section for the first time. The float keys split into a probability group (eight keys using the 0-to-1 scale), a timer group (three keys using raw seconds), and two keys with their own semantics (one cap, one multiplier). Reading the type column in the key table as "float" tells you the JSON data type. Reading the prose for each key tells you what the float actually means.
Spawn and despawn
This group controls the four core lifecycle events for every item that enters the world: whether it appears at all, how long it stays if dropped by a player, how long it stays if naturally spawned, and how quickly the server replaces items that have been removed. These four keys are the supply-side rhythm of your server. Together they determine how many items are on the ground at any moment, how long a player has to reach an item they see at a distance, and how long the server waits before repopulating a looted area.
The four keys operate as a system. Changing one without understanding its relationship to the others produces configurations that look reasonable on paper but behave unexpectedly in practice. A server with Spawn_Chance at 1.0 (all spawn points active) and Respawn_Time at 3600 (one check per hour) will have a world that starts full of items and then slowly empties as players take loot, with replacements arriving only once per hour. A server with Spawn_Chance at 0.1 (few active spawn points) and Respawn_Time at 10 seconds will have a world that is always sparsely populated but never stays looted out because items return almost the moment they are taken. Both configurations use extreme values at opposite ends of the abundance spectrum, but they produce qualitatively different experiences because the ceiling and the replenishment rate are pulling in different directions.
Spawn_Chance
Spawn_Chance is a value between 0 and 1 that caps how many of the map's placed item spawn points can be active at once. It does not add or remove spawn points -- the map author defines those. It controls the ceiling. For every 100 item spawn points the map author placed, the server will never have more than 100 times Spawn_Chance items active simultaneously. The game's internal documentation describes the relationship as "if set to 0.2 and the level has 100 item spawns, max 20 items will spawn at a time." That sentence from the game's own field description is the clearest explanation of how this key works: it is a hard multiplier on the spawn point count.
Consider a supermarket on a map where the author placed 100 item spawn points across the shelves, back rooms, and parking lot. If Spawn_Chance is 0.2, the server will cap active items at roughly 20 across the entire supermarket. As players pick items up, those spawn points become eligible for a replacement after the respawn timer elapses, and the server repopulates them up to the 20-item cap. If Spawn_Chance is 0.5, the cap is roughly 50 items. If it is 1.0, all 100 spawn points can be active at the same time and every shelf in the supermarket can have an item on it.
The practical effect of a given Spawn_Chance value depends on spawn-point density. On a map where spawn points are packed tightly -- an urban map with floor-to-ceiling loot in every room -- even a low Spawn_Chance can still produce a dense-feeling item field because a small fraction of a large number of spawn points is still a significant number of items. On a sparse rural map where spawn points are few and far between, the same Spawn_Chance will feel barren because a small fraction of a small number of spawn points is a very small number of items. The cap is global, but the feeling it produces is local, and that feeling depends on the map author's spawn-point layout.
When multiple players are actively looting the same area, the cap behaves as a shared pool. If a town has 100 spawn points and Spawn_Chance is 0.2, the 20 active items are distributed across the town's spawn points. Two players looting opposite ends of the town are drawing from the same 20-item pool. The first player to reach the good spawn points gets the items; the second player may find bare shelves. A third player arriving later may find items have respawned, depending on the Respawn_Time. The cap is not per-player; it is per-server, and every player on the map competes for the same limited active item pool.
Setting Spawn_Chance to 0 disables item spawning entirely. The map still loads its spawn points, but none of them ever produce an item. The world is item-free. No amount of waiting, no value of Respawn_Time, will cause an item to appear.
Despawn_Dropped_Time
Despawn_Dropped_Time sets how many seconds an item persists on the ground after a player drops it from their inventory. This is a direct value in seconds: 300.0 means 300 seconds (five minutes), 600.0 means ten minutes, and so on.
A dropped item is distinct from a naturally spawned item. A naturally spawned item appeared at a spawn point through the normal loot system. A dropped item was carried by a player and then discarded -- whether intentionally (the player found a better weapon and dropped the old one), through death (the player's corpse released its inventory), or through a game mechanic (the player swapped items and the displaced item fell to the ground). The server tracks these two categories separately and applies a different despawn timer to each.
The practical purpose of Despawn_Dropped_Time is to control how long a dropped item remains findable by other players. A short timer means dropped items disappear quickly. Gear that a dead player dropped in a firefight is gone before anyone else can loot it. A long timer means dropped items persist. A battlefield after a multi-squad engagement remains strewn with weapons, magazines, clothing, and supplies that anyone passing through can scavenge.
Server owners tuning this value are making a decision about post-death loot availability. A short Despawn_Dropped_Time (60 to 120 seconds) means a player who re-spawns and runs back to their death point will find their gear gone. This sharpens the penalty for dying and reduces the amount of abandoned gear littering the ground, which can help server performance on maps with high player counts. A long Despawn_Dropped_Time (600 seconds or more) means a player has a realistic chance of recovering their dropped gear if they know where they died and can reach it quickly, and it also means other players can scavenge the aftermath of a major fight for an extended period.
The interaction with Despawn_Natural_Time matters. A server where Despawn_Dropped_Time is significantly longer than Despawn_Natural_Time will have a world where player-generated loot outlasts naturally spawned loot. A player who dies and drops a weapon leaves a marker on the landscape that persists long after the surrounding naturally spawned items have cycled. A server where the two timers are equal or where Despawn_Dropped_Time is shorter produces a world where dropped items and naturally spawned items clean up at roughly the same rate, which is simpler to reason about but removes the distinction between the two item sources.
There is no maximum value enforced by the game. A Despawn_Dropped_Time of 3600 would keep dropped items on the ground for an hour. The practical upper bound is server performance: more items on the ground at once means more objects for the server to track, more network data to send to clients, and more rendering work for every player whose view distance includes those items.
Despawn_Natural_Time
Despawn_Natural_Time sets how many seconds a naturally spawned item persists before the server removes it from the world. Like Despawn_Dropped_Time, this is a direct value in seconds.
A naturally spawned item is one that appeared at a spawn point through the loot system, as opposed to one that was dropped by a player. The game's internal documentation describes it as "an item nobody wants to pick up" -- the item equivalent of a player walking past a shelf and not picking up the can of beans sitting on it. The game considers such an item "unwanted" and will despawn it after Despawn_Natural_Time seconds to free the spawn point for a replacement and to keep the world from accumulating items nobody is taking.
The practical effect of Despawn_Natural_Time is to cycle unwanted loot out of the world. Maps with loot distributions that include a lot of low-tier items -- common clothing, low-quality melee weapons, basic food items -- will accumulate a lot of unwanted ground loot over time if players ignore those items. A short Despawn_Natural_Time (300 to 600 seconds) clears the clutter quickly, making room for new spawns that might roll higher-tier items from the same spawn table. A long Despawn_Natural_Time (1200 seconds or more) preserves the clutter, which can be desirable on a server where even common items have value because the overall item economy is scarce.
The interaction between the two despawn timers determines the visible texture of the ground-loot landscape. If Despawn_Dropped_Time is long and Despawn_Natural_Time is short, items dropped by players persist while naturally spawned items the players ignore disappear quickly. This produces a world where the aftermath of player activity is highly visible (dropped guns, discarded armour, death-loot caches) but the baseline loot clutter is thin. You walk through a town and see only the items players have left behind; everything else has already cycled. If both timers are long, the world accumulates items from both sources and the ground becomes a dense field of loot over time, which has both gameplay and performance implications.
A server owner who wants to minimise server load from item tracking should keep both despawn timers short. Fewer items on the ground means fewer objects for the server to manage. A server owner who wants a world that feels lived-in and persistent should keep both timers long. Items accumulate, the history of player activity is visible, and the world does not feel like it is being cleaned by an invisible janitor.
Respawn_Time
Respawn_Time sets the approximate interval in seconds at which the server checks whether it can place a new item at an eligible spawn point. When the active item count drops below the cap established by Spawn_Chance, the server schedules new spawns at roughly this interval.
The word "approximately" in the game's description of this key is deliberate and comes from the game's own internal field documentation. The server does not wait exactly Respawn_Time seconds between spawns. It schedules spawn attempts at roughly this interval, meaning that in practice, the actual time between a spawn point becoming eligible and a new item appearing is in the neighbourhood of Respawn_Time seconds, but not precisely that value down to the tick. A server owner testing respawn behaviour should expect some variance and not assume that a stopwatch will read exactly 60.0 seconds between an item being picked up and a replacement appearing.
The direction of the relationship is straightforward: lower values mean faster respawns, higher values mean slower respawns. A Respawn_Time of 10 means the server checks for eligible spawns roughly every 10 seconds. A Respawn_Time of 300 means it checks roughly every 5 minutes. A Respawn_Time of 3600 means it checks roughly once an hour.
The interplay between Spawn_Chance and Respawn_Time defines the replenishment profile of the server. A high Spawn_Chance with a short Respawn_Time means the world is always full and items return almost as fast as they are taken. This configuration produces a high-abundance, fast-cycling economy where players never face a real shortage of supplies. A low Spawn_Chance with a long Respawn_Time means there are never many items on the ground at once and the ones that get taken are not coming back any time soon. This configuration produces a scarcity economy where players compete over the few items that exist and high-traffic areas are perpetually picked clean.
The middle configurations are where most server design lives. A moderate Spawn_Chance (0.3 to 0.5) paired with a moderate Respawn_Time (60 to 180 seconds) produces a world where areas are reasonably well-stocked, become depleted after heavy looting, and recover gradually over a period of minutes. The cadence feels natural: loot is there when nobody has been through recently, and it is not there when the area has been hit hard. The recovery is slow enough that players can perceive it but fast enough that the world does not stay empty for long.
A special case worth noting: Respawn_Time affects only naturally spawned items. Items dropped by players do not respawn. When a dropped item despawns due to Despawn_Dropped_Time, its spawn point does not become eligible for a respawn -- the dropped item is simply gone. The spawn point that originally produced the item (if any) follows the respawn logic independently. This separation means that servers with long Despawn_Dropped_Time and short Respawn_Time can have a world where the natural item field cycles rapidly while the player-dropped item field accumulates and persists, creating two distinct layers of ground loot with different lifecycles.
Worked example: tuning the spawn-and-despawn group for a specific feel
Consider a server operator who wants a hardcore survival experience: items are genuinely scarce, every find matters, and areas stay looted out for a meaningful amount of time after being cleared. The operator might configure:
Spawn_Chance: 0.15 (only 15% of spawn points are active at any time)Respawn_Time: 600.0 (the server checks for respawn opportunities roughly every 10 minutes)Despawn_Dropped_Time: 300.0 (dropped items last 5 minutes -- enough time to run back to a death point on a small map, but not on a large one)Despawn_Natural_Time: 600.0 (unwanted items last 10 minutes before cycling out)
In this configuration, a player entering a town sees only a fraction of the items the town could theoretically hold. They pick up what they can. The remaining unwanted items disappear after 10 minutes. New items do not appear for roughly another 10 minutes after the old ones are gone. The result is a town that feels picked over. A player who arrives after another player has already looted the area finds empty shelves and must travel further to find unlooted territory.
Now consider the same operator switching to a more generous configuration for a casual weekend event:
Spawn_Chance: 0.8 (80% of spawn points active)Respawn_Time: 30.0 (respawn check roughly every 30 seconds)Despawn_Dropped_Time: 1200.0 (dropped items last 20 minutes)Despawn_Natural_Time: 1200.0 (unwanted items last 20 minutes)
The same town now starts with nearly every shelf stocked. Items return within roughly 30 seconds of being picked up. Dropped gear from heavily contested areas piles up and stays on the ground for 20 minutes, creating visible reminders of past engagements. The town never really feels looted out; players can revisit the same street multiple times in a session and find new items each time. The economy is abundant and fast-cycling. The decision between these two configurations is not a difficulty slider in the traditional sense -- no enemy does more damage, no stat changes -- but it entirely transforms how the game world feels to move through.
Quality system
This group controls what quality items spawn at and how that quality is determined. Quality in Unturned is a numerical value on each item that affects its performance: higher quality means more damage for weapons, more protection from armour, more effective food and medical items, and so on. The quality system determines whether players find pristine gear or worn-down equipment, and the difference between those two outcomes changes the value proposition of every scavenged item.
The two quality keys work as a pair following a two-step process. Step one: when an item spawns, the server rolls against Quality_Full_Chance. If the roll succeeds, the item spawns at maximum (100%) quality and the process ends. Step two: if the roll fails, the server generates a random quality value and multiplies it by Quality_Multiplier. The result is the item's actual quality. This two-step process means the quality curve on a server is not a simple random distribution; it is a distribution with a spike at the maximum-quality end (items that pass the full-chance roll) and a scaled random tail (items that did not). The shape of that distribution is what these two keys define.
Quality_Full_Chance
Quality_Full_Chance is a value between 0 and 1 that sets the probability of any spawned item appearing at maximum quality -- the best possible condition that particular item can be in. The roll happens once per item spawn, independently for each item. If the roll succeeds, the item appears at 100% quality. If it fails, the item's quality is determined by the random roll plus Quality_Multiplier.
A Quality_Full_Chance of 0 means no item ever spawns at maximum quality through the random quality roll. Every item that spawns goes through the scaled random path described by Quality_Multiplier. A value of 0.1 means roughly one in ten items spawns at full quality. A value of 0.5 means roughly half of all spawned items are in perfect condition. A value of 1.0 means every item spawns at full quality and the Quality_Multiplier key has no effect because the random-quality path is never entered.
The practical effect of Quality_Full_Chance is to control how often a player who picks up an item gets the best possible version of it. On a server where Quality_Full_Chance is very low, most items a player finds will be at some fraction of their potential -- a gun that deals some percentage of its max damage, a helmet that absorbs some percentage of its max protection, a medical kit that heals some percentage of its max amount. Players learn not to expect pristine loot and plan around using worn-down equipment. On a server where Quality_Full_Chance is very high, most items are at full power and the few that are not stand out as disappointing outliers. The key sets the expectation baseline for what "finding an item" means on your server.
A server owner tuning this key should consider how it interacts with the per-item-type full-quality overrides described later in this article. If Food_Spawns_At_Full_Quality is true, food items always spawn at 100% quality regardless of what Quality_Full_Chance says. The override takes precedence. The same applies for water, clothing, weapons, and default items. The Quality_Full_Chance key is the general rule; the per-type overrides are exceptions to that rule. If every per-type override is set to true, Quality_Full_Chance is effectively disabled because no item type reaches the step where it would be consulted.
Quality_Multiplier
Quality_Multiplier is a value, typically but not necessarily between 0 and 1, that scales the random quality of items that did not roll maximum quality through Quality_Full_Chance. When an item spawns without the full-quality roll succeeding, the game generates a random quality value and then multiplies it by this factor. A Quality_Multiplier of 1.0 means the random quality is left unchanged -- an item that would have rolled 80% quality spawns at 80%. A value of 0.5 halves the random quality -- an item that would have rolled 80% quality instead spawns at 40%. A value of 0.2 means items that miss the full-quality roll spawn at one-fifth of what they would have been, which makes non-perfect items dramatically worse.
The relationship between the random roll and the multiplier is important to understand. The multiplier does not change the range of possible outcomes; it shifts the entire range downward by a factor. If the server's random quality generator produces values in a range from, say, 0.1 to 0.9, a Quality_Multiplier of 0.5 transforms that range into 0.05 to 0.45. Items that miss the full-chance roll are now between 5% and 45% quality. No item in the random path ever reaches even 50% quality. A Quality_Multiplier of 0.2 transforms the same range into 0.02 to 0.18. Items in the random path are uniformly poor.
The two quality keys work as a pair. Quality_Full_Chance determines how many items skip the random-quality step entirely by landing on maximum quality. Quality_Multiplier determines how good the remaining items are. You can tune them independently to produce different profiles, and the profiles feel different in ways that matter to the player experience.
A configuration with high Quality_Full_Chance and a low Quality_Multiplier produces a polarised item field: most items are perfect (because the full-chance roll succeeds for most spawns), but the ones that are not perfect are terrible (because the multiplier drags their random quality down). A player finds a pristine military rifle on one shelf and a barely-functional pistol on the next. The average quality across all items is still high because most items are perfect, but the gap between the good items and the bad items is extreme. This configuration can be satisfying (most finds are great) or frustrating (when a find is bad, it is really bad) depending on how players react to variance.
A configuration with low Quality_Full_Chance and a high Quality_Multiplier (close to 1.0) produces a more uniform item field where almost nothing is perfect but most things are decent. Items hover in the 70% to 90% quality range. No single find feels amazing -- finding a pristine weapon is a rare event -- but no single find feels like garbage either. The average quality across all items is moderate and the variance is low. This configuration rewards players who upgrade incrementally: every new find is potentially a small improvement over the current gear, and the improvement feels earned because it was not guaranteed to be perfect.
A configuration with low Quality_Full_Chance and a low Quality_Multiplier produces a uniformly grim item field where everything is worn down. Almost nothing is perfect, and what is not perfect is bad. Players are constantly making do with damaged gear. This configuration is appropriate for servers where the intended experience is one of desperation and scarcity -- where the question is not "is this item good?" but "is this item good enough to be worth carrying?"
A configuration with a Quality_Multiplier greater than 1.0 is syntactically possible but unusual. A value of 1.5 would mean items that miss the full-quality roll get a boost to their random quality, potentially exceeding the base random roll. In most configurations, keeping the multiplier at or below 1.0 is the intended behaviour, and values above 1.0 may produce quality values that exceed the game's expected quality range. The game's internal description of this key does not state an upper bound, so values above 1.0 are not explicitly forbidden, but they are not a standard configuration.
Ammo fill rates
This group controls how much ammunition guns, magazines, and non-magazine ammunition containers spawn with. It uses the same paired-key pattern as the quality system: a full-chance key (probability of spawning with a full load) and a multiplier key (scaling factor for items that do not get the full load). The six keys in this group follow an identical mechanical structure applied to three different item categories.
The ammunition fill system follows the same two-step process as the quality system. Step one: when an item that carries ammunition spawns, the server rolls against the relevant full-chance key. If the roll succeeds, the item spawns with its maximum ammunition capacity. Step two: if the roll fails, the server generates a random ammunition amount and multiplies it by the relevant multiplier. The three item categories -- guns, magazines, and crates (non-magazine ammunition containers) -- each have their own pair of keys, allowing independent tuning of ammunition availability across the three categories.
The six keys are mechanically identical to one another; they differ only in which item category they apply to. Understanding one pair is understanding all three.
Gun ammunition
Gun_Bullets_Full_Chance sets the probability, from 0 to 1, that a firearm spawns with a full magazine already loaded. A value of 0.1 means roughly one in ten guns is found fully loaded. A value of 0.5 means roughly half of all firearms are ready to fire the moment they are picked up. A value of 0 means every firearm spawns with a partial load determined by the multiplier.
Gun_Bullets_Multiplier scales the random ammunition amount for guns that did not roll the full-chance success. A Gun_Bullets_Multiplier of 0.5 means a gun that would have rolled 20 rounds in the magazine instead spawns with 10. A value of 0.3 means it spawns with roughly a third of what the random roll would have produced.
The interaction between these two keys creates the ammunition availability for firearms on a server. A high full-chance with a high multiplier means almost every firearm is found loaded and the few that are not are still well-stocked. A low full-chance with a low multiplier means almost every firearm is found with only a few rounds in the chamber and must be paired with a separately found magazine or ammunition crate to be useful. The latter configuration changes the value proposition of finding a gun: the gun itself is not the complete package; it is a chassis that needs ammunition to function. Players must scavenge for both components, which adds a layer of logistical difficulty to the loot loop.
The distinction between a gun's loaded magazine and a separately spawned magazine is important. A gun that spawns with a partially loaded magazine due to a failed full-chance roll still has that magazine inside it. The player picks up the gun and the magazine is part of the pickup. A separately spawned magazine item on a shelf follows the magazine ammunition keys (Magazine_Bullets_Full_Chance and Magazine_Bullets_Multiplier), not the gun ammunition keys. The same physical object -- a magazine -- can arrive in the player's inventory through two different paths, each governed by a different pair of keys. A server owner who wants consistent ammunition behaviour regardless of the delivery path should set all six ammunition keys to the same values. A server owner who wants guns found pre-loaded to behave differently from magazines found on shelves should tune the two pairs independently.
Magazine ammunition
Magazine_Bullets_Full_Chance and Magazine_Bullets_Multiplier apply the same logic to magazine items that spawn as separate ground loot, as opposed to magazines already loaded into a firearm. A magazine found on a shelf follows this pair of keys. A magazine already loaded into a gun that was found follows the gun ammunition pair instead. The magazine is the same object type in both cases; what differs is the context in which it entered the world.
The distinction matters for servers that tune the two pairs differently. A server operator might set Gun_Bullets_Full_Chance to 0.05 (guns are almost never loaded when found) but set Magazine_Bullets_Full_Chance to 0.4 (standalone magazines are often full). This configuration means a player who finds a gun must also find a magazine, but the magazine they find is likely to be fully loaded. The gun is an empty vessel; the magazine is the payload. The separation of weapon and ammunition into two independent scavenging objectives adds depth to the loot loop without making either objective impossible.
The same server operator might later decide to reduce Magazine_Bullets_Full_Chance to 0.1 to further increase scarcity. Now standalone magazines are also mostly found empty or nearly empty. The player finds a gun with no ammo and a magazine with no ammo, and must also find ammunition crates (governed by the crate keys) to manually reload the magazine before loading it into the gun. The scavenging chain stretches from one step (find a gun) to three steps (find a gun, find a magazine, find ammunition to fill the magazine). The choice of whether to stretch that chain is one of the most impactful decisions in the entire Items section, and it is made entirely through the relative values of the three ammunition key pairs.
Non-magazine ammunition
Crate_Bullets_Full_Chance and Crate_Bullets_Multiplier apply the same logic to ammunition items that are not magazines -- ammunition boxes, loose rounds, and any other item that holds ammunition in a container that is not a detachable magazine. The game's internal documentation cites ammunition boxes as the canonical example, using the term "non-magazines" to describe the category.
The separation of crate ammunition from magazine ammunition exists because the two categories serve different gameplay roles. A magazine is a reusable container that fits a specific weapon calibre and can be reloaded from ammunition crates. An ammunition crate is a consumable that refills magazines of a matching calibre and is then consumed. A full magazine is a persistent asset; a full ammunition crate is a one-time resource.
A server operator who tunes the crate keys differently from the magazine keys is making a statement about which part of the ammunition economy is the bottleneck. If Magazine_Bullets_Full_Chance is low (magazines are rarely full) but Crate_Bullets_Full_Chance is high (ammunition crates are usually full), the bottleneck is magazines. Players find plenty of ammunition but need the right magazine to use it. If Magazine_Bullets_Full_Chance is high but Crate_Bullets_Full_Chance is low, the bottleneck is ammunition itself. Players find magazines but need to find ammunition crates to fill them. If both are low, the bottleneck is both, and players spend a significant portion of their gameplay managing ammunition logistics. If both are high, ammunition is rarely a concern and players can focus on other aspects of survival.
The crate keys also serve as the safety valve for the entire ammunition system. Even on a server where guns and magazines are almost never found loaded, a player who finds a full ammunition crate can load their magazines and get their guns operational. The crate keys set the ultimate ceiling on how much ammunition a persistent player can accumulate regardless of how stingy the gun and magazine keys are. A server operator who wants ammunition to always be scarce should keep all six keys low. A server operator who wants ammunition to be scarce to find pre-loaded but available to those who put in the work should keep the gun and magazine keys low and the crate keys moderate.
Per-item-type durability overrides
The remaining ten keys form a system that controls whether items degrade through use and whether specific item categories are exempt from quality reduction. These keys replace and extend the simpler durability model that Has_Durability originally provided. Understanding the relationship between Has_Durability and the eight type-specific keys is essential to configuring this part of the section correctly.
Has_Durability: the master switch
Has_Durability is the original durability control for the Items section. The game's internal documentation describes it as the "original option for disabling item quality." When set to false, two things happen. Every item spawns at 100% quality regardless of the Quality_Full_Chance and Quality_Multiplier settings -- those keys are effectively overridden. And the quality of every item is locked at 100% -- it does not decrease through use, damage, or any other gameplay event. Weapons never wear down, clothing never loses protection, food and water items are always at peak effectiveness.
When Has_Durability is set to true, the quality and durability keys for individual item types become active. Items can spawn at less than full quality (as governed by Quality_Full_Chance and Quality_Multiplier), and their quality can decrease through gameplay.
The backwards-compatibility behaviour of Has_Durability is critical to understand. The game's internal documentation states explicitly: "For backwards compatibility, the newer per-item-type durability options are ignored if this is off." If Has_Durability is false, the game ignores the newer per-item-type durability keys entirely. Setting Has_Durability to false and then setting Weapons_Have_Durability to true has no effect -- the per-type key is overridden by the master switch. A server owner who wants to disable durability for most item types but enable it for weapons cannot use Has_Durability: false as a shortcut. They must set Has_Durability to true and then individually disable durability for every type except weapons, using the per-type keys described in the following sections.
This is the single most important architectural fact about the Items section. The master switch is not a convenience toggle that can be partially overridden. It is a binary gate. If it is closed, nothing downstream of it matters. If it is open, every downstream key is active and must be deliberately configured to match the server owner's intent. A server owner who does not understand this relationship will set Has_Durability to false expecting to keep per-item-type control and will be surprised when none of their per-type keys have any effect.
Full-quality spawn overrides by item type
These five keys control whether items of specific categories ignore the quality system and always spawn at full quality. Each one is a boolean. When set to true, items of that category always spawn at 100% quality, bypassing Quality_Full_Chance and Quality_Multiplier for that category only. When set to false or absent, items of that category follow the normal quality logic.
The game's internal documentation describes each of these keys as a "replacement for Has_Durability" for its specific item type. The original design had only Has_Durability, which was a blunt instrument: either all items had quality variance and degradation, or none did. The per-type overrides add granularity. A server owner can now say: "quality variance applies to everything, but food and water should always be at full quality because hungry players with bad food is not the kind of difficulty I want." Or: "weapons should always be pristine because weapon condition variance feels unfair in PvP, but clothing can degrade because armour management is part of the survival loop."
Food_Spawns_At_Full_Quality applies the override to food items. When true, every food item a player finds is at maximum quality. A can of beans found in a farmhouse is just as effective as one found in a military mess hall. A candy bar scavenged from a gas station restores the full amount of food it is capable of restoring. This override is useful for servers where food quality variance is not a meaningful gameplay lever -- where the challenge is finding food at all, not finding food of sufficient quality to be worth eating. On a hardcore server where food is scarce to begin with, adding quality variance on top of scarcity can push players past the point of survivability without adding interesting decisions.
Water_Spawns_At_Full_Quality applies the same logic to water items. Bottled water, canteens, and any other item categorised as water always spawn at 100% quality when this key is true. Like the food override, this simplifies the hydration economy to a binary: you have water or you do not. The quality of the water you found is not a factor. Servers that pair this with the food override are essentially removing quality variance from the survival-resource layer while keeping it for equipment.
Clothing_Spawns_At_Full_Quality applies the override to clothing items -- shirts, pants, hats, vests, backpacks, and any other wearable item. When true, every piece of clothing a player finds provides its full armour value and has its maximum inventory capacity (where capacity is a property of the item). A server owner who sets this to true is deciding that clothing protection should be a function of which item you found, not what condition it is in. A military vest always provides full protection; the variance between a good vest and a bad vest is eliminated. The only differences between clothing items are their base stats.
Weapons_Spawn_At_Full_Quality applies the override to weapon items -- both melee weapons and firearms. When true, every weapon a player finds is at 100% quality from the moment it spawns. It deals its maximum possible damage. Its durability bar starts full. The server owner who sets this to true is removing quality variance from the weapon-finding experience entirely. Every weapon find is a best-case find in terms of condition. The differences between weapons are only their base stats, not their current condition. This is an important consideration for PvP-focused servers where weapon-condition variance can be perceived as unfair: two players who find the same weapon should be on equal footing, and one should not lose a fight because their version of the gun was found at 60% quality.
Default_Spawns_At_Full_Quality is the fallback override for any item that does not fit into the food, water, clothing, or weapons categories. The game's internal documentation describes it as the "fallback used when spawning an item that doesn't fit into one of the other quality/durability settings." It catches every item type not covered by the four specific overrides. When set to true, ammunition boxes, medical supplies, crafting materials, and any other miscellaneous item spawns at full quality. When false, these items follow the normal quality logic. This key provides a convenient way to set a baseline for "everything else" without needing to list every non-standard item type individually. A server owner who is happy with quality variance for the four main categories but wants miscellaneous items to always be pristine can set the four specific overrides to false and Default_Spawns_At_Full_Quality to true.
The five override keys are independent. A server owner can set Weapons_Spawn_At_Full_Quality to true while leaving all other overrides at false, producing a world where weapons are always pristine but food, water, clothing, and miscellaneous items follow the normal quality curve. Or they can set all five to true and effectively disable the quality system for the entire Item section through the override mechanism rather than through the Has_Durability master switch. The difference between those two approaches -- all five overrides set to true versus Has_Durability set to false -- is that the override approach leaves durability degradation active. Items still wear down through use; they simply start from a full bar. The Has_Durability: false approach disables both quality variance and durability degradation entirely. The five overrides control the starting condition; Has_Durability controls the ongoing condition. A server owner who wants items to start perfect but degrade with use should use the override approach. A server owner who wants items to always be perfect, both at spawn and through use, should use Has_Durability: false.
Durability degradation by item type
These two keys control whether specific item categories degrade through use. Each is a boolean. When set to false, items of that category do not lose quality when damaged, used, or worn down. When set to true, they do.
Clothing_Has_Durability controls whether clothing items degrade. When set to false, a shirt worn through a firefight does not lose armour value. A backpack does not lose capacity slots. A helmet does not lose protection after absorbing a headshot. The clothing is effectively indestructible in terms of its protective quality, although it can still be visually damaged or destroyed by game events that remove items entirely. When set to true, clothing quality decreases as it absorbs damage, and players must repair or replace damaged gear.
The game's internal documentation describes this key as a "clothing-specific replacement for Has_Durability." Under the old model, Has_Durability controlled durability for all item types uniformly. This key and the one below allow independent control: a server owner can enable durability degradation for clothing while disabling it for weapons, or vice versa.
Weapons_Have_Durability controls whether melee weapons and firearms degrade through use. The game's internal documentation describes it as the "melee and gun replacement for Has_Durability." When set to false, a gun does not lose quality from being fired. A melee weapon does not lose quality from striking zombies, barricades, or players. The weapon is effectively indestructible in terms of its damage output, although it can still be lost, dropped, or destroyed by game events that remove items from the inventory entirely. When set to true, weapon quality decreases with use, reducing damage output over time until the weapon is repaired or replaced.
The two durability keys interact with the full-quality spawn overrides but do not depend on them. A server can have Weapons_Spawn_At_Full_Quality set to true (every weapon spawns at 100%) and Weapons_Have_Durability set to true (weapons degrade through use). In this configuration, a player who finds a weapon gets it in pristine condition, but that condition will decrease as they use it. The weapon is a depreciating asset. The player's attachment to a particular weapon is complicated by the knowledge that it is getting worse with every magazine fired.
Alternatively, a server can have Weapons_Spawn_At_Full_Quality set to false (weapons follow the normal quality curve) and Weapons_Have_Durability set to false (weapons never degrade). In this configuration, the condition of a weapon at spawn is permanent. A weapon found at 67% quality will always be a 67% weapon. It never gets worse, but it never gets better either. The player's relationship to their found weapon changes fundamentally: it is not a depreciating asset that must be maintained, but a fixed-grade tool they either accept or discard. Finding a 67% weapon is not a temporary solution until it degrades further; it is a permanent downgrade from finding a 90% weapon, and the player's only path to improvement is to find a better one.
The interplay of all these keys across the eight type-specific overrides and the master Has_Durability switch produces a combinatorial space of possible durability configurations. The table below summarises the decision tree a server operator faces when tuning this part of the section:
| Decision | Option A | Option B |
|---|---|---|
| Master switch | Has_Durability: false -- no quality variance, no degradation, per-type keys ignored | Has_Durability: true -- quality and durability active, per-type keys respected |
| Food spawn quality | true -- food always 100% | false -- food follows Quality_Full_Chance / Quality_Multiplier |
| Water spawn quality | true -- water always 100% | false -- water follows quality curve |
| Clothing spawn quality | true -- clothing always 100% | false -- clothing follows quality curve |
| Weapon spawn quality | true -- weapons always 100% | false -- weapons follow quality curve |
| Default spawn quality | true -- everything else always 100% | false -- misc items follow quality curve |
| Clothing degradation | true -- clothing wears down | false -- clothing quality is permanent |
| Weapon degradation | true -- weapons wear down with use | false -- weapon quality is permanent |
Each row is an independent choice when Has_Durability is true. When Has_Durability is false, the last seven rows are ignored and all items are perpetually at 100% quality.
The interaction layers: how the groups affect each other
Understanding each group in isolation is not enough. The groups interact in ways that change the effective meaning of individual keys. This section traces the most important interactions so that a server owner tuning one group can anticipate what will happen when their changes meet the values already set in another group.
Despawn timers versus spawn chance
When Despawn_Natural_Time is short and Spawn_Chance is high, the server is actively replacing unwanted items with fresh spawns. The world is cycling through items rapidly. Every item that sits untouched for longer than the natural despawn timer is removed and replaced, potentially with a different item from the same spawn table. This accelerates the rate at which the spawn table's item pool is sampled, because each despawn-and-respawn cycle is another roll on the table. An area with 100 spawn points, a Spawn_Chance of 0.8 (80 active items), and a Despawn_Natural_Time of 300 seconds will cycle through its entire active item field multiple times per hour, giving the spawn table many opportunities to produce rare items.
When Despawn_Natural_Time is long and Spawn_Chance is low, the opposite happens. The few items that are active stay in place for a long time because they are not being picked up and are not despawning naturally. The spawn table gets few opportunities to produce new rolls because the existing items are not being cleared. An area with 100 spawn points, a Spawn_Chance of 0.2 (20 active items), and a Despawn_Natural_Time of 1800 seconds (30 minutes) will hold its 20 items for half an hour before cycling them, and if any of those 20 items are low-tier, those spawn points are locked into low-tier items for the full 30-minute duration. A player who clears the area by picking up the unwanted items forces a faster cycle, but a player who simply walks through and ignores everything leaves the spawn points locked.
Quality versus despawn
The quality of an unwanted item determines how long it is visible on the ground before the natural despawn timer removes it, but that duration is the same regardless of quality. A 5% quality item and a 95% quality item both persist for Despawn_Natural_Time seconds if nobody picks them up. This means that on servers with very low Quality_Full_Chance and a very low Quality_Multiplier, the vast majority of items on the ground at any moment are poor-quality items that nobody wants. These items are taking up active spawn slots that could otherwise be producing new items, and they are not being removed until the natural despawn timer fires. The poor-quality items are clogging the spawn pipeline.
The fix for this is not in the quality keys themselves but in the despawn timer. A shorter Despawn_Natural_Time clears unwanted items faster, which frees spawn slots for new rolls that might produce better-quality items -- or might produce more unwanted items. The despawn timer is the only lever that controls how fast the spawn pipeline self-cleans. On a server with very low quality, a short natural despawn timer is essential to prevent the world from filling up with items nobody will ever pick up. On a server with high quality, the despawn timer matters less for item quality reasons because most items are being picked up before they despawn.
Ammo fill versus weapon quality
A gun found at 100% quality with zero ammunition is a different find from a gun found at 60% quality with a full magazine. The quality keys and the ammo keys interact to determine the effective value of a weapon find. A server operator tuning both groups should consider the combined profile.
A server with Quality_Full_Chance at 0.5, Gun_Bullets_Full_Chance at 0.05, and Gun_Bullets_Multiplier at 0.2 produces a world where roughly half of all guns are in perfect condition but almost none of them are loaded, and the ones that are not loaded have only a few rounds. Finding a perfect-condition gun is common; finding a perfect-condition gun that is ready to fire is rare. The player often has the chassis but not the ammunition, and must supplement their find with separately scavenged magazines or crates.
A server with Quality_Full_Chance at 0.1, Gun_Bullets_Full_Chance at 0.8, and Gun_Bullets_Multiplier at 0.8 produces the opposite: most guns are worn down, but most of them are found with a full or nearly full magazine. The player's find is immediately usable but not in peak condition. They can fire it right away, but they are firing a worn weapon. The decision of whether to use it or keep looking for a better one is immediate.
A server with both quality and ammo keys set low produces a grim weapon economy: most guns are worn and empty, and the player must find both a better gun and ammunition for it. A server with both set high produces a generous weapon economy: most guns are pristine and loaded, and the player can engage immediately with whatever they find. The quadrants are not equally desirable; the right quadrant depends on the server's intended difficulty.
Durability degradation versus spawn quality
When Clothing_Has_Durability or Weapons_Have_Durability is true, items degrade through use. The rate at which they degrade is not controlled by any key in the Items section; it is determined by the item's own asset data and by the damage mechanics of the game. The spawn quality keys determine where the item starts on that degradation curve.
On a server where Clothing_Spawns_At_Full_Quality is true and Clothing_Has_Durability is true, every piece of clothing starts at 100% and then slides downward. The player's relationship to their clothing is maintenance: keeping the quality bar high through repairs or replacements. On a server where Clothing_Spawns_At_Full_Quality is false and Clothing_Has_Durability is true, clothing starts at whatever quality the random system produced and then slides further downward. Some clothing is already in bad shape when found. The player's relationship to their clothing is triage: deciding whether each found item is good enough to wear despite its current condition and its inevitable deterioration.
On a server where Clothing_Has_Durability is false, spawn quality is permanent. A piece of clothing found at 67% will always be 67%. The spawn quality keys determine the entire quality story for clothing, because there is no degradation to account for. The player's relationship to their clothing is static: each item is a fixed-grade upgrade or downgrade, and once they have the best item they can find, they are done.
Canned Beans
The Items section of Config.json does not contain a key that references canned beans directly or indirectly. No key in this section governs the spawn rate, despawn timer, quality, or durability of the canned beans item specifically. The canned beans are governed by the same general keys as every other item that enters the world through the spawn system.
If you want to tune the behaviour of canned beans on your server, you tune the twenty keys in this section and the behaviour of canned beans changes along with every other item. There is no per-item granularity in the Items section. The spawn cap you set with Spawn_Chance applies to canned beans the same way it applies to military rifles. The despawn timer you set with Despawn_Natural_Time removes unwanted beans from the shelves at the same rate it removes unwanted medical supplies. The quality you set with Quality_Full_Chance determines whether the beans a player finds are at peak nutritional effectiveness or a diminished fraction of it.
This absence of per-item control is not a flaw. The Items section is a system-wide tuning surface. The per-item tuning surface lives in the spawn tables, where a map author decides whether canned beans appear at all, how often they appear relative to other items, and at which spawn points on the map they are eligible to appear. The Items section sets the environmental conditions that all items operate under; the spawn tables decide which items are in the environment to begin with. To make canned beans more common on your server, you edit the spawn tables. To make every item, including canned beans, persist longer on the ground, you edit the Items section.
A server operator who wants canned beans to be a reliable food source should look upstream to the spawn tables and ensure beans appear in the appropriate spawn entries. A server operator who wants canned beans to always be at full quality when found can use the Food_Spawns_At_Full_Quality override described earlier in this article -- but that override applies to all food items, not just beans. There is no mechanism in the Items section to single out canned beans for special treatment. The beans travel with the herd.
For the documented lore of the canned beans as an artefact of the Unturned setting -- their geometry, their history, their cultural significance among survivors -- see the Canned Beans Lore article. That article treats the beans as a real object within the game's world; this article treats them as one item among many governed by a shared rule set.
Practical use: putting the section together
The Items section is small enough to tune holistically. Twenty keys is not a large surface, and the interactions between them are the thing that produces the feel of the server, not any individual key in isolation. The most common mistake a new server operator makes when editing this section is to change one key, test it in isolation, and call it done. Changing Spawn_Chance without adjusting Respawn_Time changes the item ceiling but leaves the replenishment rate at its baseline. Changing Respawn_Time without touching the despawn timers creates a world where items return fast but old items have not left yet, which inflates the active item count beyond what either key suggests. Changing the quality keys without considering the durability keys produces an economy where items start in one condition and then slide to a different one over time, and the gap between those two conditions is the space where player satisfaction or frustration lives.
Abundance vs. scarcity
The spawn-and-despawn group -- Spawn_Chance, Despawn_Dropped_Time, Despawn_Natural_Time, and Respawn_Time -- defines the abundance-versus-scarcity axis. A high-abundance configuration uses Spawn_Chance at or near 1.0, Respawn_Time at a short interval (10 to 30 seconds), and both despawn timers long enough that items are not removed before players have a chance to reach them. A high-scarcity configuration uses Spawn_Chance at 0.1 to 0.3, Respawn_Time at a long interval (300 to 600 seconds), and short despawn timers that clear unwanted items quickly to make room for the few new spawns the cap allows.
The choice between these two poles is not just a difficulty decision. It is a genre decision. A high-abundance configuration pushes the server toward a more casual, exploration-focused experience where loot is a reward for moving through the world. A high-scarcity configuration pushes the server toward a more competitive, survival-focused experience where loot is a contested resource. A server whose owner wants players to be able to gear up quickly and get into combat will lean toward abundance. A server whose owner wants the scavenging loop itself to be the primary challenge will lean toward scarcity.
Perfection vs. degradation
The quality and durability groups define the perfection-versus-degradation axis. A high-perfection configuration uses Quality_Full_Chance at 0.5 or above, Quality_Multiplier at or near 1.0, and the full-quality spawn overrides set to true for the most important categories. Items are consistently good when found. A high-degradation configuration uses Quality_Full_Chance very low (0.05 to 0.1), Quality_Multiplier below 0.5, the full-quality overrides set to false, and both Clothing_Has_Durability and Weapons_Have_Durability set to true. Items are consistently worn when found and they wear down further through use.
A server that pairs high abundance with high perfection is a generous server. Items are everywhere and they are good. Players have no friction in their equipment loop. A server that pairs high scarcity with high degradation is an unforgiving server. Items are rare and what few exist are in poor condition and deteriorate. Players spend a large portion of their time managing equipment condition. Most servers live between these quadrants, and the right quadrant depends entirely on the intended player experience.
The ammunition dimension
The ammunition fill keys add a third dimension. A server with high Gun_Bullets_Full_Chance and high Magazine_Bullets_Full_Chance means firearms are usually ready to fire the moment they are picked up. The player finds a gun, loads it, and fights -- no extra step. A server with low values for both means the gun-finding step and the ammunition-finding step are separate. The player finds a gun and then must find ammunition for it, which might take minutes or hours depending on the rest of the config. This single design choice splits the scavenging experience into two distinct phases and doubles the number of successful finds a player needs before they are combat-ready.
Common configuration profiles
The four profiles below illustrate how the twenty keys can be combined to produce distinct server identities. Each profile is a complete Items section. The values are illustrative and demonstrate the relationships between keys; they are not prescriptions. Every server community is different, and the specific numbers that work for one community may not work for another.
Profile 1: Casual abundance
A server where loot is plentiful, items are in good condition, and the focus is on exploration and combat rather than survival pressure.
json
"Items": {
"Spawn_Chance": 0.85,
"Despawn_Dropped_Time": 900.0,
"Despawn_Natural_Time": 900.0,
"Respawn_Time": 30.0,
"Quality_Full_Chance": 0.4,
"Quality_Multiplier": 0.8,
"Gun_Bullets_Full_Chance": 0.5,
"Gun_Bullets_Multiplier": 0.7,
"Magazine_Bullets_Full_Chance": 0.5,
"Magazine_Bullets_Multiplier": 0.7,
"Crate_Bullets_Full_Chance": 0.5,
"Crate_Bullets_Multiplier": 0.7,
"Has_Durability": true,
"Food_Spawns_At_Full_Quality": true,
"Water_Spawns_At_Full_Quality": true,
"Clothing_Spawns_At_Full_Quality": false,
"Weapons_Spawn_At_Full_Quality": false,
"Default_Spawns_At_Full_Quality": false,
"Clothing_Has_Durability": true,
"Weapons_Have_Durability": true
}This profile produces a world where 85% of spawn points are active, items return within roughly 30 seconds, and unwanted items stay on the ground for 15 minutes. Quality is generous (40% full-chance with a 0.8 multiplier for the rest) but not universal. Ammunition is plentiful. Food and water are always at full quality, but everything else follows the quality curve and degrades through use. This is a server where players can gear up quickly, but their gear requires maintenance.
Profile 2: Hardcore survival
A server where resources are genuinely scarce, every find matters, and equipment management is a core survival mechanic.
json
"Items": {
"Spawn_Chance": 0.2,
"Despawn_Dropped_Time": 180.0,
"Despawn_Natural_Time": 600.0,
"Respawn_Time": 480.0,
"Quality_Full_Chance": 0.05,
"Quality_Multiplier": 0.35,
"Gun_Bullets_Full_Chance": 0.05,
"Gun_Bullets_Multiplier": 0.25,
"Magazine_Bullets_Full_Chance": 0.05,
"Magazine_Bullets_Multiplier": 0.25,
"Crate_Bullets_Full_Chance": 0.1,
"Crate_Bullets_Multiplier": 0.3,
"Has_Durability": true,
"Food_Spawns_At_Full_Quality": false,
"Water_Spawns_At_Full_Quality": false,
"Clothing_Spawns_At_Full_Quality": false,
"Weapons_Spawn_At_Full_Quality": false,
"Default_Spawns_At_Full_Quality": false,
"Clothing_Has_Durability": true,
"Weapons_Have_Durability": true
}This profile produces a world where only 20% of spawn points are active, respawns happen roughly every 8 minutes, and dropped items disappear in 3 minutes -- fast enough that gear recovery after death is not realistic. Quality is harsh: only 5% full-chance, and non-perfect items are scaled to roughly a third of their random roll. Ammunition is scarce across all three categories. No item type spawns at full quality. Durability degradation is active for both clothing and weapons. This is a server where players are perpetually under-equipped and every find is a hard-won improvement.
Profile 3: PvP-focused fair start
A server where the focus is on player-versus-player combat and the server owner wants everyone on an equal footing regardless of their luck with loot quality.
json
"Items": {
"Spawn_Chance": 0.5,
"Despawn_Dropped_Time": 300.0,
"Despawn_Natural_Time": 600.0,
"Respawn_Time": 90.0,
"Quality_Full_Chance": 0.1,
"Quality_Multiplier": 0.5,
"Gun_Bullets_Full_Chance": 0.5,
"Gun_Bullets_Multiplier": 0.5,
"Magazine_Bullets_Full_Chance": 0.5,
"Magazine_Bullets_Multiplier": 0.5,
"Crate_Bullets_Full_Chance": 0.5,
"Crate_Bullets_Multiplier": 0.5,
"Has_Durability": true,
"Food_Spawns_At_Full_Quality": true,
"Water_Spawns_At_Full_Quality": true,
"Clothing_Spawns_At_Full_Quality": false,
"Weapons_Spawn_At_Full_Quality": true,
"Default_Spawns_At_Full_Quality": false,
"Clothing_Has_Durability": true,
"Weapons_Have_Durability": false
}This profile produces a world with moderate item density. Weapons always spawn at full quality and never degrade, meaning every weapon find is a fair, permanent asset. Clothing follows the quality curve and degrades, keeping armour management as a meaningful differentiator. Ammunition is moderately available across all three categories. Food and water are always full quality, removing survival-resource RNG from the equation. The profile prioritises fairness in combat (weapons are consistent) while retaining some equipment-management depth (clothing quality and degradation).
Profile 4: Degradation-only challenge
A server where items are abundant and start in good condition, but they degrade rapidly and must be constantly maintained or replaced. The challenge is not finding gear; the challenge is keeping gear in working order.
json
"Items": {
"Spawn_Chance": 0.7,
"Despawn_Dropped_Time": 900.0,
"Despawn_Natural_Time": 600.0,
"Respawn_Time": 45.0,
"Quality_Full_Chance": 0.3,
"Quality_Multiplier": 0.7,
"Gun_Bullets_Full_Chance": 0.6,
"Gun_Bullets_Multiplier": 0.7,
"Magazine_Bullets_Full_Chance": 0.6,
"Magazine_Bullets_Multiplier": 0.7,
"Crate_Bullets_Full_Chance": 0.6,
"Crate_Bullets_Multiplier": 0.7,
"Has_Durability": true,
"Food_Spawns_At_Full_Quality": false,
"Water_Spawns_At_Full_Quality": false,
"Clothing_Spawns_At_Full_Quality": false,
"Weapons_Spawn_At_Full_Quality": false,
"Default_Spawns_At_Full_Quality": false,
"Clothing_Has_Durability": true,
"Weapons_Have_Durability": true
}This profile produces a world with generous item density and decent starting quality, but everything degrades. Items are plentiful and ammunition is common, but no item is safe from wear. A player who finds a great weapon at 90% quality knows it will not stay at 90%. They must plan for its decline by stockpiling repair materials or by keeping an eye out for replacements. The world gives freely, but what it gives does not last.
Testing your configuration
The only reliable way to test an Items section configuration is to run the server with it active, join as a player, and observe the world. Walk through several loot-dense areas at different times after a server restart. Count the items you see. Note the quality of those items. Pick items up and watch when they respawn. Drop an item and time how long it persists. Die with items in your inventory and check whether those items are on the ground when you return. The numbers in the config file are abstractions. The feel of the world is the only metric that matters.
A testing routine for a new Items section configuration should cover at minimum:
- A walk through a high-density loot area within the first five minutes of the server being up, to observe the initial spawn wave. Are the shelves too full, just right, or too empty?
- A return to the same area after the value of your
Respawn_Time(plus some margin for the approximate interval), to observe the respawn behaviour. Are items coming back at the expected pace? - A timing of a dropped item's despawn, to confirm
Despawn_Dropped_Timeis working as intended. Does a dropped item vanish at roughly the number of seconds you set? - A check of item quality across at least twenty different items of different types, to confirm the quality curve matches your intended profile. Are too many items perfect? Are too many items nearly worthless?
- An equipment-degradation test: fire a weapon repeatedly, or absorb damage in clothing, and observe whether the quality bar moves. Is degradation happening at all for the categories where you enabled it?
These tests take twenty to thirty minutes and will surface configuration errors that are invisible when reading the JSON file. A Despawn_Dropped_Time set to 60.0 instead of 600.0 makes dropped items disappear in one minute instead of ten. The config file looks fine. The numbers are valid JSON. The server log shows no errors. The only way to know the value is wrong is to be in the world and watch an item vanish sixty seconds after you dropped it.
Managing the section over time
As your server's player count changes, as new maps are added to rotation, or as the community's skill level evolves, the Items section configuration that worked at launch may no longer feel right. A server that launched with 10 concurrent players and a Spawn_Chance of 0.3 will feel barren when the player count hits 40 because the same item pool is now divided among four times as many scavengers. A server that launched with Quality_Full_Chance at 0.1 to create progression pressure for new players will feel unsatisfying when the player base has accumulated stashes of high-quality gear through other means.
Revisit the section periodically. Walk the world on your own server. Ask your players whether they are finding too much or too little. The Items section is a living configuration surface, not a set-and-forget one. The keys are the levers. The world is the readout. When they drift apart, the levers are what you adjust.
Frequently asked questions
What happens if I don't include the Items section at all?
The server applies its hardcoded defaults for all twenty keys. The exact values of those defaults are not publicly documented, but the game runs normally with an absent Items section. The default item economy is the one the game's developers chose as a general-purpose baseline.
Can I set Spawn_Chance above 1.0?
The game describes the key as accepting a value in the 0-to-1 range. Values above 1.0 are outside the documented range and may produce undefined behaviour or be clamped by the server. A value of 1.0 already activates every spawn point on the map; there is no practical reason to exceed it.
How do I make only specific items spawn at full quality?
Use the per-item-type full-quality overrides. Set Has_Durability to true (to enable per-type control), then set the full-quality override for the categories you want to always be pristine. For example, setting Weapons_Spawn_At_Full_Quality to true and leaving all other overrides at false makes only weapons spawn at full quality. Food, water, clothing, and default items follow the Quality_Full_Chance and Quality_Multiplier values. There is no per-item override; the finest granularity available is per-item-category.
What is the relationship between Has_Durability and the per-type keys?
Has_Durability is the master switch. When it is false, all per-type durability and quality keys are ignored and every item is always at 100% quality with no degradation. When Has_Durability is true, the per-type keys become active. You cannot partially override the master switch; it is all or nothing at that level. Per-type control requires Has_Durability: true.
Can I use the same value for all three ammunition key pairs?
Yes. Setting Gun_Bullets_Full_Chance, Magazine_Bullets_Full_Chance, and Crate_Bullets_Full_Chance to the same value makes the ammunition-fill probability identical across all three item categories. The same applies to the multiplier keys. This produces a uniform ammunition landscape. Many servers do this for simplicity.
Why would I want different values for gun, magazine, and crate ammunition?
Different values allow you to create an ammunition economy where, for example, guns are rarely found loaded, magazines are sometimes found loaded, and ammunition crates are reliably full. This creates a scavenging chain: find a gun (empty), find a magazine (partially full), find an ammunition crate (full), reload the magazine, load the gun, now you are combat-ready. The chain adds depth to the loot loop. If all three pairs are identical, finding a loaded gun is as likely as finding a full magazine, and the ammunition economy is simpler.
Does Respawn_Time affect items dropped by players?
No. Respawn_Time affects only naturally spawned items. When a dropped item despawns due to Despawn_Dropped_Time, no respawn occurs at that location because the item was not occupying a spawn point that the server tracks for respawn purposes. The original spawn point that produced the item (if any) follows the respawn logic independently and is not affected by the item being dropped or despawning elsewhere.
What happens to items on the ground when the server restarts?
The server's behaviour on restart with respect to ground items is not documented in the Items section's field descriptions. Server operators should assume that a restart clears all ground items and that the spawn system begins a fresh cycle when the server comes back up, populating items up to the Spawn_Chance cap over the first Respawn_Time interval.
Does the Items section affect items in containers or storage?
No. The Items section governs ground loot -- items that spawn at map spawn points and items dropped by players onto the ground. Items inside storage containers (crates, lockers, chests), items in player inventories, and items in vehicle storage are not affected by the spawn, despawn, or respawn keys in this section. Quality and durability keys may affect items that enter the world through other means, but the spawn-and-despawn group applies only to items on the ground.
If I set Has_Durability to false, do Quality_Full_Chance and Quality_Multiplier still matter?
No. When Has_Durability is false, all items spawn at 100% quality and never degrade, which means the server never consults Quality_Full_Chance or Quality_Multiplier. Those keys are still valid JSON in the config file and will not cause an error, but they have no effect. The same is true for all six ammunition keys and all eight per-type override keys: they are present in the file and syntactically valid, but they are ignored when Has_Durability is false.
What is the difference between Despawn_Natural_Time and Despawn_Dropped_Time in practice?
Despawn_Natural_Time applies to items that appeared at spawn points through the normal loot system. Despawn_Dropped_Time applies to items that were carried by a player and then discarded. The two timers run independently and an item can only be under one of them at a time -- an item is either naturally spawned or player-dropped, never both. A naturally spawned item that a player picks up and then drops back onto the ground is now a dropped item, and its despawn timer switches from the natural timer to the dropped timer at the moment it is dropped.
Common mistakes
These are the configuration errors the 57 Studios cohort has observed most frequently in server config files reviewed during troubleshooting sessions. Each entry describes the mistake, why it produces unexpected behaviour, and how to detect it.
Setting Has_Durability to false expecting per-type control
The most frequent mistake in the entire Items section. A server owner reads about Weapons_Have_Durability and Clothing_Has_Durability, decides they only want durability degradation for weapons, and sets the config like this:
json
"Has_Durability": false,
"Weapons_Have_Durability": trueThe intent is clear: disable the master switch but override it for weapons. The actual behaviour: Has_Durability: false ignores every per-type key. Weapons do not degrade. No item degrades. Quality is locked at 100% for everything. The mistake is invisible -- the server loads without errors and runs normally -- but the behaviour is the opposite of what was intended.
Detection: Walk the server world and check item quality. If every item is at 100% quality and no item ever degrades, Has_Durability is false. Check weapon quality after sustained use; if it never drops, the master switch is overriding.
Fix: Set Has_Durability to true, then set Clothing_Has_Durability to false and Weapons_Have_Durability to true to achieve the original intent: clothing quality is permanent, weapons degrade.
Treating Spawn_Chance as a per-spawn-point probability
A server owner reads "percentage of item spawns to use" and interprets it as "each spawn point has this percent chance of spawning an item." They set Spawn_Chance to 0.5, expecting that each of 100 spawn points independently has a 50% chance of producing an item, resulting in roughly 50 items on average. The game's internal description clarifies the actual behaviour: 0.5 means a maximum of 50 items across the 100 spawn points, not a per-point probability.
The difference matters in practice. Under the probability interpretation, the item count would fluctuate: sometimes 45, sometimes 55, sometimes 50 exactly. Under the cap interpretation, the item count never exceeds the cap but can be lower if items have been picked up and are waiting for the respawn timer. The cap is not an average target; it is a hard ceiling. A server owner who expects variance will not see it; a server owner who expects a floor will not see that either. The actual item count is always somewhere below the ceiling, drifting upward as respawns happen and downward as players pick items up.
Detection: Count items in a loot-dense area. If the count is always at or below the cap value and never significantly exceeds it, the cap interpretation is correct. If the count fluctuates above and below the expected value randomly, your mental model is wrong and you may have also misconfigured Respawn_Time.
Fix: No config change needed if the behaviour is what you want. If you expected variance and got a ceiling, adjust Spawn_Chance upward to raise the cap, and shorten Respawn_Time so the server populates items up to the cap more aggressively.
Forgetting that Respawn_Time is approximate
A server owner sets Respawn_Time to 60.0 and stands at a spawn point with a stopwatch. They pick up an item and wait. At 60 seconds, no item appears. At 65 seconds, no item. At 70 seconds, an item appears. They conclude the key is broken. It is not. The game's own field description uses the word "approximately" for this key. The server schedules spawn checks at roughly the interval, not exactly at the interval.
The practical consequence is that testing Respawn_Time with a stopwatch is unreliable. You cannot validate the exact value by observation; you can only observe the general cadence. An item that should respawn roughly every 60 seconds might appear at 55 seconds, 70 seconds, or 48 seconds. The server is not broken; it is behaving as described.
Detection: Time ten respawn cycles and average them. If the average is close to your Respawn_Time value (within roughly 20% on either side), the key is working. If the average is off by a factor of two or more, your value may be wrong or may be interacting with another key.
Fix: Do not fine-tune Respawn_Time based on stopwatch tests. Set it to a value that produces the intended cadence in feel-terms, verify the average across multiple cycles, and leave it.
Setting quality keys without understanding the two-step process
A server owner sets Quality_Full_Chance to 0.0 and Quality_Multiplier to 0.0, expecting items to spawn at zero quality. Or they set Quality_Full_Chance to 0.0 and omit Quality_Multiplier, expecting the server to use a default multiplier. In the first case, items spawn at whatever the random roll produces multiplied by zero -- potentially zero or very low quality, which may or may not be the intended result and may produce items that are unusable. In the second case, an omitted Quality_Multiplier uses the server's hardcoded default, which may or may not be zero, and the actual quality curve may not match the intended one.
Detection: Check item quality across multiple spawn cycles. If you intended a uniform quality value and are seeing variance, one of the two keys is not set to the value you think it is. If you intended a specific low quality and are seeing items at near-normal ranges, Quality_Multiplier is higher than expected.
Fix: Always set both Quality_Full_Chance and Quality_Multiplier together. Understand that setting both to zero may produce items at zero quality, which might render them unusable. Understand that omitting either key falls back to the hardcoded default, which is not documented.
Mismatching the ammunition keys and expecting uniform behaviour
A server owner sets Gun_Bullets_Full_Chance to 0.8 (guns are usually loaded) but leaves Magazine_Bullets_Full_Chance and Crate_Bullets_Full_Chance at their defaults. They test by picking up guns and seeing that most are loaded. They conclude the ammunition system is working. But magazines found separately -- not inside guns -- follow a different, undocumented default value, and those magazines are not as full as the server owner expects. Players who find a gun and a separate magazine may wonder why the gun was full but the magazine is not.
Detection: Test ammunition fill across all three categories independently. Pick up guns, standalone magazines, and ammunition crates, and check their ammunition counts. If the counts differ systematically between categories, the keys are not aligned.
Fix: If you want uniform ammunition behaviour, set all six ammunition keys to the same values. If you intentionally want different behaviour, document the difference so that your players understand it is by design, not a bug.
Appendix: key-by-function quick reference
The table below groups the twenty keys by their functional role so that a server owner returning to this article for a quick lookup can find the relevant group without reading the full prose.
| Group | Keys | What they control |
|---|---|---|
| Spawn cap | Spawn_Chance | Maximum fraction of spawn points that can be active |
| Despawn timers | Despawn_Dropped_Time, Despawn_Natural_Time | How long player-dropped and naturally-spawned items persist |
| Respawn pacing | Respawn_Time | Approximate interval between spawn attempts below the cap |
| Base quality | Quality_Full_Chance, Quality_Multiplier | Probability of full quality and scaling of partial quality |
| Gun ammo | Gun_Bullets_Full_Chance, Gun_Bullets_Multiplier | Ammo fill rate for firearms found as loot |
| Magazine ammo | Magazine_Bullets_Full_Chance, Magazine_Bullets_Multiplier | Ammo fill rate for standalone magazines |
| Crate ammo | Crate_Bullets_Full_Chance, Crate_Bullets_Multiplier | Ammo fill rate for non-magazine ammo containers |
| Master durability | Has_Durability | Master on/off for quality variance and degradation |
| Full-quality overrides | Food_Spawns_At_Full_Quality, Water_Spawns_At_Full_Quality, Clothing_Spawns_At_Full_Quality, Weapons_Spawn_At_Full_Quality, Default_Spawns_At_Full_Quality | Per-category overrides for always spawning at 100% quality |
| Durability overrides | Clothing_Has_Durability, Weapons_Have_Durability | Per-category control over quality degradation through use |
Next steps
If you are configuring a server from scratch, the Items section is one part of a larger Config.json. The other sections you will likely need to tune alongside it are:
- The Vehicles section, which controls the vehicle economy using a structurally similar set of spawn, despawn, and respawn keys
- The Zombies section, which controls zombie spawn density, variant types, damage, and loot drops -- the item economy's demand-side counterpart
- The Players section, which controls starting health, vitals, death penalties, and skill retention -- the context in which the item economy operates
- The Gameplay section, which controls global gameplay settings that interact with item behaviour
If you are a map author rather than a server operator, the items your map spawns are defined in your spawn tables, not in Config.json. The Items section controls the conditions those spawned items operate under on any server that runs your map. As the map author, you cannot force a server operator to use your preferred Items section configuration. You can recommend one in your workshop description, and you should test your map under multiple Items section profiles to confirm it plays well across the range of configurations your players' servers will use.
Return to the Config.json overview for the complete file structure and a list of all sections.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-28 | 57 Studios | Initial publication. Complete Items section reference covering all 20 keys with grouped explanations, quality system, ammo fill rates, durability overrides, interaction analysis, four configuration profiles, canned beans section, FAQ, and practical testing guidance. |