Config.json Barricades and Structures

Intermediate20-30 minutesCross-platformUnturned ServerConfig.json

When you edit the Config.json file for an Unturned dedicated server, two sections govern every player-built object in the world: Barricades and Structures. These blocks of keys control how long a built object survives without its owner logging in, how much damage it takes from different weapon classes, how fast it can be repaired, and -- for barricades only -- what players are allowed to attach to their vehicles. Together they form the durability and decay layer of the server's building system.

This article documents every key in both sections. For each key, it explains what the setting does in mechanical terms, how the value interacts with the other multipliers in the same section, and what a server owner should consider when choosing a value. The two sections are documented together because their seven shared keys work identically in concept; the four barricade-only keys that govern vehicle building are covered in their own section later in the article.

Nothing in this article assumes prior experience editing Unturned server configuration. Every term is defined the first time it appears, and every multiplier is explained with concrete examples. The article does not tell you what value to set; it tells you what each value means so that you can make an informed decision for your server's intended play style.

Prerequisites

• A working Unturned dedicated server installation with a Config.json file you can locate and edit
• A text editor capable of saving plain UTF-8 without a byte order mark -- Notepad++, VS Code, Sublime Text, or any editor that does not inject formatting characters into JSON
• A basic understanding of JSON syntax: keys are quoted strings, values follow a colon, floats use a decimal point, booleans are true or false without quotes, and the file as a whole is a valid JSON object

Where to find these keys in Config.json

The Config.json file for an Unturned dedicated server is a single JSON object containing numerous top-level keys. The Barricades and Structures keys covered in this article live inside nested objects. The structure of the file arranges them as follows:

{
  "Barricades": {
    "Decay_Time": <value>,
    "Armor_Lowtier_Multiplier": <value>,
    ...
  },
  "Structures": {
    "Decay_Time": <value>,
    "Armor_Lowtier_Multiplier": <value>,
    ...
  }
}

If the "Barricades" or "Structures" objects do not appear in the Config.json file at all, the server uses its internal defaults for every key in that section. Adding the object with one or more keys overrides the defaults only for the keys you specify; any key you omit retains its internal default. The tables in this article list - in the Default column because the internal defaults are not exposed by the SDK source that documents the keys. The value you set in your Config.json replaces whatever the internal default is.

What you'll learn

• The mechanical difference between a barricade and a structure in Unturned's item classification system
• Every key in the Barricades section of Config.json, with its type, default, and a plain-language explanation of what it governs
• Every key in the Structures section of Config.json, with the same reference detail
• How Decay_Time works, including the server-offline safeguard that resets all decay timers under specific conditions
• How armour tier multipliers scale incoming damage for Low-tier and High-tier buildables
• How gun calibre multipliers separate the damage of Heavy Weapon firearms from all other guns
• How melee damage and melee repair multipliers work in opposite directions on the same target
• The four vehicle placement keys unique to the Barricades section: two boolean toggles and two distance limits
• The order in which the game applies multipliers during a damage calculation so that server owners can predict the effect of configuration changes
• How to approach tuning both sections for a specific server profile by answering a sequence of design questions

What barricades and structures are

In Unturned's item and world-object classification, barricades and structures are two distinct categories of player-built object. The distinction matters because each has its own block in Config.json, and the keys are not shared: a value set under the Barricades section does not affect Structures, and vice versa, even when the key name and purpose are identical. This independence is a design feature, not an oversight. It lets a server owner assign different durability, decay, and repair profiles to the two categories without compromise.

Barricades defined

A barricade is any object placed through the barricade placement system. Open your inventory, select a placeable item, and place it on a valid surface in the world: that is a barricade. The category is broad. It includes storage containers -- wooden crates, metal lockers, pine wardrobes, military-grade cabinets -- which are the most commonly placed barricades on most servers. It includes defensive items: barbed wire, caltrops, wooden spikes, metal spikes, and sandbags. It includes functional furniture: beds (which serve as respawn points when claimed), bookshelves, ovens, refrigerators, and crafting stations. It includes deployable equipment: portable generators, fuel-powered spotlights, sentry guns, and claimed flags. It includes cosmetic and roleplay items: rugs, wall-mounted trophies, and decorative placards.

Barricades are placed freely on any valid surface. There is no building grid. The player positions and rotates the item by hand, and the game checks only that the placement point is valid -- the surface exists, the barricade fits, and nothing blocks its footprint. A barricade can be placed on a floor, a wall, a ceiling, a terrain surface, or -- if the server configuration permits it -- on a vehicle. There is no structural integrity system for barricades; they exist independently of each other and do not depend on adjacent objects for support.

Barricades have owners. The Steam ID of the player who placed the barricade is recorded, and the barricade's decay timer runs against that owner's last login time. Barricades placed inside a claimed area or within a group's build zone may inherit group ownership, in which case the decay timer runs against any group member's last login rather than the original placer's.

Structures defined

A structure is any object placed through the structure placement system. Structures are the skeleton of a base: pillars, walls, floors, roofs, ramps, doorframes, garage frames, hatches, and the triangular corner and edge variants of each. Where barricades are the contents of the house, structures are the house itself, and the game treats them with a different set of placement rules to reflect that role.

Structures snap to a building grid. When a player places a structure, the placement position is snapped to the nearest valid grid point rather than placed at the exact cursor location. Adjacent structures align to the same grid, which produces the coherent rooms, corridors, and multi-storey buildings that define player bases in Unturned. The grid system is the foundational difference between barricade placement and structure placement: barricades are freehand, structures are grid-locked.

Structures cannot be placed on vehicles. The four vehicle-related keys that appear in the Barricades section have no counterpart in the Structures section because there is no category of "structures on vehicles" in the game's item system. A server that allows barricade placement on vehicles does not extend that permission to walls or pillars.

Structures share the same ownership and decay model as barricades. The player who placed the structure is recorded as its owner, and the decay timer runs against that owner's login activity. Group ownership applies where the structure was placed within a group's build zone.

Why the distinction matters for configuration

The fact that barricades and structures are configured separately means that server owners can assign different survival profiles to the two categories:

• Different decay windows. A server can set barricades to decay after three days of owner inactivity while structures persist for two weeks. This produces a world where abandoned storage crates and furniture are cleaned up promptly but the architectural shell of an abandoned base remains standing -- a useful pattern for roleplay servers where ruined buildings contribute to the map's atmosphere while cluttered interiors do not.
• Different durability. A server can make barricades fragile (high damage multipliers) and structures tough (low damage multipliers), creating a raiding dynamic where the objective is to breach the walls and the contents inside are easily destroyed once the outer shell falls.
• Different repair speeds. A server can make barricades quick to repair and structures slow, or vice versa, depending on whether the server owner wants maintenance effort to concentrate on the outer shell or the interior fixtures.

These profiles emerge from setting the same key to different values in each section. There is no single "buildable health" slider that governs both categories at once. Every tuning decision is made twice, once per section, and the independence of the two sections is the tool that lets a configuration express a specific world-building intent.

The Barricades section

Eleven keys. Source: the Unturned SDK PlayConfigData.cs, class BarricadesConfigData.

Key	Type	Default
Decay_Time	uint	-
Armor_Lowtier_Multiplier	float	-
Armor_Hightier_Multiplier	float	-
Gun_Lowcal_Damage_Multiplier	float	-
Gun_Highcal_Damage_Multiplier	float	-
Melee_Damage_Multiplier	float	-
Melee_Repair_Multiplier	float	-
Allow_Item_Placement_On_Vehicle	bool	-
Allow_Trap_Placement_On_Vehicle	bool	-
Max_Item_Distance_From_Hull	float	-
Max_Trap_Distance_From_Hull	float	-

The first seven keys govern decay timing, damage scaling by armour tier and weapon class, and repair speed. The last four govern vehicle building: two boolean toggles that allow or disallow vehicle attachment, and two float distance limits that constrain how far from the vehicle body a placed barricade or trap can extend.

The Structures section

Seven keys. Source: the Unturned SDK PlayConfigData.cs, class StructuresConfigData.

Key	Type	Default
Decay_Time	uint	-
Armor_Lowtier_Multiplier	float	-
Armor_Hightier_Multiplier	float	-
Gun_Lowcal_Damage_Multiplier	float	-
Gun_Highcal_Damage_Multiplier	float	-
Melee_Damage_Multiplier	float	-
Melee_Repair_Multiplier	float	-

These are the same seven shared keys that appear in the Barricades section, governing decay timing, armour-tier damage scaling, gun-damage scaling by calibre class, melee damage scaling, and melee repair scaling. The Structures section is self-contained: every key here operates on structures only. A structure's damage calculation draws exclusively from the values in this block; it never consults the Barricades block, even for identically named keys.

Reading the key tables

Both tables above follow a consistent format. This section explains how to interpret each column so that you can read the tables without prior exposure to Unturned's type system or configuration conventions.

The Key column

The Key column lists the exact string you must write in your Config.json file. Key names are case-sensitive. Decay_Time and decay_time are different as far as the game is concerned, and only the casing shown in the table -- PascalCase with underscores separating words -- is recognised by the server. The key always appears inside double quotes in the JSON file: "Decay_Time": 604800.

The Type column

The Type column lists the data type the game expects for the value associated with the key. Four types appear in these two sections:

• uint -- unsigned integer. A whole number that cannot be negative. Written in JSON without quotes, without a decimal point, and without commas or other separators. Examples: 0, 3600, 604800, 1209600. The server may reject or misread values that are negative, fractional, or formatted with digit group separators.
• float -- floating-point number. A number that may include a fractional portion after a decimal point. Written in JSON without quotes. Examples: 0.0, 0.5, 1.0, 2.5, 0.75. The game expects the decimal separator to be a period, regardless of the operating system's locale settings. A value written as 0,5 (using a comma) is not a valid JSON number and will cause the file to fail parsing.
• bool -- boolean. A value that is either true or false. Written in JSON without quotes. The game recognises the lowercase JSON literals true and false. The strings "true", "false", "True", "FALSE", or the integers 1 and 0 are not valid boolean values in JSON and will cause the key to be read incorrectly or the file to fail parsing.

The Default column

The Default column displays - for every key in both sections. This notation means that the internal default value for the key is not documented in the SDK source from which these tables are drawn. It does not mean the default is literally a hyphen character or that the key has no default behaviour. Every key has a built-in fallback value that the server uses when the key is absent from Config.json. The tables mark that fallback as - because the source does not expose it.

When you add a key to your Config.json, the value you write replaces the internal default. When you omit a key, the internal default applies. This means you do not need to include every key in your file. A minimal Barricades section might contain only Decay_Time and Armor_Hightier_Multiplier, leaving the remaining six keys at their internal defaults. The server will not produce errors for missing keys.

Decay_Time

Decay_Time is typed as uint and measured in seconds. It defines an expiration window for player-built objects. When the owner of a barricade or structure last logged into the server -- or when any member of the owner's Steam group last logged in -- a countdown begins. The length of that countdown is the value of Decay_Time. If the countdown reaches zero, the object is no longer saved when the server next writes world data to disk. On that save, the object is removed from the world.

How the countdown works

The decay countdown is owner-scoped. If a player named Alex places a wooden crate on Monday and does not log in again, the crate's countdown starts on Monday at the moment of logout. If Alex is a member of a Steam group that also includes a player named Jordan, and Jordan logs in on Wednesday, the countdown for Alex's crate resets to the full Decay_Time value on Wednesday. The group member does not need to interact with the crate. They do not need to be near the crate. Logging into the server is the only action required. The game checks ownership against the Steam ID that placed the object and the Steam group that the owner belonged to at the time of placement.

If the group membership changes after placement -- if Alex leaves the group or the group is disbanded -- the game still tracks the original owner and the original group state at the time of placement for decay purposes. A player who leaves a group does not render their previously placed barricades and structures ineligible for group-member login resets that occurred before the departure. However, future logins by former group members no longer reset the timer.

Practical value ranges

Server owners choose a Decay_Time based on how long they want inactive builds to persist. The following ranges reflect common server profiles:

• 86400 (one day) and below. Aggressive cleanup. Suitable for test servers, event servers with short lifespans, and high-turnover survival servers where abandoned structures are a performance and gameplay concern. A player who misses a single day returns to find their builds gone. At values below 3600 (one hour), the offline-reset safeguard (described below) becomes the dominant mechanic, and the timer may never actually expire on a server that restarts or updates regularly.
• 259200 to 604800 (three days to one week). Moderate cleanup. The most common range for public survival servers. A player can go away for a weekend and return to intact builds, but a week-long absence results in removal. This range balances server performance -- removing truly abandoned builds -- against player goodwill.
• 1209600 to 2592000 (two weeks to one month). Preservation-oriented. Typical for roleplay servers, community servers with established player bases, and servers where builds represent weeks or months of collective effort. A player on an extended absence can return to their base intact, but a genuinely abandoned build will eventually be cleaned up.
• 0 or unset. Decay disabled. Objects persist indefinitely regardless of owner activity. This is the default stance for private servers, creative-mode servers, and servers where the owner manages clutter through manual inspection and deletion rather than an automated timer.

The server-offline safeguard

The decay system includes a protection against mass wipes during server downtime. If the server process is offline for a continuous period that exceeds half of the Decay_Time value, every decay timer on the server -- for every barricade or structure, regardless of owner -- is reset to the full Decay_Time when the server comes back online.

Take a Decay_Time of 86400 (one day). A server that goes down for planned maintenance at hour twelve of the countdown and stays offline for thirteen hours -- more than half of one day -- will, upon restart, reset every decay timer. An object that was twenty-three hours into its countdown and one hour from deletion is suddenly granted a fresh full day. This behaviour only triggers when the downtime exceeds half the Decay_Time. A ten-minute restart does not reset anything.

The safeguard exists to prevent the following scenario: a server owner schedules an eight-hour maintenance window on a server with a one-day Decay_Time. During the maintenance, every decay timer continues counting in real time even though the server is not running. When the server comes back online, it checks all decay timers, finds that many have expired during the downtime, and deletes every barricade and structure on the server in a single save cycle. The safeguard prevents this by detecting that the downtime exceeded half the decay window and resetting all timers.

The practical consequence for server owners is that Decay_Time should be at least twice the server's typical maximum downtime window. If your server typically goes offline for updates that take up to one hour, a Decay_Time below 7200 (two hours) is at risk of being nullified by the offline reset. A Decay_Time of 86400 (one day) on a server with a maximum downtime of four hours works as intended: four hours is less than half of one day, so the safeguard does not trigger, and decay timers that expired during the four-hour window are processed normally on restart.

Independent decay windows for each category

Barricade Decay_Time and structure Decay_Time are separate keys. A server can assign different decay windows to each category. Common patterns include:

• Structures survive longer than barricades. If Structures.Decay_Time is 1209600 (two weeks) and Barricades.Decay_Time is 604800 (one week), the architectural shell of an abandoned base persists twice as long as its contents. This is useful for roleplay servers where ruined buildings are atmospheric but abandoned crates full of loot are visual and performance clutter.
• Barricades survive longer than structures. If the server wants storage to persist but walls to cycle out, the barricade timer is set higher. This pattern is less common but appears on servers where players are encouraged to build minimally and where storage persistence is treated as a quality-of-life feature.
• Identical timers. The simplest case: both sections use the same Decay_Time value, and the server treats all player-built objects uniformly.

Decay and the server save interval

The decay check runs as part of the server's world-save cycle, not as a continuously ticking clock. If the server's save interval is set to 300 seconds (five minutes) and a barricade's decay countdown reaches zero at second 180 of that interval, the barricade persists for another 120 seconds until the save cycle executes and removes it. The effective decay time is the configured Decay_Time plus up to one save interval of additional existence.

This lag between timer expiry and actual removal is not configurable through the Barricades or Structures sections. It is governed by the server's save interval, which is set elsewhere in Config.json. A server with a very long save interval (such as 1800 seconds, or thirty minutes) will see barricades persist for up to half an hour past their decay deadline. A server with a very short save interval (such as 60 seconds) will see near-instant removal once the timer expires.

Armour tier multipliers

Every barricade and structure in Unturned carries an armour tier classification in its asset data: Low or High. The tier is set by the item's creator at the asset level and is not a property that players see in the standard user interface. It is not something a server owner can change through Config.json, and it is not something a player chooses when placing the item. It is a fixed data field in the item definition.

Wooden buildables -- pine walls, birch floors, maple pillars, and their triangular variants -- are predominantly classified as Low tier. Metal buildables -- metal walls, metal floors, metal pillars, and their reinforced variants -- are predominantly classified as High tier. Brick buildables, where the map or a mod provides them, are typically High tier. The classification is binary; there is no numeric tier scale, no Medium tier, and no way to assign a buildable to a tier other than the one its asset data specifies.

Armor_Lowtier_Multiplier

Typed as float. Applied to every point of damage received by a barricade or structure whose armour tier is Low.

The multiplier scales incoming damage from all sources: gunfire, melee strikes, explosions, vehicle collisions, and any custom damage type introduced by a mod. A value of 1.0 means Low-tier buildables take damage at the normal rate -- the armour tier has no modifying effect. A value of 0.5 cuts incoming damage in half, making every Low-tier barricade or structure twice as durable as it would be at the normal rate. A value of 2.0 doubles incoming damage, making Low-tier buildables half as durable.

The armour tier multiplier is the first multiplier applied in the damage calculation. It modifies the raw incoming damage before any weapon-class multiplier sees it. This means the armour tier multiplier has an outsized influence relative to the weapon-class multipliers: halving the armour tier multiplier halves the effective damage of every weapon against that tier, before those weapons' own multipliers are even applied.

Armor_Hightier_Multiplier

Typed as float. The same concept applied to buildables whose armour tier is High. Operates independently of Armor_Lowtier_Multiplier.

A server owner can set different values for the two tiers to widen or narrow the durability gap between wooden and metal buildables. Setting both to 1.0 preserves the gap at whatever the base asset health values produce. Setting Armor_Lowtier_Multiplier to 1.0 and Armor_Hightier_Multiplier to 0.5 leaves wood at normal durability and doubles the effective health of metal. Setting both to 0.5 doubles the durability of everything but preserves the proportional gap between tiers.

The multiplier does not distinguish between damage types. A fist, a kitchen knife, an assault rifle, and a rocket launcher all have their damage scaled by the same armour tier multiplier before their own weapon-class multiplier is applied. If you want metal walls to be tough against guns but vulnerable to explosives, you cannot achieve that with armour tier multipliers alone; the armour tier multiplier affects all damage equally. Weapon-specific tuning is the role of the gun calibre and melee multipliers covered in the following sections.

Why two armour tier multipliers exist

The separation of Low and High tier multipliers gives server owners control over the relative value of building materials. Without this separation, every buildable would share one durability scalar, and the choice between wood and metal would be purely aesthetic. With the separation, a server can make metal genuinely valuable -- by setting Armor_Hightier_Multiplier significantly lower than Armor_Lowtier_Multiplier -- or can flatten the material hierarchy by setting the two multipliers to similar values.

On a server where resources are scarce and metal is hard to acquire, a wide gap between the two multipliers rewards the investment. On a server where building materials are abundant and the server owner wants combat encounters to be decided by player skill rather than by who has the most metal, a narrow gap or identical values serve that intent.

Gun damage multipliers

Unturned classifies every firearm internally as either a "Heavy Weapon" or not. This classification is set in the weapon's asset data and is not exposed through Config.json. The classification determines which of two gun damage multipliers applies when the weapon strikes a buildable.

What counts as a Heavy Weapon

Weapons flagged as Heavy Weapon include the game's largest firearms: the Dragonfang, the Nykorev, the Timberwolf, the Grizzly, the Matamorez, the Ekho, and the Hell's Fury. These weapons share characteristics that make them distinct from standard firearms: they typically deal high damage per shot, they are rare in the loot progression, and they are intended by the game's design to serve as the upper tier of the weapon hierarchy. The Heavy Weapon flag is the data-level marker that connects these design intentions to the damage calculation.

Everything that is not flagged as a Heavy Weapon falls into the other category. This includes assault rifles (the Maplestrike, the Zubeknakov, the Eaglefire, the Heartbreaker), submachine guns (the Yuri, the Bulldog, the Viper, the Scalar), pistols (the Colt, the Avenger, the Cobra, the Desert Falcon), shotguns (the Bluntforce, the Vonya, the Masterkey), designated marksman rifles (the Snayperskya, the Sabertooth), and all other firearms that the game ships. Ammunition type, magazine capacity, rate of fire, and attachment slots do not affect the Heavy Weapon classification; it is a single boolean flag on the weapon asset.

Gun_Lowcal_Damage_Multiplier

Typed as float. Scales the damage dealt to barricades and structures by firearms that are not flagged as Heavy Weapons.

A value of 1.0 means non-heavy guns deal their normal damage to buildables. A value of 0.5 halves the damage, making it take twice as long -- and cost twice the ammunition -- to destroy a buildable with these weapons. A value of 2.0 doubles the damage, making non-heavy guns an efficient raiding tool.

On a server that wants raiding to be exclusive to heavy weapons, Gun_Lowcal_Damage_Multiplier is set below 1.0. On a server that wants all firearms to be viable against buildables, it is set to 1.0 or higher. The value interacts with the armour tier multiplier in the damage chain: a Gun_Lowcal_Damage_Multiplier of 0.5 and an Armor_Hightier_Multiplier of 0.5 together produce 25 percent of the weapon's base damage against a High-tier buildable.

Gun_Highcal_Damage_Multiplier

Typed as float. Scales the damage dealt to barricades and structures by firearms flagged as Heavy Weapons.

Because heavy weapons are rarer and more powerful by design, this multiplier is often set higher than its low-calibre counterpart on raiding-focused servers, establishing heavy weapons as the intended raiding tool. On servers where the owner wants building destruction to be difficult regardless of weapon choice, both gun multipliers are set low. On servers where the owner wants building destruction to be quick by any means, both are set high.

The two gun multipliers and the two armour tier multipliers together form a four-variable damage space. The server owner chooses values for each that produce the intended relationship between weapon rarity, material tier, and the time and resource cost of destroying a player-built object.

Interaction between gun multipliers and armour tier

When a gun fires at a buildable, the damage calculation always passes through both an armour tier multiplier and a gun calibre multiplier. This means a server owner who wants to make a specific weapon class ineffective against a specific buildable tier has two places to make that adjustment: the armour tier key or the gun calibre key. Which one to use depends on the scope of the change.

Changing an armour tier multiplier affects every weapon that strikes that tier, including melee. Changing a gun calibre multiplier affects only guns in that calibre class. If the intent is to make all weapons less effective against metal, change Armor_Hightier_Multiplier. If the intent is to make assault rifles less effective against everything, change Gun_Lowcal_Damage_Multiplier. If the intent is specifically to make assault rifles less effective against metal while leaving heavy weapons effective against metal, both multipliers are adjusted together.

Melee damage and repair multipliers

Two keys in each section govern what happens when a player swings a melee item at a buildable object. One controls destruction; the other controls restoration. They are separate keys because they serve opposite functions, and they are tuned independently.

Melee_Damage_Multiplier

Typed as float. Scales the damage dealt to barricades and structures by all melee weapon strikes and unarmed punches.

This multiplier covers every melee-classified interaction a player can initiate against a buildable. It does not distinguish between melee items designed for combat (military knives, katanas, baseball bats) and melee items designed as tools (axes, sledgehammers, chainsaws). A fire axe striking a wall and a kitchen knife striking the same wall both route through this one key. The weapon's own damage value determines the base damage; the multiplier scales it.

A server that encourages melee raiding -- either because the server is explicitly melee-only or because the loot economy makes ammunition scarce -- sets this multiplier high. A server that wants raiding to require firearms sets it low. A server that wants building destruction to be equally viable through melee and gunfire sets it to match the gun damage multipliers.

The multiplier applies after the armour tier multiplier. A Low-tier wall taking a melee hit with Armor_Lowtier_Multiplier at 0.5 and Melee_Damage_Multiplier at 0.5 receives 25 percent of the weapon's base melee damage.

Melee_Repair_Multiplier

Typed as float. Scales the amount of health restored to a barricade or structure by melee items whose function is repair. The Blowtorch is the primary repair tool in the base game.

Unlike every other multiplier in these two sections, Melee_Repair_Multiplier does not modify damage. It operates on the repair pathway, which is a separate mechanical system from damage. When a player applies a repair tool to a damaged buildable, the health restored per interaction is multiplied by this value. The multiplier does not change the interaction speed, the tool's durability consumption, or the fuel cost; it only changes the health amount added.

A value of 1.0 means repair tools restore their normal amount of health. A value of 0.5 halves the repair rate. A value of 2.0 doubles it.

The repair multiplier interacts with the damage multipliers indirectly, through the repair-to-damage ratio. If a server sets all damage multipliers to 0.5 (buildables take half damage) and sets Melee_Repair_Multiplier to 2.0 (repair is twice as fast), the effective repair-to-damage ratio shifts strongly in favour of the defender. A damage setup that takes thirty seconds to deal could be repaired in a fraction of that time if the repair multiplier is high. Conversely, if damage multipliers are high and the repair multiplier is low, repair becomes an impractical response to active raiding and serves only as a post-raid restoration tool.

Vehicle placement keys (barricades only)

Four keys in the Barricades section govern whether and how barricades can be attached to vehicles. Structures have no equivalent keys; structures cannot be placed on vehicles. These keys exist exclusively in the Barricades block because barricades -- unlike structures -- are candidates for vehicle attachment in the game's placement system.

Allow_Item_Placement_On_Vehicle

Typed as bool. When set to true, players are permitted to place non-trap barricade items on vehicles they own or have build permission for. When set to false, the placement interaction is blocked entirely -- the game refuses to attach any barricade to any vehicle surface, regardless of the player's relationship to the vehicle.

The barricades that this key governs include storage crates, beds, generators, spotlights, sentry guns, claimed flags, and all other non-trap placeables in the barricade inventory. When placed on a vehicle, these barricades become physically attached to it. They move with the vehicle, rotate with it, and are subject to the same decay and damage rules as ground-placed barricades. The Barricades section's multipliers -- armour tier, gun calibre, melee -- apply to vehicle-attached barricades identically.

Allow_Trap_Placement_On_Vehicle

Typed as bool. When set to true, players are permitted to place trap-classified barricades on vehicles. Traps in this context include barbed wire, caltrops, wooden spikes, metal spikes, and any other barricade item whose asset data classifies it as a trap.

This key is separate from Allow_Item_Placement_On_Vehicle so that server owners can permit utility and storage barricades on vehicles while denying weaponised attachments. A server that wants vehicles to function as mobile crafting and storage stations -- but does not want players armouring their cars with damage-dealing barricades -- would set Allow_Item_Placement_On_Vehicle to true and Allow_Trap_Placement_On_Vehicle to false.

The separation also allows the inverse: a server that wants vehicle traps but not vehicle storage would set the storage toggle to false and the trap toggle to true. This is a less common configuration, but the keys exist independently so that it is possible.

Max_Item_Distance_From_Hull

Typed as float. Defines the maximum placement distance, measured from the vehicle's collision geometry (its hull), for non-trap barricade items. The measurement is taken from the outer surface of the vehicle's collider mesh to the placement point the player has targeted.

This key operates as a build envelope constraint. A short distance restricts barricade placement to positions flush against or very near the vehicle body. A longer distance allows barricades to extend further outward, which enables more elaborate vehicle builds -- floating platforms, extended storage arrays, barricade structures that project well beyond the vehicle's footprint.

The distance check is performed at placement time. If a player targets a point whose distance from the nearest vehicle collider exceeds this value, the placement is rejected and the barricade is not placed. The game does not snap the barricade to a nearer valid point; the player must reposition and try again.

Max_Trap_Distance_From_Hull

Typed as float. The same concept as Max_Item_Distance_From_Hull, applied to trap-classified barricades. Defines the maximum placement distance from the vehicle hull for trap items.

This key is separate from its non-trap counterpart so that traps can have a more restrictive build envelope. A server owner who wants utility barricades to extend freely from vehicles but wants traps confined tightly to the vehicle body -- to prevent vehicles from becoming wide-area damage zones -- would set Max_Trap_Distance_From_Hull to a lower value than Max_Item_Distance_From_Hull.

Vehicle placement keys (barricades only)

Four keys in the Barricades section govern whether and how barricades can be attached to vehicles. Structures have no equivalent keys; structures cannot be placed on vehicles. These keys exist exclusively in the Barricades block because barricades -- unlike structures -- are candidates for vehicle attachment in the game's placement system.

Why these keys are barricade-only

The game's item system treats barricades and structures differently at the engine level. A barricade is a standalone object that the server can attach to any valid placement surface, including the moving collision geometry of a vehicle. A structure is a grid-snapped building block whose placement logic depends on adjacency to other structures and alignment to the world grid. Vehicles do not have a building grid, do not participate in the structure placement system, and are not valid placement surfaces for structures. This is not a configuration choice that the vehicle placement keys could override if they existed in the Structures section; it is a fundamental limitation of the structure placement system.

The four vehicle keys in the Barricades section are therefore both the only vehicle-building controls available and the complete set of vehicle-building controls that can exist under the game's current item architecture. There is no hidden key, no planned key, and no moddable extension that makes structures attachable to vehicles through Config.json alone.

Allow_Item_Placement_On_Vehicle

Typed as bool. When set to true, players are permitted to place non-trap barricade items on vehicles they own or have build permission for. When set to false, the placement interaction is blocked entirely -- the game refuses to attach any barricade to any vehicle surface, regardless of the player's relationship to the vehicle.

The barricades that this key governs include storage crates, beds, generators, spotlights, sentry guns, claimed flags, and all other non-trap placeables in the barricade inventory. When placed on a vehicle, these barricades become physically attached to it. They move with the vehicle, rotate with it, and are subject to the same decay and damage rules as ground-placed barricades. The Barricades section's multipliers -- armour tier, gun calibre, melee -- apply to vehicle-attached barricades identically.

A server that disables vehicle barricades entirely sets this key to false. A server that allows vehicle-mounted storage and utility but not traps sets this key to true and Allow_Trap_Placement_On_Vehicle to false. A server that allows all vehicle barricades sets both toggles to true.

Allow_Trap_Placement_On_Vehicle

Typed as bool. When set to true, players are permitted to place trap-classified barricades on vehicles. Traps in this context include barbed wire, caltrops, wooden spikes, metal spikes, and any other barricade item whose asset data classifies it as a trap.

This key is separate from Allow_Item_Placement_On_Vehicle so that server owners can permit utility and storage barricades on vehicles while denying weaponised attachments. The separation allows a server to define a "mobile base" profile where vehicles carry crafting stations and storage but are not themselves offensive tools, or a "battle wagon" profile where traps are permitted alongside other barricades.

The separation also allows the uncommon inverse configuration. A server that wants vehicle traps but not vehicle storage would set the storage toggle to false and the trap toggle to true. This configuration exists in the design space but is rare in practice because most servers that permit weaponised vehicle attachments also permit utility attachments.

Max_Item_Distance_From_Hull

Typed as float. Defines the maximum placement distance, measured from the vehicle's collision geometry (its hull), for non-trap barricade items. The measurement is taken from the outer surface of the vehicle's collider mesh to the placement point the player has targeted.

This key operates as a build envelope constraint. A short distance restricts barricade placement to positions flush against or very near the vehicle body. A longer distance allows barricades to extend further outward, which enables more elaborate vehicle builds -- floating platforms, extended storage arrays, barricade structures that project well beyond the vehicle's footprint.

The distance check is performed at placement time. If a player targets a point whose distance from the nearest vehicle collider exceeds this value, the placement is rejected and the barricade is not placed. The game does not snap the barricade to a nearer valid point; the player must reposition and try again.

Max_Trap_Distance_From_Hull

Typed as float. The same concept as Max_Item_Distance_From_Hull, applied to trap-classified barricades. Defines the maximum placement distance from the vehicle hull for trap items such as barbed wire and spikes.

This key is separate from its non-trap counterpart so that traps can have a more restrictive build envelope than utility barricades. A server owner who wants storage crates to extend freely from vehicles but wants traps confined tightly to the vehicle body -- to prevent vehicles from becoming wide-area damage zones -- would set Max_Trap_Distance_From_Hull to a lower value than Max_Item_Distance_From_Hull.

Side-by-side comparison of the two sections

The table below summarises the relationship between the Barricades and Structures sections at a glance. It shows which keys are shared, which are exclusive to one section, and the mechanical reason for the difference.

Aspect	Barricades	Structures
Number of keys	11	7
Shared decay key	Decay_Time	Decay_Time
Shared armour tier keys	Armor_Lowtier_Multiplier, Armor_Hightier_Multiplier	Armor_Lowtier_Multiplier, Armor_Hightier_Multiplier
Shared gun damage keys	Gun_Lowcal_Damage_Multiplier, Gun_Highcal_Damage_Multiplier	Gun_Lowcal_Damage_Multiplier, Gun_Highcal_Damage_Multiplier
Shared melee keys	Melee_Damage_Multiplier, Melee_Repair_Multiplier	Melee_Damage_Multiplier, Melee_Repair_Multiplier
Vehicle placement keys	Allow_Item_Placement_On_Vehicle, Allow_Trap_Placement_On_Vehicle, Max_Item_Distance_From_Hull, Max_Trap_Distance_From_Hull	None -- structures cannot be placed on vehicles
Placement model	Free placement on any valid surface	Grid-snapped placement, adjacency-dependent
Vehicle interaction	Barricades can be attached to vehicles (subject to the four vehicle keys)	Not possible under the game's item architecture
Ownership tracking	Steam ID of placer; group ownership where applicable	Steam ID of placer; group ownership where applicable
Decay tracking	Countdown from owner or group member last login	Countdown from owner or group member last login
Damage calculation	Armour tier then weapon-class multiplier, from Barricades block	Armour tier then weapon-class multiplier, from Structures block
Repair calculation	Melee_Repair_Multiplier from Barricades block	Melee_Repair_Multiplier from Structures block

The seven shared keys are conceptually identical across the two sections -- they govern the same mechanics for their respective object category -- but their values are independent. The four barricade-only keys fill a functional gap: the game's placement system allows barricades on vehicles, and those four keys provide the on/off toggles and distance constraints to control that capability.

How the multipliers interact: the damage calculation order

When a barricade or structure takes damage, the game applies the relevant multipliers from its section in a fixed sequence. Understanding this sequence is the key to predicting how a configuration change will affect the world.

The damage chain

The calculation proceeds through four steps:

1. Base damage. The weapon delivers its raw damage value to the buildable. This is the number defined in the weapon's asset data, before any server-side modification.
2. Armour tier check. The game reads the buildable's armour tier from its asset data. If the tier is Low, the base damage is multiplied by Armor_Lowtier_Multiplier from the relevant section (Barricades or Structures). If the tier is High, it is multiplied by Armor_Hightier_Multiplier. The result is the armour-modified damage.
3. Weapon-class check. The game reads the weapon's classification. If the weapon is a non-Heavy Weapon gun, the armour-modified damage is multiplied by Gun_Lowcal_Damage_Multiplier. If the weapon is a Heavy Weapon gun, it is multiplied by Gun_Highcal_Damage_Multiplier. If the weapon is a melee item (or fist), it is multiplied by Melee_Damage_Multiplier. The result is the final damage.
4. Health subtraction. The final damage is subtracted from the buildable's current health. If the health reaches zero or below, the buildable is destroyed.

The repair chain

When a player repairs a buildable, the calculation is simpler:

1. Base repair. The repair tool delivers its raw repair value. This is the number defined in the tool's asset data.
2. Repair scaling. The base repair value is multiplied by Melee_Repair_Multiplier from the relevant section.
3. Health addition. The scaled repair value is added to the buildable's current health, capped at the buildable's maximum health.

The armour tier multipliers do not participate in the repair calculation. Neither do the gun calibre multipliers. Repair has its own single-multiplier pathway that is independent of the damage chain.

Why the order matters

Because the armour tier multiplier is applied before the weapon-class multiplier, the two values multiply each other's effect rather than adding to it. Two multipliers of 0.5 produce an effective damage of 25 percent of base, not 0 percent. Three multipliers of 0.5 produce 12.5 percent. The multiplication is commutative -- the result is the same regardless of order -- but the fact that the values multiply rather than accumulate means that each additional multiplier below 1.0 has a proportionally diminishing impact on further reductions while each additional multiplier above 1.0 has an amplifying effect.

A server owner who wants to cut all damage to buildables by half should change one multiplier to 0.5, not three multipliers to values that multiply to 0.5. The single change is easier to reason about, easier to document, and easier to tune later than a three-multiplier arrangement where any single value change alters the product.

Configuration profiles by server type

The keys in these two sections are interdependent, but server owners typically approach them by answering a sequence of design questions. The order matters because later questions build on the answers to earlier ones. The following sequence walks through the five decisions that produce a coherent configuration, then presents worked example profiles for three common server types.

Decision 1: Decay window

How long should inactive builds survive before the server removes them?

Set Decay_Time in both sections. Answer separately for barricades and structures or assign the same value to both. The value is in seconds. Common anchors:

• 0 -- decay disabled, builds persist indefinitely
• 86400 -- one day, aggressive cleanup for test and high-turnover servers
• 259200 -- three days, moderate cleanup for survival servers
• 604800 -- one week, standard for public survival servers with weekend-tolerant players
• 1209600 -- two weeks, standard for roleplay and community servers
• 2592000 -- approximately one month, preservation-oriented for servers with established player bases

The offline-reset safeguard means that the Decay_Time must be at least twice the server's typical maximum downtime for the decay mechanic to function normally. A server that undergoes multi-hour maintenance windows should use a Decay_Time that accommodates those windows.

Decision 2: Buildable durability relative to base game

How tough should buildables be, regardless of what is hitting them?

Set Armor_Lowtier_Multiplier and Armor_Hightier_Multiplier in both sections. Values below 1.0 increase durability. Values above 1.0 decrease it. Decide whether metal (High tier) should be proportionally more durable than wood (Low tier) and set a gap between the two multipliers that reflects the intended material value.

A PvE server where base defence is not a competitive concern might set both multipliers to 1.0 or lower to give builders confidence that their work will survive. A PvP server where raiding is a core activity might set multipliers above 1.0 to make base destruction fast and decisive. A roleplay server where buildable destruction is rare and primarily serves narrative purposes might set Low-tier multipliers moderate and High-tier multipliers very low, making metal bases functionally permanent.

Decision 3: Weapon effectiveness against buildables

Which weapons should be effective at destroying buildables?

Set Gun_Lowcal_Damage_Multiplier, Gun_Highcal_Damage_Multiplier, and Melee_Damage_Multiplier in both sections.

• Heavy weapons only. Set Gun_Lowcal_Damage_Multiplier low, Gun_Highcal_Damage_Multiplier at or above 1.0. This makes raiding an activity that requires rare, high-tier firearms.
• All guns viable. Set both gun multipliers to 1.0 or higher. Any firearm can raid.
• Melee-only raiding. Set gun multipliers low and Melee_Damage_Multiplier high. This is uncommon but appears on servers where ammunition is deliberately scarce and melee combat is the intended primary interaction mode.
• No raiding. Set all weapon-class multipliers to a value near zero. Buildables functionally cannot be destroyed by player weapons. This is typical for creative and build-focused servers.

Decision 4: Repair speed relative to damage

How fast should repair tools fix damage compared to how fast weapons deal it?

Set Melee_Repair_Multiplier in both sections. A value above 1.0 makes repair faster. Below 1.0 makes it slower.

The repair-to-damage ratio determines the tactical dynamic during a raid. If repair is fast, defenders can actively maintain their walls during an assault, turning the raid into a war of attrition where ammunition stockpiles matter as much as aim. If repair is slow, the defender's only option is to eliminate the raiders before the walls fail; once damage is dealt, it sticks.

A server that wants defenders to have a chance against a prepared raiding party sets the repair multiplier high. A server that wants raids to be decisive and irreversible sets it low.

Decision 5: Vehicle building permissions

What should players be allowed to build on their vehicles?

This decision applies only to the Barricades section. The Structures section has no vehicle keys.

Set Allow_Item_Placement_On_Vehicle and Allow_Trap_Placement_On_Vehicle to true or false based on whether the server permits each category of vehicle attachment. Set Max_Item_Distance_From_Hull and Max_Trap_Distance_From_Hull to distances that produce the intended build envelope. A conservative value -- close to zero -- keeps vehicle builds tight and prevents floating barricade platforms. A generous value allows elaborate vehicle construction.

Common vehicle building profiles:

• No vehicle building. Both toggles false. Distance limits are irrelevant but should be set to reasonable values in case the toggles are changed later.
• Storage only. Allow_Item_Placement_On_Vehicle true, Allow_Trap_Placement_On_Vehicle false. Players can attach crates, beds, and generators to vehicles but not weapons.
• Full vehicle building. Both toggles true. Players can attach any barricade, including traps. Distance limits are set wide enough to accommodate creative vehicle builds while preventing exploits.
• Traps only. Allow_Item_Placement_On_Vehicle false, Allow_Trap_Placement_On_Vehicle true. An uncommon configuration that permits weaponised vehicle attachments but denies utility attachments.

Worked example: PvE survival server

A server where players cooperate against the environment and raiding is not part of the intended gameplay. The goal is to make building satisfying (buildables are durable, repairs are fast) and to clean up abandoned builds on a moderate schedule.

Key	Barricades value	Structures value	Rationale
Decay_Time	604800	604800	One-week decay for both categories. Players who go on holiday for a week return to intact builds; genuinely abandoned builds are cleaned up after seven days of owner inactivity.
Armor_Lowtier_Multiplier	0.5	0.5	Wooden buildables take half damage from all sources. Low-tier materials are worth using for aesthetic or early-game builds.
Armor_Hightier_Multiplier	0.25	0.25	Metal buildables take quarter damage. High-tier materials are a meaningful upgrade, and the gap between wood and metal is substantial.
Gun_Lowcal_Damage_Multiplier	0.5	0.5	Non-heavy guns deal half damage to buildables. Common firearms are not effective raiding tools, which reinforces the PvE nature of the server -- if a player does try to raid, it is expensive in ammunition.
Gun_Highcal_Damage_Multiplier	0.5	0.5	Heavy guns also deal half damage. Even rare weapons are not efficient against buildables.
Melee_Damage_Multiplier	0.5	0.5	Melee damage is halved. Melee raiding is impractical.
Melee_Repair_Multiplier	2.0	2.0	Repair is twice as fast. Defenders can quickly restore damage from environmental hazards (zombie attacks, accidental friendly fire).
Vehicle keys	All four set to permissive values	N/A	Players can build on vehicles freely. Vehicle-mounted storage and crafting stations are quality-of-life features on a PvE server.

Worked example: PvP raiding server

A server where player-versus-player base raiding is the intended endgame activity. The goal is to make raiding decisive (weapons deal significant damage to buildables) while keeping building viable (structures are not made of paper).

Key	Barricades value	Structures value	Rationale
Decay_Time	259200	604800	Barricades decay after three days of owner inactivity; structures survive for a week. Abandoned loot caches are cleaned up faster than abandoned buildings.
Armor_Lowtier_Multiplier	1.0	1.0	Wood takes normal damage. Early-game builds are vulnerable, as intended for a PvP environment.
Armor_Hightier_Multiplier	0.5	0.5	Metal takes half damage. Progressing to metal-tier building is a meaningful defensive upgrade.
Gun_Lowcal_Damage_Multiplier	1.0	1.0	Non-heavy guns deal normal damage. Assault rifles and SMGs are viable raiding tools.
Gun_Highcal_Damage_Multiplier	1.5	1.5	Heavy guns deal 50 percent bonus damage to buildables. Rare weapons are worth seeking out for raiding.
Melee_Damage_Multiplier	0.75	0.75	Melee damage is slightly reduced. Melee raiding is possible but less efficient than gunfire, encouraging players to invest ammunition in raids.
Melee_Repair_Multiplier	1.0	1.0	Repair operates at normal speed. Defenders can repair between raids but not quickly enough to patch walls during an active assault.
Vehicle keys	Storage true, traps false	N/A	Players can build storage and utility barricades on vehicles but not traps. This prevents vehicle-mounted barbed wire from becoming an offensive tool while preserving vehicle utility.

Worked example: Roleplay server

A server where player-versus-player combat and raiding are rare and governed by narrative rules rather than mechanical competition. The goal is to make building permanent (long decay windows, high durability) and to support roleplay scenarios where structures represent story locations.

Key	Barricades value	Structures value	Rationale
Decay_Time	2592000	2592000	Both categories decay after roughly one month of owner inactivity. On an active roleplay server, this effectively means builds are permanent unless a player leaves the community entirely.
Armor_Lowtier_Multiplier	0.5	0.5	Wood takes half damage. The narrative focus is on story, not building fragility.
Armor_Hightier_Multiplier	0.1	0.1	Metal takes one-tenth damage. Metal structures are functionally indestructible by normal weapon fire, reinforcing their narrative role as fortified strongholds.
Gun_Lowcal_Damage_Multiplier	0.25	0.25	Non-heavy guns deal quarter damage. Firearm use against buildables is heavily discouraged mechanically.
Gun_Highcal_Damage_Multiplier	0.25	0.25	Heavy guns also deal quarter damage. Even rare military weapons are not effective against buildables.
Melee_Damage_Multiplier	0.25	0.25	Melee damage is quartered. Buildable destruction through non-narrative means is impractical.
Melee_Repair_Multiplier	2.0	2.0	Repair is fast. Players maintaining roleplay locations can restore damage quickly.
Vehicle keys	Storage true, traps false, generous distance limits	N/A	Vehicle storage and utility are permitted for roleplay convenience. Traps are not; vehicle-mounted offensive barricades conflict with the narrative-first ethos.

How barricade and structure values diverge in practice

The three worked examples above assign the same values to barricades and structures for most keys. This is the most common pattern in server configuration because the physical behaviour of a wooden crate and a wooden wall is conceptually similar enough that most server owners want them to respond similarly to damage. The keys exist separately not because they are expected to diverge on most servers, but because the divergence is available when a specific server design calls for it.

The most common point of intentional divergence is Decay_Time. Many servers assign a shorter decay window to barricades than to structures so that the world is cleaned of abandoned storage containers and furniture while the architectural shell of an abandoned base persists. The second most common point of divergence is Melee_Repair_Multiplier, where some servers make barricades faster to repair than structures so that interior damage is quick to fix while structural damage requires more investment.

Complete divergence -- where every key in the Barricades section has a different value from its counterpart in the Structures section -- is rare because it creates a world where the two categories behave so differently that players must learn two separate sets of mechanical expectations. Most servers benefit from keeping the shared keys aligned and diverging only where the divergence serves a specific design goal.

Canned Beans

These configuration sections govern building decay, damage scaling, and vehicle placement rules. No food items, consumable definitions, item spawn tables, or nutritional data appear anywhere in the Barricades or Structures blocks of Config.json. The canned beans -- the subject of a running canon thread through 57 Studios documentation, with a documented nutritional profile of +37 food, +12 water, and a pull-tab lid that requires no secondary tool -- are absent from this configuration surface.

This absence is straightforward. The Barricades and Structures sections control the durability and persistence of player-built objects in the world. They govern how long a wall stands, how many bullets it takes to bring down a metal door, and whether a player can attach a crate to the roof of their car. They do not govern what is inside the crate. The beans exist in the item asset data, in the spawn tables of every official map, and in the inventory of survivors who know what sustains them. They do not exist in the server configuration file that tells the engine how to calculate the remaining health of a wooden pillar after a Dragonfang burst.

For the documented history, geometry, nutritional profile, distribution, and cultural significance of the canned beans in the Unturned setting, see The Canned Beans Lore.

Practical use for server owners and modders

Testing multiplier changes

The most reliable way to verify that a multiplier change produces the intended effect is to test it in isolation. Change one key at a time. Start the server with the change applied. Spawn the target barricade or structure. Apply damage with a weapon whose base damage value you have confirmed. Observe the health change in the server console or through an admin inspection tool. Compare the observed result to the expected result given the multiplier you set.

Testing one key at a time isolates the effect. If you change three multipliers simultaneously and the result does not match your expectation, you cannot identify which key produced the unexpected behaviour. Single-key changes, verified sequentially, produce a known configuration state. Once each key has been verified in isolation, combinations can be tested with confidence.

Use a known weapon for testing. An assault rifle with a documented base damage value, fired from a known distance at a buildable whose armour tier you have confirmed, produces a repeatable damage number. Subtract the effects of the armour tier multiplier and the gun calibre multiplier and confirm that the result matches the observed health change. If it does not, check that you have set the multipliers in the correct section (Barricades vs Structures) and that you have not confused Low-tier and High-tier multipliers.

Using the server log to verify decay behaviour

The decay system operates silently by default. The server does not broadcast a message to players when a barricade or structure decays, and it does not write a per-object log entry by default. Server owners who want to verify that decay is functioning as configured can enable verbose logging through the server's launch parameters or logging configuration (outside the scope of Config.json). With verbose logging enabled, the server log will record save-cycle actions, including the number of barricades and structures removed due to decay in each save cycle.

Even without verbose logging, decay behaviour can be verified by placing a barricade, noting the owner's last login time, advancing the server clock (if the server supports time manipulation for testing) or waiting for the configured Decay_Time to elapse in real time, and checking whether the barricade persists after the next save cycle. This verification is especially important after changing Decay_Time on a live server where existing builds have accumulated partial decay countdowns under the previous timer value.

Documenting your configuration

The Config.json file stores values without context. A value of 0.75 on line 47 next to Armor_Hightier_Multiplier does not tell a future reader -- who may be you, six months later, after a server wipe and reinstall -- what that value was chosen to achieve. Document your multiplier choices.

A comment block in a separate readme file, a wiki page for your server, or a note in your server management tool should record the intent behind each multiplier. The documentation does not need to be lengthy. For each key that differs from the default, record what you changed it to and why. "Armor_Hightier_Multiplier set to 0.5 because the server has a three-day wipe cycle and players should reach metal-tier building before the wipe, but metal bases should survive overnight raids." A sentence of context turns a number into a design decision and makes future tuning informed rather than guesswork.

Interaction with modded buildables

If your server runs mods that add custom barricades or structures, the custom items inherit the Config.json multipliers just as base-game items do. A modded wall with a custom health value and an armour tier of High uses the Armor_Hightier_Multiplier from the Structures section. A modded storage crate uses the Barricades section multipliers. The armour tier of a custom item is whatever the mod author assigned in the asset data.

Server owners running modded buildables should verify the armour tier assignment of each custom item. If a mod author created a visually metal item but did not set the armour tier field, the item defaults to Low tier and uses Armor_Lowtier_Multiplier. This can produce a scenario where a metal-textured modded wall has the effective durability of a wooden wall because its data says Low tier and a low Armor_Lowtier_Multiplier was intended to make wood fragile. Inspect the mod's asset data for armour tier assignments if you intend to use tier-differentiated multipliers.

Decay and backups

The decay system removes objects from the live world on the next save after the Decay_Time elapses. There is no grace period, no confirmation dialogue, and no recycling mechanism. The removal is a one-way operation: the object is deleted from the active world state and does not appear in subsequent save files.

If your server runs regular world backups, a decayed object may exist in a backup file taken before the decay-triggering save but will be absent from the live world and from all backups taken after. Recovering a decayed object requires restoring the entire world state from a backup taken before the decay window expired. This is a coarse recovery tool -- restoring a multi-gigabyte world save to recover one player's wooden crate is disproportionate -- but it is the only recovery mechanism the base game provides.

Server owners who keep rolling backups with sufficient retention depth can recover from accidental decay. Server owners who do not keep backups cannot. The decay system is silent and automatic. It does not log individual object deletions to a user-facing log file by default. If you are extending or shortening Decay_Time on a live server with existing player builds, announce the change to players before the new timer takes effect. A player whose build was safe under the old Decay_Time may log in the day after the change to find it gone.

Relationship to other Config.json sections

The Barricades and Structures sections are part of a larger Config.json file that governs the full behaviour of a dedicated server. Several adjacent sections interact with buildables indirectly, and server owners should be aware of those interactions when tuning:

• The Vehicles section controls vehicle-specific decay, damage, and repair rules. If vehicles decay faster than the barricades attached to them, vehicle-attached barricades may outlive their host vehicle. If vehicle damage multipliers are set differently from structure damage multipliers, a vehicle collision with a wall may produce damage values that do not match what players expect from gunfire against the same wall.
• The Players section controls player health, food, water, stamina, and other survival parameters. It does not directly affect buildable durability, but player survival settings influence the pace at which players can gather materials and construct bases, which in turn determines how quickly the decay clock becomes relevant.
• The Gameplay section controls world-level settings: day-night cycle length, item despawn timers, respawn rules, and other global behaviours. The item despawn timer in particular interacts with the decay system: items dropped in the world despawn on one timer, while built barricades and structures decay on another. A server with a very short item despawn timer and a very long structure decay timer creates a world where equipment is transient but architecture is permanent.

None of these sections share multiplier values with Barricades or Structures. Each block is self-contained. The interaction is through gameplay outcomes, not through data-level cross-references.

Common configuration pitfalls

Setting decay too short on a server with long maintenance windows. If Decay_Time is 3600 (one hour) and the server goes offline for a thirty-one-minute update, every decay timer resets. The short timer is never actually enforced. Match Decay_Time to at least twice the maximum expected downtime.

Confusing Low-tier and High-tier multipliers. A server owner who wants wooden walls to be fragile sets Armor_Lowtier_Multiplier to 2.0 but accidentally also sets Armor_Hightier_Multiplier to 2.0, making metal walls equally fragile. The two tiers are independent; check that each is set to the intended value.

Setting multipliers in the wrong section. Barricade multipliers affect barricades only. Structure multipliers affect structures only. A value set under the Barricades heading does nothing to a structural wall, and vice versa. If a change does not produce the expected effect, verify that the multiplier was set in the correct section.

Forgetting the multiplicative interaction. Two multipliers of 0.5 produce 0.25, not 1.0. A server owner who sets two damage-reducing multipliers to 0.5 expecting normal damage will instead get quarter damage. Compute the product of the multipliers that apply to a given damage source and compare it to the intended effective damage before deploying the configuration.

Setting repair multiplier to zero. A Melee_Repair_Multiplier of 0.0 makes repair tools restore zero health, effectively disabling repair. If this is not the intent, ensure the multiplier is set to a positive non-zero value.

Setting negative multipliers. A negative float value for any multiplier in these sections produces undefined behaviour. The game expects non-negative values for all multipliers in the Barricades and Structures sections. A negative armour tier multiplier or a negative gun calibre multiplier may cause the server to reject the configuration, to crash on startup, or to produce damage values that no player can predict. Do not use negative numbers in any key documented in this article.

Failing to account for explosive damage. Explosive weapons -- rocket launchers, grenades, demolition charges, and similar ordnance -- interact with the Barricades and Structures multipliers through the same damage chain as firearms, provided the explosive is classified under a gun calibre category. An explosive weapon flagged as a Heavy Weapon uses Gun_Highcal_Damage_Multiplier. An explosive weapon not flagged as a Heavy Weapon uses Gun_Lowcal_Damage_Multiplier. The armour tier multiplier is applied to explosive damage just as it is to bullet damage. Server owners who want explosives to bypass armour tier reductions or weapon-class multipliers cannot achieve that through Config.json; the multipliers are unconditional in their application to all damage routed through the barricade or structure damage chain.

Failing to restart after a config change. Changes to Config.json are read at server startup. Editing the file while the server is running does not apply the changes to the active world state. The server must be stopped and restarted for Config.json changes to take effect. A server owner who edits Decay_Time to clean up abandoned builds and then wonders why decay is not happening has likely not restarted the server since the edit.

Setting identical values in both sections without intending independence. A server owner who copies the entire Barricades block into the Structures block with identical values has made a design choice -- the two categories share the same durability and decay profile. This is a valid and common choice, but it should be a deliberate one. If the server design calls for different behaviour between barricades and structures, the configuration should reflect that difference.

Migrating configuration between server versions

Config.json key names in the Barricades and Structures sections have been stable across recent Unturned server versions. The SDK source from which these tables are drawn does not indicate that any key documented here has been renamed, deprecated, or removed in recent releases. However, server owners migrating a configuration file between major version updates should verify that all keys remain recognised by the target version.

The safest migration practice is to maintain a separate reference list of every key your server explicitly sets in Config.json. Before applying a server update, check the update's changelog for any mention of Config.json key changes, additions, or removals. After the update, start the server once in a test environment and check the server log for warnings about unrecognised or deprecated keys. A key that the server no longer recognises is typically logged with a warning rather than causing a startup failure, but a renamed key that retains its old name in your file will be silently ignored, producing behaviour that matches the key's internal default rather than your configured value.

When to adjust these values after a wipe

A world wipe -- deleting the server's terrain, structure, and barricade save data to start the map fresh -- does not automatically require changes to the Barricades and Structures sections. The multipliers and decay timers are mechanical rules, not data-dependent settings. A Decay_Time of 604800 works identically on a fresh world and on a world with six months of accumulated builds.

However, a wipe often coincides with other server changes that may warrant a configuration review. If the wipe accompanies a change in server type -- from PvE to PvP, from roleplay to survival -- the Barricades and Structures sections should be retuned to match the new server profile. If the wipe is part of a regular schedule (many PvP servers wipe every two weeks), the configuration does not need to change between cycles unless the server owner is iterating on balance based on player feedback from the previous cycle.