Config.json Gameplay Section Reference
The Gameplay section of Config.json is where a server owner defines the rules that govern how Unturned feels to play on their server. It controls whether bullets drop over distance, how long a player waits to respawn, whether groups can see each other through walls, and how much recoil a third-person shooter experiences. If you are searching for "Config.json gameplay," "Unturned server gameplay settings," or "how to configure an Unturned dedicated server," this article is a complete field-by-field reference for all 47 keys in the Gameplay section.
This article is structured for both reading-through and looking-up. It opens with an explanation of what Config.json is and where to find it, then presents the full verified key table, followed by detailed explanations organized into six functional groups: combat and ballistics, HUD and UI, building and repair, group systems, timer settings, and world behaviour. Each key is explained in plain language for a server owner editing this file for the first time. No key described here is drawn from community consensus, forum discussions, or testing. Every value comes from the Unturned SDK source code, specifically the GameplayConfigData class in PlayConfigData.cs.
What Config.json Is and Where It Lives
Config.json is the primary configuration file for an Unturned dedicated server. It is a JSON document that the server reads once at startup and never again during the server's uptime. Every section within it controls a different subsystem of the server, and the Gameplay section is the largest of these. When a player connects to your server, the values set in Config.json determine what they see on their HUD, how their weapons behave, what they are allowed to build, how groups function, and how long they wait between death and respawn.
Each server instance keeps its own copy. The file lives at Servers/<ServerID>/Server/Config.json, relative to the Unturned installation directory, where <ServerID> is the instance name the server was launched with. It sits in the same Server folder as Commands.dat.
Do not confuse it with Config.txt, which is a different file at a different level: Servers/<ServerID>/Config.txt, one directory above the Server folder. Editing the wrong one is a common way to change a setting and then see no effect.
If you use a hosting panel, the panel may surface these files through its own file browser rather than at these literal paths, but the names and their positions relative to each other are the same.
Config.json is a strict JSON file. Keys are case-sensitive and values are typed, so a single missing comma or stray brace makes the whole file unparseable. When the game cannot parse a Config.json it reports the failure and recommends checking the file with a JSON linter, so a syntax error shows up as a startup complaint rather than as a silently ignored setting. Copy the file before editing so you can revert, and run a JSON validator over your edit before restarting.
The Gameplay section appears as a top-level object in the JSON root, typically under a key named Gameplay. Every key documented below lives inside that object. A minimal Config.json with only the Gameplay section and a single key looks like this:
json
{
"Gameplay": {
"Ballistics": true
}
}Keys omitted from the Gameplay block run on the server's internal defaults -- the same behaviour as if the key were not written at all. A key written with an explicit value overrides the internal default. This is true of every key in the section. If your Config.json does not have a Gameplay block, the server uses its internal defaults for every key described on this page. If your Config.json has a Gameplay block but omits some keys, those omitted keys also run on internal defaults.
Key Index
The table below lists all 47 keys in the Gameplay section, along with their C# types and the default values pulled from the game's SDK source. A dash (-) in the Default column means the game supplies an internal default that is not declared in the SDK; setting the key explicitly in Config.json overrides that internal value. Use this table as a lookup when you need to find a key by name.
| Key | Type | Default |
|---|---|---|
Repair_Level_Max | uint | - |
Hitmarkers | bool | - |
Crosshair | bool | - |
Ballistics | bool | - |
Chart | bool | - |
Satellite | bool | - |
Compass | bool | - |
Group_Map | bool | - |
Group_HUD | bool | - |
Group_Player_List | bool | - |
Allow_Static_Groups | bool | - |
Allow_Dynamic_Groups | bool | - |
Allow_Lobby_Groups | bool | - |
Allow_Shoulder_Camera | bool | - |
Can_Suicide | bool | - |
Friendly_Fire | bool | - |
Bypass_Buildable_Mobility | bool | - |
Bypass_No_Building_Zones | bool | - |
Bypass_Building_In_Safezones | bool | - |
Allow_Holidays | bool | true |
Allow_Freeform_Buildables | bool | - |
Allow_Freeform_Buildables_On_Vehicles | bool | - |
Enable_Damage_Flinch | bool | - |
Enable_Explosion_Camera_Shake | bool | - |
Enable_Workstation_Requirements | bool | - |
Disable_Motion_Sickness_Options | bool | - |
Disable_Foliage_Off | bool | - |
Use_2D_Scope_Overlay | bool | - |
Enable_Fishing_Catch_Challenge | bool | - |
Timer_Exit | uint | - |
Timer_Respawn | uint | - |
Timer_Home | uint | - |
Timer_Leave_Group | uint | - |
Max_Group_Members | uint | - |
Explosion_Launch_Speed_Multiplier | float | 1.0f |
AirStrafing_Acceleration_Multiplier | float | 1.0f |
AirStrafing_Deceleration_Multiplier | float | 1.0f |
FirstPerson_RecoilMultiplier | float | 1.0f |
FirstPerson_AimingRecoilMultiplier | float | 1.0f |
FirstPerson_AimingZoomRecoilReduction | float | 0.0f |
ThirdPerson_RecoilMultiplier | float | 2.0f |
ThirdPerson_SpreadMultiplier | float | 2.0f |
Viewmodel_AimingJumpLandMultiplier | float | 1.0f |
Viewmodel_AimingMisalignmentMultiplier | float | 1.0f |
Min_Fishing_Bite_Interval | float | - |
Max_Fishing_Bite_Interval | float | - |
Fishing_MaxStrength_Bite_Interval_Multiplier | float | 0.3f |
Combat and Ballistics
The combat and ballistics group is the largest section. It controls how weapons fire, how the camera behaves during combat, how movement in the air works, and how the server handles player-versus-player damage. These are the keys that most directly shape the moment-to-moment feel of your server. For a server owner, this group answers the question: "what does it feel like to be in a fight here?"
Weapon Recoil
Five recoil keys and two spread keys govern how much your screen kicks when you fire and how accurate your shots are. Each is a multiplier: a value of 1.0 means the base recoil or spread is unchanged, 0.5 halves it, 2.0 doubles it, and 0.0 removes it entirely. The base values that these multipliers scale come from the weapon asset files themselves, not from Config.json. That means two servers with the same recoil multiplier can still feel different if they load different weapon mods.
FirstPerson_RecoilMultiplier scales the recoil magnitude when the player is in first-person view. At its default of 1.0f, recoil behaves as the weapon asset files define it -- the gun kicks by its asset-defined amount every shot. Setting this lower makes first-person guns easier to control. Setting it higher increases the kick. A value of 0.5f halves the recoil of every weapon in first-person. A value of 0.0f removes first-person recoil entirely, which effectively turns every gun into a laser at the cost of removing the primary skill gate for sustained fire.
FirstPerson_AimingRecoilMultiplier is the same scaling factor, but only while the player is aiming down sights in first-person. Because the default is 1.0f, aimed recoil and hipfire recoil have the same magnitude by default -- aiming does not reduce kick on its own. A common server configuration is to set this lower than the hipfire multiplier, so that aiming feels noticeably steadier. For example, a server with FirstPerson_RecoilMultiplier = 1.0 and FirstPerson_AimingRecoilMultiplier = 0.5 makes aimed fire half as bouncy as hipfire, which rewards the player who takes the time to sight in.
FirstPerson_AimingZoomRecoilReduction adjusts recoil inversely with the magnification level of the scope the player is using. The default is 0.0f, which disables this effect entirely -- a 2x scope and an 8x scope have identical recoil at the same fire rate. Setting it to a positive value makes higher-magnification scopes reduce recoil more than lower-magnification scopes, proportional to their zoom level. A high-powered sniper scope, under a positive value, would provide greater recoil stabilization than a red dot sight. This is independent of the flat aiming multiplier above; both can apply simultaneously.
ThirdPerson_RecoilMultiplier controls recoil when the player is in third-person view. Its default of 2.0f means third-person shooting inherently has twice the recoil of first-person shooting, before any other multipliers apply. This is the game's built-in trade-off: the wider situational awareness of third-person view -- the ability to see around corners, over walls, and behind you without exposing your character -- comes at the cost of greater weapon kick. Setting this to 1.0f removes the penalty and makes third-person recoil identical to first-person.
ThirdPerson_SpreadMultiplier scales bullet inaccuracy -- the random deviation from where the crosshair points -- while in third-person. The default of 2.0f doubles the spread compared to its base value, making third-person shots less precise than first-person shots. Spread is distinct from recoil: recoil moves the crosshair itself, while spread adds random offset to each individual shot even if the crosshair is perfectly on target. A player who fires in third-person at 2.0f spread multiplier will have their bullets land farther from the crosshair center, on average, than a player who fires the same weapon in first-person.
How the Recoil and Spread Keys Interact
The five recoil keys and two spread keys apply multiplicatively with each other and with the weapon's base values from the asset files. Understanding the multiplication chain is important because setting multiple keys to non-default values produces compounded effects that may be stronger or weaker than a server owner expects from each individual key.
A third-person shot on a server with ThirdPerson_RecoilMultiplier = 2.0 and FirstPerson_RecoilMultiplier = 1.0 has twice the recoil of a first-person shot from the same weapon. The first-person values and third-person values are independent channels: changing first-person recoil does not affect third-person recoil, and changing third-person recoil does not affect first-person recoil. A server owner who wants to adjust recoil for one perspective only changes the key for that perspective.
Within first-person, the recoil multipliers stack multiplicatively. The FirstPerson_RecoilMultiplier sets the base first-person recoil. The FirstPerson_AimingRecoilMultiplier applies on top of that whenever the player is aiming down sights. If a server sets hipfire recoil to 1.0 and aimed recoil to 0.5, aimed recoil becomes 50% of hipfire recoil for every weapon. If the server also sets FirstPerson_AimingZoomRecoilReduction to a positive value, the scope's zoom level further reduces the already-halved aimed recoil by a factor proportional to the magnification. A player using an 8x scope on a weapon with recoil already halved by the aiming multiplier would see that halved recoil further reduced by the scope's zoom factor, producing a compound reduction that could approach or reach zero recoil at high enough zoom.
The spread keys work independently of the recoil keys. ThirdPerson_SpreadMultiplier increases the random inaccuracy of each shot in third-person without affecting recoil. A server with high third-person recoil and high third-person spread creates a perspective where both the crosshair jumps significantly (recoil) and individual shots deviate from the crosshair position (spread), making sustained fire from third-person extremely difficult to control.
A server owner who wants identical gunplay across both perspectives sets all five recoil keys and both spread keys to 1.0. A server owner who wants to strongly incentivize first-person aiming -- creating a deliberate gap between the two perspectives -- sets hipfire recoil high, aimed recoil low, third-person recoil very high, and third-person spread very high. The distance between the best-case (first-person aimed, low-recoil scope) and worst-case (third-person hipfire) can span an order of magnitude difference in effective recoil.
Viewmodel Motion
Two keys control how much the first-person weapon model moves around the screen during specific actions. Both accept values in the range 0 to 1, as declared in the SDK source. Values outside this range may produce unintended visual results because the game clamps or misinterprets out-of-bounds inputs. The viewmodel is the rendered weapon and arms that the player sees in first-person -- it is a client-side visual effect, separate from the actual weapon mechanics, which are server-authoritative.
Viewmodel_AimingJumpLandMultiplier scales the vertical bouncing of the viewmodel when the player jumps or lands while aiming down sights. At 1.0f, the full animation plays -- the weapon model rises in view as the character leaves the ground and drops back down on landing, producing a pronounced visual kick that corresponds to the character's vertical movement. The animation gives physical feedback: the player can feel the jump in their view, which makes the first-person camera feel connected to the character's body.
At 0.0f, the viewmodel stays completely locked in place during jumps and landings while aiming. The character still jumps in the game world -- other players see them leave the ground -- but the first-person weapon view shows no vertical displacement. The viewmodel behaves as if mounted on a stabilized mount, which removes a source of visual disruption during combat but also removes the physical feedback that tells the player they are airborne. At intermediate values like 0.3f or 0.5f, the bounce is reduced but still present, giving a subtle sense of weight without being disorienting.
This key only affects the viewmodel during aimed fire. Jumps and landings from the hip use their own animation curves that this multiplier does not touch. A server owner who wants to reduce ADS combat clutter without removing the sense of physicality from the game entirely might set this to 0.3f or 0.5f, keeping enough motion for feedback without disrupting target tracking during jump-shots.
Viewmodel_AimingMisalignmentMultiplier scales how much the first-person arms and weapon shift out of alignment while the player is aiming down sights and moving. At 1.0f, the full misalignment animation plays -- the weapon sways and drifts off the center of the screen as the player walks, strafes, or changes direction. The weapon might tilt slightly to one side, the arms might bob independently of the crosshair, and the viewmodel generally feels heavy and physical. This animation is designed to convey the effort of holding a weapon steady while in motion.
At 0.0f, the weapon stays perfectly centered on the crosshair while the player walks and aims. The crosshair and the viewmodel are locked together, and the weapon behaves as if mounted on a gimbal that cancels all motion-induced drift. This makes aimed movement feel precise and arcade-like, with no visual penalty for shooting while strafing.
This key differs from recoil in an important way: it does not relate to firing at all. It controls only the idle movement of the weapon model during locomotion while aiming. A player can walk with a perfectly stable scope picture at 0.0f and still experience full recoil when they pull the trigger. The two systems are independent. A server that reduces misalignment to zero while keeping recoil at 1.0f makes aimed movement accurate but aimed fire bouncy, creating a dynamic where players are encouraged to move and stop to shoot rather than moving and shooting simultaneously.
Camera and Feedback
Allow_Shoulder_Camera determines the third-person camera position. When true, the third-person camera offsets to the side of the character's shoulder, giving the over-the-shoulder view common in third-person shooters. The player character sits to one side of the screen (typically the left side for a right-handed shooter), and the camera looks past the character's shoulder at the environment. The crosshair sits near the center of the screen, and the character model occupies roughly the bottom-left quadrant.
When false, the third-person camera centers directly behind the character. The character's body sits in the middle of the screen, and the camera looks past the character's head at the direction they are facing. The crosshair remains at the screen center, but the character model now occupies the center-bottom of the view.
The practical difference is in corner peeking and situational awareness. An over-the-shoulder camera (the true setting) allows a player to look around corners without exposing their character model, because the camera casts from the side and can catch angles beyond the character's head position. A player standing behind a wall with the camera offset to the right shoulder can see around the right side of the wall without ever moving their character into the open. A centered camera (the false setting) removes this asymmetry: what the camera sees is what the character's physical position would allow them to see. To look around a corner with a centered camera, the player must physically move the character to an angle that exposes at least part of their hitbox.
Servers that disable the shoulder camera generally do so to prevent third-person corner peeking, which removes the risk of scouting a position. On a server with the shoulder camera enabled, a player can gather visual information from safety. On a server with it disabled, scouting requires exposure. This is a more pronounced balance decision on PvP servers, where the information advantage of safe corner peeking can determine the outcome of an encounter. On PvE servers, shoulder camera positioning is more a matter of player preference and comfort.
Enable_Damage_Flinch controls whether the player's aim kicks away from the center of the screen when they take damage. When true, being shot or damaged causes the crosshair to displace -- the view jerks momentarily, and the player must correct their aim to stay on target. When false, incoming damage does not affect aim at all; a player who is being hit can keep their sights on target without mechanical interruption. This is one of the most significant balance decisions in the entire Gameplay section.
Flinch as a mechanic punishes the player taking damage and rewards the player who lands the first shot. In a fight between two evenly matched opponents, the one who fires first gets the additional advantage of throwing off the other's aim, making it harder for the defender to return accurate fire. Servers that disable flinch remove this advantage; the defender can fire back with full accuracy the moment they identify the threat. Competitive communities often disable flinch because it introduces an asymmetry that is triggered by the first hit -- whoever shoots first wins both the damage trade and the aim-stability trade, which can make fights feel predetermined by reaction speed rather than by sustained aim duels. Casual servers often leave it enabled because it feels more physically grounded and adds weight to every hit.
The flinch mechanic interacts with Can_Suicide in an edge case: on a server with flinch enabled but suicide disabled, a player who is being repeatedly shot and cannot aim back due to chain-flinching also cannot escape through suicide. They are locked into the fight until they either land return fire through the flinch or die. This interaction can make sustained-fire weapons feel disproportionately powerful because their ability to chain flinches can lock a target into aim disruption for the entire engagement duration.
Enable_Explosion_Camera_Shake controls whether the camera shakes when the player is near an explosion. When true, the screen rumbles in proximity to detonations -- grenades, rockets, vehicle explosions, placed charges. The intensity typically scales with the size of the explosion and the player's distance from the epicenter. This effect can also be adjusted by individual players through the client-side Options menu, so even when the server enables it, a player may reduce its intensity locally. Enabling camera shake adds sensory weight to explosions, making them feel impactful beyond the damage number. Disabling it removes a source of visual disruption during explosive-heavy engagements.
Disable_Motion_Sickness_Options is a server-authoritative override. When true, all client-side settings that control motion-related effects -- damage flinch, explosion camera shake, viewmodel bob, and any similar options -- are ignored by the server. The server's values for these effects apply uniformly regardless of what the player has configured in their local options. When false, the player's client-side motion settings are respected, and individual players can reduce or disable these effects for themselves.
This key is designed for servers that want consistent visual behaviour across all clients. In a competitive setting, if one player disables camera shake and another leaves it on, the first player has a slight advantage during explosive combat because their screen stays stable while the second player's screen jumps. Enforcing motion sickness options server-side removes that asymmetry by making every player experience the same visual effects. In a recording or content-creation context, consistent viewmodel behaviour across all footage removes awkward discrepancies between what different players see during the same recorded event.
The trade-off is that players who genuinely need motion-reduction settings for comfort -- those susceptible to motion sickness from viewmodel bob, those who find damage flinch disorienting, or those who experience eye strain from camera shake -- have no local way to adjust their experience. The server's settings are the only settings that apply. Server owners who enable this key should communicate the decision clearly so that players with motion-sensitivity concerns can assess whether the server is comfortable for them before investing time in it.
Projectile Behaviour
Ballistics is the toggle that determines whether bullets in your server are simulated or instant. When true, bullets are affected by gravity and travel time: they arc, drop over distance, and need to be led against moving targets. A player must aim above a distant target to account for drop and ahead of a moving target to account for travel time. When false, bullets are hitscan -- the shot registers instantly at whatever the crosshair is pointed at the moment the trigger is pulled, with no travel arc, no time-of-flight, and no need to lead.
This is one of the most impactful settings in the entire Config.json. A hitscan server feels arcade-like and rewards fast-twitch aim and snap reflexes. A ballistics server feels more deliberate and rewards range estimation, leading, and understanding of each weapon's muzzle velocity. Most servers that describe themselves as "vanilla" run ballistics enabled, because ballistics is the standard behaviour in the base single-player and co-op game.
Changing this key changes every firearm on the server. There is no per-weapon ballistics toggle in Config.json; if you want some guns to be hitscan and others to have travel time, that must be configured in the weapon asset files, not in the server configuration.
Hitmarkers controls the hit-confirmation feedback system. When true, a small visual indicator appears at the center of the screen every time the player deals damage to another entity -- a player, a zombie, or an animal. The hitmarker is a universal feedback mechanism: it fires on every damage instance regardless of the weapon type, the range, or the hit zone. When false, no such indicator appears, and the player receives no automatic visual confirmation that their shot connected.
Without hitmarkers, a player must judge their effectiveness from secondary cues: the target's health bar movement (if visible), the target's flinch animation, the target's reaction, or the killfeed. This creates a more uncertain combat environment that rewards players who can assess damage from context. Servers that disable hitmarkers often do so in conjunction with disabling other information sources -- the crosshair, group HUD markers, the compass -- to create a low-information combat experience that relies on player awareness rather than interface signals.
Crosshair controls whether the crosshair reticle is visible while holding a firearm. When true, the standard crosshair appears at the center of the screen when a gun is equipped, providing a constant reference point for where the weapon is pointing. When false, the crosshair is hidden, and the player must rely on iron sights, scopes, the weapon model's natural point of aim, or instincts to place shots.
Disabling the crosshair changes how players approach any firearm engagement. Hipfire becomes unreliable because there is no on-screen indication of where the barrel is aimed. Aiming down sights becomes the default way to shoot because it provides the only visual alignment reference. This is common on servers that emphasize weapon handling realism or that want to discourage hipfire as a primary combat style. It pairs naturally with recoil multipliers that make hipfire less accurate than aimed fire, creating a combined incentive to sight in before shooting.
Movement Physics
Explosion_Launch_Speed_Multiplier scales the velocity that explosions add to players -- the knock-back effect. At the default 1.0f, explosions push players with their base force as defined in each explosive's asset data. Increasing this value sends players flying farther when a grenade, rocket, or charge detonates near them. Setting it to 0.0f removes knock-back entirely, though damage still applies. Values above 1.0f amplify the launch, which can turn modest explosions into significant displacement tools.
This key is independent of explosion damage. An explosion at Explosion_Launch_Speed_Multiplier = 0.0 still deals its full base damage. It simply does not move the player. Conversely, an explosion at Explosion_Launch_Speed_Multiplier = 5.0 launches players across the map even if the damage remains unchanged. Server owners who run custom maps with platforming elements or who want explosions to function as mobility tools often increase this multiplier. Server owners who find knock-back deaths caused by environmental hazards frustrating often reduce or disable it.
AirStrafing_Acceleration_Multiplier scales how quickly a player can change direction while in the air. At 1.0f, midair steering behaves as the base game defines it -- a player who jumps forward and presses left will curve gently, not snap instantly. Lower values make air movement sluggish; once a player jumps, their trajectory is harder to alter, and they commit to the jump arc they launched with. Higher values give players more aerial control, allowing faster midair direction changes, which raises the movement skill ceiling and can make combat feel faster and more acrobatic.
This key is often adjusted alongside AirStrafing_Deceleration_Multiplier. A server with high acceleration and low deceleration creates an environment where players carry momentum and can redirect it freely, rewarding movement-heavy playstyles. A server with low acceleration and high deceleration makes jumps more committal and punishes players who leave the ground without a clear destination.
AirStrafing_Deceleration_Multiplier scales how quickly a player slows down while in the air and moving faster than their maximum walking speed. At 1.0f, the base deceleration applies -- a player who exceeds walk speed in the air gradually returns to normal speed over the course of the jump arc. Lower values mean players carry momentum longer; the speed gained from a sprint-jump or an explosion launch persists through most of the airborne time. Higher values bring players back to walk speed more aggressively after a jump, which reduces the distance that can be covered in a single bound and diminishes the utility of bunny-hopping and other momentum-preservation techniques.
The deceleration multiplier specifically applies only when the player's speed exceeds their maximum walk speed. If the player is airborne and moving at or below walk speed, this multiplier has no effect -- the standard air deceleration is used. This means the key specifically governs situations where the player has built up excess speed, such as from a fast sprint before a jump, an explosion knock-back, or a vehicle dismount at speed. It does not affect basic airborne movement at normal speeds.
Together, the acceleration and deceleration multipliers define the aerial movement style of the server. Servers with both values at 1.0f run the standard movement physics. Servers that tune these values are usually making a deliberate statement about whether they want movement to feel grounded and weighty or floaty and skill-expressive. A server with high acceleration and low deceleration rewards airborne agility: players can redirect freely and carry their speed. A server with low acceleration and high deceleration punishes leaving the ground without a clear plan: jumps are committal and momentum is quickly lost.
Damage Rules
Friendly_Fire determines whether players in the same group can damage each other with weapons, explosives, and vehicles. When true, group members can harm one another; a grenade thrown into a group fight will damage everyone in the blast radius regardless of group affiliation. When false, group members are immune to each other's damage -- bullets, explosives, and vehicle impacts pass through groupmates harmlessly.
This is a foundational server-identity setting. A server with friendly fire disabled allows groups to fight in close quarters without worrying about crossfire. A group can stack tightly in a hallway, fire past each other, and throw grenades into rooms without checking whether a groupmate is inside. This reduces the coordination burden and speeds up combat pacing, but it also removes a layer of tactical depth: on a server with friendly fire enabled, a group must maintain fire discipline, call out throws, and position themselves to avoid hitting each other.
Friendly fire interacts with the group information keys (Group_Map, Group_HUD, Group_Player_List) in an important way. On a server where groupmates can damage each other (friendly fire is true) but cannot see each other's markers through walls (group HUD is false), a player who sees a silhouette behind a doorway has no interface-level way to determine whether it is a groupmate or an enemy. The consequence of shooting a groupmate is real damage. The consequence of not shooting an enemy is a lost engagement. This creates a tension that rewards target identification, communication, and trigger discipline. On a server where groupmates are immune to damage and have wall-hack name tags, no such tension exists; players fire freely and trust the interface to sort out friend from foe.
Can_Suicide controls whether the suicide option appears in the pause menu. When true, a player can open the pause menu and choose the suicide command, which immediately kills their character. This is used for several legitimate purposes: escaping being stuck in map geometry (falling through the world, trapped between objects, wedged in a crevice), joining friends at a different spawn location without walking across the map, or abandoning a situation where continuing to play is not practical (out of ammunition, surrounded, no viable escape route).
When false, the suicide option is removed from the menu. A player who needs to die must find an external cause: fall damage from a height, engaging zombies or hostile animals at low health, stepping into environmental hazards, or -- if the server has friendly fire enabled -- asking another player to kill them. This makes death a consequence of the environment rather than a menu option, which some servers prefer for immersion and pacing reasons.
The most common reason servers disable suicide is to prevent its use as a fast-travel mechanic. On a large map, dying and respawning at a bed can be faster than walking or driving from one end of the map to the other. A player who needs to move from the northern coast to the southern military base can kill themselves and respawn at a bed placed near the base, bypassing the travel time and risk. Disabling suicide forces players who want to change location to actually traverse the distance, exposing themselves to the environment, hazards, and other players along the way. It also prevents "combat suicide" -- a player who realizes they are losing a PvP fight and hits the suicide button to deny the opponent the kill credit and loot drop.
HUD and UI
The HUD and UI group controls what information the player can see at all times, without needing an item in their inventory. Each key here governs a specific overlay, map feature, or interface element. Together, they define how much the player knows about the world, their location, and their group. A server with all HUD keys enabled gives players near-total information. A server with all HUD keys disabled gives players almost nothing beyond what they can see with their own camera. Most servers land somewhere between.
Navigation Tools
Chart gives every player permanent access to a paper map of the level. In the base game, a chart is a physical item that a player must find in the world or craft before they can open a map view. When Chart is true in Config.json, that requirement is bypassed -- every player can open the map at any time, from the moment they spawn, regardless of what is in their inventory. The paper map shows topography and major landmarks but does not include the high-detail satellite view.
The chart is considered a basic survival tool. Finding one in the world is usually not difficult -- charts spawn in civilian locations, houses, and campsites -- but there is still a window at the start of a fresh spawn where a player has no map access. Enabling this key closes that window permanently. When Chart is false, a newly spawned player has no map and must navigate by visual landmarks, road signs, and memory until they locate a chart item.
This is primarily a convenience setting that simplifies navigation. On large or maze-like custom maps where new players would otherwise need to memorize routes or find the chart item before they can orient themselves, enabling the chart eliminates a frustrating early-game gate. On smaller maps where navigation is straightforward and the player can see the entire playable area within a few minutes of walking, the chart is less impactful. Servers that disable it do so because finding the chart item is part of the intended early-game progression: a player who spawns in unfamiliar territory should feel lost until they secure basic navigation tools. The moment of finding a chart in a kitchen drawer is a small but meaningful progression beat that enabling the key erases.
Satellite gives every player permanent access to a GPS-quality satellite map of the level. This is the higher-detail map layer, showing terrain features, roads, building footprints, and often additional markers such as vehicle spawns or loot zones that do not appear on the paper chart. In the base game, a GPS device is a rare item typically found in military loot zones, police stations, or high-tier equipment spawns. It is not something a fresh spawn has.
Enabling Satellite in Config.json is a significant information giveaway that accelerates a player's ability to navigate, plan routes, and identify points of interest from the map alone. A player who joins a server with satellite enabled can open the map immediately and see the full layout of the level -- every road, every building cluster, every bridge and chokepoint -- without ever finding the item that normally gates that knowledge behind exploration and looting.
A server can enable Satellite without enabling Chart, but in practice this is unusual because the satellite view includes everything the chart shows plus the additional detail layer. The chart is the base layer and the satellite is the enhanced overlay. A server that wants players to have a map but not the most detailed version enables Chart and disables Satellite. A server that wants no map at all disables both. A server that wants maximum information enables both, though the satellite alone provides the same effective navigation utility.
Compass gives every player permanent access to the compass heading indicator on their HUD. In the base game, the compass only appears in the HUD when the player carries a compass item in their inventory. When Compass is true, the heading display -- typically a thin bar along the top or edge of the screen showing N, S, E, W and numeric degree markings -- is always visible to every player from the moment they spawn.
This key makes directional callouts reliable across a group. A player who says "enemy north-east" knows that every groupmate can see which direction north-east is without needing to find the compass item first. On a server where Compass is false, callouts depend on whether the receiver has found the item. A player without a compass cannot verify what "north-east" means, and groups fall back to relative callouts: "enemy behind the red truck," "enemy moving toward the water tower," "enemy on my position." Relative callouts are slower to process and require shared map knowledge, while cardinal callouts are instant and unambiguous.
The compass is the smallest and least intrusive of the navigation keys. Unlike the map, it does not reveal terrain or player positions. It simply adds a heading reference to the HUD. For this reason, many servers that disable the chart and satellite still enable the compass, because it improves communication without giving away map knowledge. A server with the compass enabled but the map disabled creates a situation where players can navigate by bearing -- "head 270 degrees from spawn" -- but cannot see the layout of what lies in that direction until they reach it.
These three navigation keys are entirely independent of each other. Every combination from all-off to all-on is a valid and intentional server design. A hardcore survival server might set all three to false, forcing players to find each navigation item before they can orient themselves. A roleplay server with a large custom city might enable all three so that new players can learn the layout without spending hours lost. A PvP server might enable only the compass to support combat callouts while keeping the map gated behind item discovery.
Group Information Display
Three keys control how group members see each other's information across the interface. They do not affect whether groups can form -- that is handled by the group system keys in the next section. They only affect what group members can see once a group exists. These three keys are some of the most frequently adjusted in the Gameplay section because they directly change how groups coordinate and how much information advantage a group has over solo players.
Group_Map controls whether group member locations and related markers are visible on the in-game map. When true, opening the map while in a group shows the positions of every groupmate. Each member appears as a marker at their current location, updating in real time as they move. This is a powerful coordination tool: a group leader can see that one member is approaching the objective, another is holding a defensive position, and a third is still at base gearing up, all from the map interface.
When false, the map shows only the player's own position, and groupmates are invisible on the map. Groups must coordinate through voice or text communication to know each other's locations. A player who goes silent cannot be tracked; a player who gets lost must describe their surroundings and hope a groupmate can talk them back.
Group_HUD controls whether group member names and markers appear through walls, terrain, and other solid objects. When true, a player can see the floating name, health bar, and distance indicator of a groupmate even when that groupmate is on the other side of a building, underground in a tunnel, or on the far side of a hill. This is the most generous information setting in the group system because it removes line-of-sight as a gating factor for knowing where groupmates are.
When false, groupmate name tags appear only when the groupmate is in direct line of sight -- the same visibility rule that applies to enemy players. This forces groups to maintain positional awareness through communication. A player who rounds a corner and disappears from view is no longer tracked by the HUD, and the group must ask where they went.
Group_Player_List controls whether the player list -- typically the scoreboard accessed through the Tab key or equivalent -- shows group affiliations. When true, the player list indicates which players belong to which group, making the server's social structure visible at a glance. When false, the list shows player names only, and group membership is hidden from the public roster.
This key affects how players perceive the server population. With group affiliations visible, a solo player can see that eight of the ten players on the server are in the same group and make decisions accordingly -- they might avoid that group's territory, try to join, or log off if they are looking for a more balanced population. Without group affiliations, the social landscape is opaque, and players must deduce who is working together from in-game observation alone.
These three keys together create a spectrum of group information availability. At one end, a server with all three enabled gives groups near-complete awareness of each other's location, status, and server presence. At the other end, a server with all three disabled creates an environment where groups are mechanically supported -- they prevent friendly fire (if Friendly_Fire is false), they may share building permissions -- but the information disadvantage forces constant communication. The choice is a design decision about how much of the coordination burden the interface should carry.
Scope Rendering
Use_2D_Scope_Overlay switches how scoped aiming renders in first-person when the player uses a dual-render scope. A dual-render scope is a scope asset that renders a separate, magnified viewport inside the scope lens while keeping the surrounding screen at the normal field of view. This is the standard scope rendering technique in Unturned: the weapon model and scope housing stay visible, and the scope lens shows a zoomed-in secondary view of whatever the crosshair is pointed at.
When this key is true, the game changes the rendering approach for dual-render scopes. Instead of painting a magnified viewport inside the scope lens, the game hides the weapon model entirely and replaces the full screen with a static 2D overlay that shows the magnified view. The player sees only the zoomed image with no weapon housing, no scope body, and no peripheral environment at the unmagnified field of view. This is a fallback rendering mode.
The primary use case for this key is compatibility with modded scope assets. Some custom scopes, particularly older ones or those built before the dual-render pipeline stabilized, have a dual-render surface -- the render target inside the scope lens -- that is too small relative to the screen. When a scope's render target does not cover enough screen area, the "magnified" viewport can actually appear smaller than the unmagnified world around it, resulting in a net zoom-out when the player aims in rather than a zoom-in. This is a visual bug that makes the scope worse than useless. Enabling the 2D overlay bypasses the dual-render pipeline entirely for these scopes by replacing the broken render target with a full-screen image, which always displays at the correct magnification.
When false, the game uses the standard dual-render pipeline for all scopes that support it. The weapon model remains on screen, the scope housing surrounds the magnified zone, and the player sees both the zoomed view and their peripheral environment. This is the intended rendering mode for scopes built to the standard dual-render specification and provides the most visually coherent scope experience.
For non-dual-render scopes -- simple zoom overlays, red dot sights with no separate render surface, or iron sights -- this key has no effect because there is no dual-render pipeline to override. The key only affects the behaviour of scopes that use the dual-render technique. Servers that run only standard, well-tested scope assets can leave this key at its internal default. Servers that run a wide variety of modded scopes, some of which may not be built to the current dual-render specification, may need to enable it as a compatibility measure.
Building and Repair
The building group governs where and how players can place structures, what they can build on, and what skill limits apply to item repair. These keys together define the construction rules of your server. A permissive building configuration lets players reshape the map. A restrictive one preserves the map's intended geometry and flow. The choice is between player freedom and map integrity.
Repair Skill Limit
Repair_Level_Max is a uint that sets the highest repair skill level any player on the server can use when crafting a repair blueprint. The repair skill in Unturned governs the ability to restore damaged or broken items: a player invests skill points into their repair skill, and each tier of repair skill unlocks the ability to repair items of that tier. A broken military-grade rifle might require repair skill level 3 to restore. A broken civilian pistol might require repair skill level 1. A high-end crafted item might require repair skill level 4 or 5.
This key does not change how many skill points a player has. It does not reduce their skill level, prevent them from allocating points, or display a lower number on their character sheet. It gates the actual crafting action at the moment the player attempts to use a repair blueprint. When the server receives the craft request, it compares the blueprint's repair skill requirement to this cap. If the requirement exceeds the cap, the craft is denied, and the player receives an error or the blueprint simply does not complete.
The practical consequence is that setting Repair_Level_Max = 2 locks every repair blueprint that requires skill level 3 or above. Blueprints requiring levels 0, 1, and 2 work normally. This creates a tier ceiling: players can repair common and mid-tier items but cannot restore the highest-tier equipment through the repair system. Items above the cap must be used until they break and then discarded, or preserved as long as possible without repair.
The uint type means this key takes a non-negative integer. A value of 0 would block all repair blueprints that require any skill level above zero, functionally disabling the repair system for everything except zero-skill repairs (if any exist). A value higher than any blueprint in the game's data would make the cap irrelevant and allow all repairs. If the internal default -- the - in the table -- already allows unrestricted repair, explicitly setting a high number produces the same behaviour but makes the intention visible. The key has no per-item exceptions, no per-player overrides, and no tiered bypass mechanics. It is a single number that applies uniformly to every repair attempt on the server.
Building Zone Overrides
Three bypass keys allow the server owner to override the map's built-in building restrictions. These are override keys, not enable keys: the map defines the zones, and Config.json decides whether to respect or ignore those definitions.
Bypass_No_Building_Zones is a map-wide override for designated no-building zones. Map authors can mark specific regions of a map where building is prohibited, usually to protect navigation routes, spawn points, roadways, bridges, or structural map geometry from being obstructed by player-placed structures. These zones are defined in the map file, not in Config.json. The map author decides where no-building zones exist. Config.json decides whether the server respects them.
When this key is false (the more restrictive behaviour, which is typical for the internal default), the server enforces every no-building zone defined by the map. A player who tries to place a buildable inside one of these zones receives a placement-denied message or the placement ghost turns red and refuses to snap. When this key is true, every no-building zone on the map is ignored: players can place structures anywhere on the map, including inside areas the map author explicitly intended to keep clear.
Enabling this key gives players maximum construction freedom. It also opens the possibility of map griefing -- a player can wall off a critical chokepoint like the only bridge into a city, block a spawn exit with barricades, or seal a tunnel that connects two halves of the map. Because Config.json has no per-zone or per-area controls, enabling the bypass applies to every no-building zone on the entire map. There is no way to allow building in some no-build zones but not others through Config.json alone. Servers that enable this key should have active moderation -- staff members who can manually remove obstructive structures -- or should operate in a community where structural griefing is not a behavioural concern.
Map authors place no-building zones for specific reasons. A no-building zone around a spawn point prevents a player from walling in new spawns and trapping them before they can move. A no-building zone along a main road prevents vehicle blockades. A no-building zone around a quest NPC prevents the NPC from being walled off and made inaccessible. Bypassing these zones means accepting that the protections they provide are gone, and the server owner becomes responsible for maintaining map traversal fairness through other means.
Bypass_Building_In_Safezones is the safezone equivalent of the no-building-zone bypass. Safezones are regions of a map where players cannot take damage from any source -- weapons, explosives, environmental hazards, fall damage, or zombie attacks. They are typically placed in town centers, trader hubs, spawn areas, or quest-giver locations where the map designer wants to guarantee a non-combat space. Building inside safezones is normally restricted by the map because structures placed inside a safezone inherit the zone's damage immunity: a wall, a door, or a full base built inside a safezone cannot be destroyed through normal gameplay. Nothing a player can do -- no weapon, no explosive, no vehicle impact -- will damage a structure protected by the damage-immunity aura. The only entity that can remove a structure inside a safezone is a server administrator with elevated permissions.
When this key is false, the server enforces the map's safezone building restriction and players cannot place any buildable inside any safezone. When this key is true, building inside safezones is permitted, and any structure placed there inherits permanent damage immunity. Server owners who enable this should understand that they are creating an indestructible-structure path: a player or group that builds inside a safezone has an unraidable base that no other player can touch through normal means.
This key is more dangerous than Bypass_No_Building_Zones because no-building zones prevent placement but do not confer damage immunity. A structure placed in a formerly no-build zone after that bypass is still destructible through normal combat. A structure placed in a safezone after this bypass is not. The two bypasses have fundamentally different risk profiles and should be considered separately rather than enabled together as a "building freedom" package.
Bypass_Buildable_Mobility controls whether two specific buildable types -- sentry guns and beds -- can be placed on vehicles. In the standard game, these items require a static ground surface: a sentry gun must be placed on terrain or a floor, and a bed must be placed inside a structure on solid ground. Both buildables are restricted from vehicle surfaces by default. When this key is true, that restriction is lifted and both sentry guns and beds can be mounted on any vehicle that accepts buildable placement.
A sentry gun on a vehicle creates a mobile automated turret platform. A player can drive a truck with a sentry gun positioned in the bed or on the roof, park the vehicle overlooking an objective, and the sentry will autonomously engage targets in its field of fire. The sentry is protected by the vehicle's hitbox and can be repositioned by simply driving to a new location. In combat, a mobile sentry changes the geometry of a fight: the attacking team can bring automated fire support with them rather than being limited to static placements around a base.
A bed on a vehicle creates a mobile respawn point. A player or group can place a bed inside a helicopter, on a boat, or in the back of a van, and then respawn at that bed when they die. The bed moves with the vehicle, so the respawn point is wherever the vehicle currently is. A group that brings a bed-equipped helicopter to a raid can have dead members respawn directly into the helicopter, rearm from its storage, and rappel back into the fight within seconds. This is one of the most powerful tactical adjustments in the game and is why many servers disable Bypass_Buildable_Mobility -- the mobile spawn mechanic fundamentally changes how base raids and territory battles play out.
The key specifically lists sentry guns and beds as the affected buildables. Not every buildable type is affected, and the key does not create a general "all buildables on vehicles" permission. Other structures -- walls, foundations, doors, storage containers -- are not affected by this key. They either have their own vehicle placement rules or are restricted from vehicles through other mechanics. This is a targeted bypass for two specific buildable types that the game considers high-impact when mobilized.
Freeform Building
Freeform barricades are individual structural pieces -- wall segments, barriers, ramps, platforms -- that players place one at a time as free-standing objects rather than as part of a larger structure that snaps to a grid. They are the smallest and most granular unit of building in the game. Unlike the snap-together building system (where a wall automatically aligns with a foundation and a doorway snaps into a wall opening), freeform pieces can be placed at any angle, at any position, on any surface they are allowed to occupy. This gives players the ability to create shapes and structures that the grid system cannot produce.
Allow_Freeform_Buildables toggles whether freeform barricades can be placed anywhere in the world -- on the ground, on terrain, on existing buildings, on rocks, on any surface that accepts building placement. When true, the freeform placement system is available and players can place individual structural pieces in the world. When false, the entire freeform mechanic is disabled: the placement interface does not appear, the buildables do not show as placeable, and players are restricted to the standard snap-together building system exclusively.
Servers that disable freeform building typically do so for three reasons. First, moderation complexity: a single player with malicious intent can scatter hundreds of individual freeform pieces across the map in a short time, and each piece must be removed individually -- there is no bulk-removal tool for freeform barricades in the base game, and each piece generates its own log entry, making cleanup tedious. Second, performance: each freeform piece is an independent networked object, and hundreds or thousands of them in a concentrated area can degrade server and client performance more than an equivalent number of pieces in a single snap-together structure would. Third, visual consistency: random individual wall segments scattered across the landscape degrade the map's visual presentation in a way that snap-together structures, which tend to be concentrated in base locations, do not.
Servers that keep freeform building enabled value the creative flexibility it provides. A freeform piece can bridge a gap between two snap-together structures that do not align. It can create a custom ramp angle, a barricade shape, or a cover position that the grid system cannot produce. For players who build elaborate structures, freeform pieces are often the finishing layer that turns a functional base into a designed space.
Allow_Freeform_Buildables_On_Vehicles is the vehicle-specific counterpart to the main freeform toggle. When true, freeform barricades can be placed on vehicle surfaces -- the flatbed of a truck, the roof of a van, the deck of a boat, the cargo bay of a helicopter, or any other vehicle surface that the game recognizes as a valid placement target. When false, freeform barricades are restricted to ground, terrain, and static building surfaces; vehicles cannot receive freeform placements.
This key is logically dependent on Allow_Freeform_Buildables. Both keys must be true for vehicle-mounted freeform barricades to be placeable. If Allow_Freeform_Buildables is false, then Allow_Freeform_Buildables_On_Vehicles has no effect regardless of its value, because the parent freeform system that would process the placement is already disabled. The server owner must enable the general system before the vehicle-specific override can take effect.
Vehicle-mounted freeform barricades enable a range of creative applications that change how vehicles function in the game. A group can armour a truck by placing metal wall segments along its bed, creating a shielded mobile firing platform. A solo player can place a ramp piece on the back of a boat to create a vehicle-launching ramp that travels with the boat. These applications are possible because freeform pieces placed on a vehicle move with the vehicle -- the pieces become part of the vehicle's physics object. Some servers encourage this as a creative building mechanic. Others restrict it because armoured vehicles can dominate combat or because the physics interactions between freeform pieces and vehicle collision meshes can produce unintended behaviour.
Crafting Requirements
Enable_Workstation_Requirements controls how the game validates the environmental requirements for crafting blueprints. When true, a crafting blueprint can specify that a particular workstation object must be within a certain range of the player before the recipe can be crafted. A blueprint for a forged metal plate, for example, might require a forge to be nearby. A blueprint for advanced ammunition might require a chemistry station. A blueprint for vehicle repairs might require a workbench. The specific workstation type and required range are defined in each blueprint's asset data, not in Config.json; Config.json only controls whether the validation step runs at all.
When false, the workstation validation step is skipped. No blueprint anywhere on the server will check for a nearby workstation. Instead, the only environmental check that remains active is the legacy "Heat Source" tag -- a requirement that originates from the cooking system in earlier versions of the game. A Heat Source is a nearby campfire, furnace, barbecue, or any object tagged with the heat-source property. If a blueprint requires a Heat Source, that check still runs. If a blueprint requires a workstation, that check is ignored entirely.
The practical effect of disabling this key is that every workstation-gated recipe becomes craftable anywhere, as long as the player has the required materials in their inventory. A recipe that the map author balanced around requiring the player to first build a base, construct a forge, and power it becomes craftable in the middle of a field. This can shortcut significant portions of the intended progression path.
This key functions identically to the cooking skill's heat-source behaviour from earlier versions of the game. In those versions, certain cooking recipes required a campfire or similar heat source nearby. The workstation system extended that concept to all crafts, not just cooking. Disabling Enable_Workstation_Requirements reverts the system to its earlier, simpler state where only the Heat Source tag gates crafting.
Servers that run a full suite of mods with workstation-gated progression -- tech trees where a forge unlocks tier 2 recipes, a chemistry station unlocks tier 3, and so on -- should leave this key enabled. Disabling it would collapse the progression ladder. Servers that run minimal mod setups or that do not use workstation gating as a design element can disable it without meaningful impact. If you are unsure whether your server's mods depend on workstation requirements, leave the key enabled; disabling it can only remove restrictions, and removing progression gates in a mod that was designed around them rarely improves the experience.
Group Systems
The group system is the primary social structure in Unturned. It controls who can form teams, how large those teams can be, and how the game handles the transition when a member leaves or is removed. These keys define the mechanical rules of group formation and operation. The social norms of your community layer on top of these mechanics, but the mechanics set the boundaries for what is possible.
Group Types
Unturned supports three distinct types of groups, each with its own enable key in Config.json. A server can run any combination of these three -- all enabled, all disabled, or any mix.
Allow_Static_Groups enables Steam clan and group integration as an in-game grouping mechanism. When true, players who are members of the same Steam group are automatically recognized as an in-game group when they join the server. This type of group is called "static" because it is bound to the player's Steam identity rather than to server-specific state or in-game commands. A static group exists because the Steam group exists, and it automatically applies to every server that has this key enabled.
Static groups have several characteristics that distinguish them from dynamic groups. They persist across servers: a group of friends in the same Steam clan will be grouped together on every server they join that has Allow_Static_Groups enabled, without ever issuing a single in-game command. This makes them exceptionally convenient for communities that run multiple servers or that play across different maps. They do not support in-game invitation or roster management because the roster is defined by Steam group membership: a player joins or leaves the in-game group by joining or leaving the underlying Steam group, which is a Steam-level operation. And they are not affected by the dynamic-group management keys -- Timer_Leave_Group, Max_Group_Members, and similar dynamic-group settings do not apply to static groups because the group membership logic is handled by Steam, not by the in-game group system.
Static groups are the lowest-friction grouping mechanism available because they require zero in-game setup. When two friends who belong to the same Steam group join the same server, they are immediately grouped, with all the information and protection benefits that the server's group settings provide. The server owner cannot control static group size, composition, or member behaviour through Config.json; those are all Steam-level properties. The only Config.json lever is whether the integration is enabled at all.
Allow_Dynamic_Groups enables the in-game group creation and invitation system. When true, a player can open the group interface, create a new dynamic group, send invitations to other players currently connected to the server, accept incoming invitations, and manage the group's roster -- promoting members to leader, demoting leaders, and kicking members. The entire in-game group management system is gated on this single key.
Dynamic groups are server-specific. A group created on one server does not carry over to another. When the last member of a dynamic group disconnects from the server, the group dissolves -- it does not persist in any server state or database. This makes dynamic groups well-suited to the open-server model where player populations change from session to session: a player joins, plays for a while, meets other players, and forms or joins a group through the invite interface. When the session ends, the group ends with it. No cleanup, no lingering state.
Dynamic groups are the most flexible grouping type because they support in-game management commands. A group leader can kick a member who is not cooperating. A member can voluntarily leave and join a different group. The group can grow or shrink as players come and go. This flexibility is also why dynamic groups are gated by the management keys that static groups ignore: Max_Group_Members limits the roster size, and Timer_Leave_Group inserts a delay before a departure takes effect. These controls exist specifically because the dynamic system is player-managed and needs guardrails that static groups, managed through Steam, do not.
Most public servers enable dynamic groups because they are the only grouping mechanism available to players who are not in the same Steam group. A solo player joining a server for the first time cannot benefit from static groups -- they may not belong to the same Steam group as anyone else on the server -- but they can receive an invitation to a dynamic group from another player and immediately gain the coordination and protection benefits. Disabling dynamic groups while enabling static groups creates a server where only pre-existing Steam-group friends can group together, which can feel exclusionary to new players.
Allow_Lobby_Groups converts a Steam lobby into an in-game dynamic group automatically when the lobby members join the server. A Steam lobby is the party system used when friends launch Unturned together from the Steam friends list or from a Steam group chat invitation. The lobby persists through the game launch and into the server connection. When all lobby members have joined the server, if this key is true (and Allow_Dynamic_Groups is also true), the game automatically creates a dynamic group containing every member of the lobby, without any manual invitation step.
The dependency on Allow_Dynamic_Groups is hard: if dynamic groups are disabled server-wide, lobby groups cannot form regardless of this key's value. The lobby group is a convenience wrapper around the dynamic group system, not a separate grouping mechanism. It automates the group creation step that the lobby members would otherwise need to perform manually -- one member creating a group, inviting every other lobby member, and each member accepting the invitation. The lobby group shortcut collapses that process into zero actions.
The intended use case is friends who launch the game as a group and want to stay grouped without the administrative friction of invites. If they arrive on the server as a lobby, the game handles the group creation transparently. From the player's perspective, they joined together and are grouped together with no additional interface interaction. The group functions as a normal dynamic group thereafter: it supports in-game management, it respects Max_Group_Members and Timer_Leave_Group, and it dissolves when the last member disconnects.
A server can mix these types freely. A PvE cooperative server might enable all three, giving players the option to group through their Steam clan, through the in-game invite system, or automatically from a lobby. A hardcore PvP server might disable all three entirely, forcing players to identify friends and enemies by sight, coordination, and trust rather than by interface markers and damage immunity.
Group Size
Max_Group_Members is a uint that sets the upper limit on how many players can be invited into a single dynamic group. When the group reaches this number of members, the invitation system prevents any further invitations from being sent. Existing members are not removed, and the limit does not shrink the group retroactively; it only gates new invitations.
This key depends on Allow_Dynamic_Groups being enabled. If dynamic groups are entirely disabled, this key has no group system to apply to. Static groups are not affected by this limit because their roster is derived from Steam group membership, not from in-game invitations. Similarly, lobby groups created through Allow_Lobby_Groups are subject to this limit at creation time: if a Steam lobby has more members than this limit, the automatic group creation that Allow_Lobby_Groups would trigger is blocked or only the first N members are grouped.
The group size limit is a social and balance lever. A low limit of 2 or 3 forces teams to stay small, which increases the total number of independent groups on the server and prevents any single large group from dominating the player population through sheer numbers. This structure suits competitive environments, battle-royale-style game modes, and any server where large-team dominance is undesirable. A high limit or no practical limit (setting the value higher than the server's maximum player count) allows the formation of large factions, which suits roleplay servers with defined faction structures, cooperative survival communities where everyone works together, or servers built around large-scale base construction where more hands produce faster results.
The limit counts only dynamic group members. If a server also has Allow_Static_Groups enabled, a Steam clan with twenty members can all join the server as a static group regardless of what this key is set to, because static groups are not gated by the dynamic group limit. The two group types coexist under different rules: dynamic groups are capped, static groups are not. A server that wants to cap all group sizes must disable static groups entirely and rely only on dynamic grouping with this limit enforced.
Leaving a Group
Timer_Leave_Group is a uint measured in seconds that sets the delay between when a player chooses to leave a dynamic group and when they are actually removed from the group. This is a grace-period mechanic designed to prevent sudden, exploitative group departures during combat.
The delay works as follows. A player who is a member of a dynamic group can, at any time, issue the leave command through the group interface. When they do, a timer begins counting down from the value of Timer_Leave_Group. During the countdown, the player is still technically in the group: friendly-fire rules still apply (they cannot damage or be damaged by groupmates if Friendly_Fire is false), group HUD markers still show, and group-building permissions are still active. When the timer reaches zero, the player is removed from the group, and all group-related mechanics -- information, protection, shared access -- cease for them immediately.
The purpose of this delay is tactical. If a group is in the middle of combat and a member decides to leave -- perhaps because the fight is going poorly and they intend to turn on their groupmates the moment friendly-fire protection drops -- the remaining members have Timer_Leave_Group seconds to notice the departure warning and reposition. On many servers, the group interface shows a visual indicator when a member has queued a departure, so the rest of the group can see "Player X leaving in 12 seconds" and react accordingly. Without this delay, a group member could leave instantly and immediately start damaging their former allies with no warning.
This timer applies only to voluntary departures -- a player choosing to leave their own group. If a group leader forcibly removes a member through the kick command, the removal is instant; there is no delay for kicks because the kick action represents the group's consensus decision, not a single player's choice. The timer is also only relevant for dynamic groups. Static groups are tied to Steam membership, and a player cannot voluntarily "leave" a static group without leaving the underlying Steam group, which is a Steam operation outside the game's control.
Setting Timer_Leave_Group to 0 makes group departures instant, as if the key did not exist. Setting it to a moderate value like 10 gives groups a ten-second window to react, which is usually enough to call out the departure and reposition. Setting it to a high value like 30 gives groups a full half-minute to react, but it also means a player who genuinely wants to leave for non-hostile reasons -- switching to a different group, logging off, or reorganizing -- must wait the full duration. The choice is a balance between protecting groups from betrayal and keeping group management responsive.
Timer Settings
The timer group contains delays that gate specific player actions. Every value here is a uint (unsigned integer) measured in seconds. A value of 0 means the action is available instantly with no delay. A positive value inserts a mandatory wait between the triggering event and the action becoming available.
Server Access and Respawn
Timer_Exit sets how many seconds a player must wait after connecting before they can use the pause menu to leave the server. The exit timer starts when the player's character spawns into the world. During the countdown, the "Leave Server" or equivalent option in the pause menu is disabled -- typically greyed out or hidden. Once the timer reaches zero, the option activates and the player can disconnect through the normal menu path.
This key exists to prevent reconnaissance joins, sometimes called "ghost joining." On a competitive or raid-oriented server, a player could connect, open the map to scout enemy base locations and territory, check the player list to see who is online and in which groups, scan the group HUD for player positions, and then immediately disconnect -- all without ever leaving the spawn area or engaging with the world. The information gathered during those few seconds of connection is tactically valuable, and the reconnaissance costs nothing because the player leaves before anyone can react.
An exit timer of fifteen or thirty seconds forces the scout to stay connected for at least that duration. During those seconds, they are visible in the player list. They may appear on other players' HUDs if group tracking is enabled. Their connection and pending departure are logged. And they are exposed to being spotted, attacked, or noticed by server staff. A short timer like five seconds is a minor inconvenience to a determined scout. A longer timer like thirty or sixty seconds makes reconnaissance a real investment of time, during which the scout risks being caught.
The timer only gates the pause-menu exit path. A player can still disconnect by closing the game client, killing the game process through the operating system, or losing network connectivity. The timer is a soft gate, not a hard lock: it deters casual reconnaissance by making it inconvenient, but it does create a technical barrier against a player who alt-tabs and force-quits the process. The assumption is that force-quitting is annoying enough that most players will not do it for routine information gathering, even if they could.
Timer_Respawn sets the delay in seconds between the moment a player dies and the moment the respawn button becomes available for the standard respawn option. During this interval, the player is dead: they can spectate their body, rotate the free camera around their death location, watch other players continue the fight, or simply wait at the death screen. The death screen displays the remaining respawn time, counting down from the timer's value to zero. When the countdown ends, the standard respawn button activates and the player can return to the map at a random spawn point or designated spawn zone.
This is the primary death penalty lever in the Gameplay section. A Timer_Respawn of 0 means instant respawns, and dying carries no time cost beyond the loss of carried items and position. A player who dies in a base raid with a zero-second timer can respawn at the nearest random spawn, sprint back to the fight, and re-engage within seconds. A Timer_Respawn of 30 or more means the dead player is out of action for that duration, during which their groupmates must hold a position short-handed. The respawn timer makes dying meaningful beyond the loss of inventory: it costs time, and time during a fight is the most precious resource.
Longer respawn timers also change how players approach risky behaviour. On a server with a five-second timer, a player might sprint across an open field knowing that even if they are picked off, they will be back in the fight almost immediately. On a server with a sixty-second timer, that same sprint becomes a genuine gamble because death means a full minute of watching from the sideline. The timer shapes risk assessment at every level of play.
Timer_Home sets the delay between death and the option to respawn at a bed or bedroll. The home respawn and the standard respawn are presented as two separate options on the death screen. The standard respawn (gated by Timer_Respawn) places the player at a random spawn point chosen from the map's spawn table. The home respawn (gated by Timer_Home) places the player at the exact location of their bed.
These two timers can be set independently, which creates a range of respawn incentive structures. A server with Timer_Respawn = 15 and Timer_Home = 5 encourages bed-based respawning as the faster route back into play. This incentivizes players to build beds, protect them with walls and traps, and place them in strategically useful locations -- near objectives, loot routes, or group bases. A server with Timer_Respawn = 5 and Timer_Home = 30 makes bed respawning slower than the standard spawn, which discourages players from using beds as continuous reinforcement tools during base defence. In this configuration, a group defending a base cannot have dead members continuously flood back into the fight from beds inside the base; each death removes a defender for thirty seconds.
Setting Timer_Home to 0 makes bed respawns instant, which effectively turns any bed into a teleportation anchor. A group with beds placed in multiple strategic locations can respawn instantly at whichever bed is most useful at the moment, creating a level of mobility that dramatically changes the flow of combat and exploration. Setting it to a high value makes bed respawns a long-term planning commitment rather than a tactical option.
Fishing Intervals
Three keys control the timing of the fishing mechanic. They are all float values, though the game treats them as interval durations in seconds. These keys affect every fishing cast on the server; there is no per-player or per-zone fishing configuration.
Min_Fishing_Bite_Interval is the shortest possible time in seconds before a fish takes the bait after the bobber lands in the water. This is the lower bound of the random range. The game does not use this value directly. Instead, on every cast, the game picks a random duration somewhere between Min_Fishing_Bite_Interval and Max_Fishing_Bite_Interval. The minimum simply sets the floor -- the bite can never happen faster than this value.
Max_Fishing_Bite_Interval is the longest possible time. Together with the minimum, these two values define the random range. On every cast, the game generates a random duration that falls between the minimum and maximum bounds. After that duration elapses from the moment the bobber touches the water, the fish bites. Setting both the minimum and maximum to the same number removes the randomness entirely and makes every cast take exactly that duration before a bite triggers.
The practical effect is that wider ranges create more varied fishing sessions. A range of Min = 3.0 and Max = 20.0 means one cast might produce a bite in three seconds while the next takes twenty, making fishing feel unpredictable. A range of Min = 8.0 and Max = 12.0 keeps fishing tight and consistent, with most bites arriving within a few seconds of each other. The choice is aesthetic -- some servers want fishing to feel like a reliable food source with predictable timing, while others want the variability that makes each cast feel distinct.
Fishing_MaxStrength_Bite_Interval_Multiplier applies a modifier to the rolled bite interval when the player casts their line at full power. The casting mechanic in Unturned involves a power bar: the player holds the cast button and releases it at the desired strength, with longer holds producing longer casts. When the bar reaches its maximum -- full strength -- the game checks this multiplier and applies it to whatever random interval was rolled between the minimum and maximum.
At the default 0.3f, a full-strength cast multiplies the rolled interval by 0.3, reducing it to 30% of the original value. If the game rolls a 10-second interval for a particular cast and the player executed a full-strength cast, the actual wait becomes 3 seconds. This is the game's reward for casting skill: a player who consistently lands full-strength casts catches fish in roughly a third of the time that a player who casts at half strength or less spends waiting.
Setting this multiplier to 1.0f removes the full-strength benefit entirely: the rolled interval applies unchanged regardless of cast strength. A weak cast and a perfect cast produce the same wait time. Setting it above 1.0f inverts the incentive: a perfect cast takes longer than a weak one, which would punish skilled casting. The multiplier exists as a reward mechanism, and the default value reinforces that.
These fishing keys only matter on servers where fishing is a relevant gameplay mechanic. On a combat-focused PvP server where players spend their time fighting and looting, the fishing intervals are typically left at their defaults or ignored entirely because fishing is not a primary activity. On a survival or roleplay server where fishing is a legitimate food-gathering activity -- where players spend extended periods at the water's edge -- the intervals directly affect how much time players invest in fishing relative to other food sources. Short intervals make fishing the most efficient food source; long intervals push players toward hunting, farming, or looting for sustenance.
World Behaviour
The world behaviour group covers settings that affect the map environment, cosmetic content, and gameplay mechanics that are not strictly combat, building, or groups. These keys are fewer in number but have broad reach across the player experience.
Seasonal Content
Allow_Holidays controls whether holiday-themed content loads on the server. When true (the explicit default shown in the key table), Halloween and Christmas content is active. This includes changes to NPC outfits -- zombies and non-player characters may wear seasonal costumes such as pumpkin-head masks or Santa hats -- and the game places decorative objects on the map, such as carved pumpkins in town squares or christmas trees in central areas. When false, the server suppresses all holiday cosmetic content and runs in its standard visual state regardless of the calendar date.
The Halloween and Christmas events in Unturned change the visual presentation of the game world without changing the underlying gameplay mechanics. A zombie wearing a pumpkin head has the same health, damage, and behaviour as the same zombie type without the pumpkin head. A zombie with a Santa hat fights identically to one without. The changes are entirely cosmetic. However, cosmetics can still be confusing: a new player who has learned that zombies in their area look a certain way -- green skin, torn clothing, specific silhouette -- may not immediately recognize a zombie in a full-body Santa costume as the same threat.
Some servers disable holidays to maintain a consistent visual baseline across the entire year, so that players never encounter unfamiliar NPC variants regardless of when they join. Other servers leave holidays enabled because the seasonal variety is part of the game's identity and many players expect to see decorated zombies in October and December. The choice is aesthetic, not mechanical.
This key does not check the calendar. It does not enable holidays only during October and December. It is a manual binary toggle: when true, the holiday assets are loaded on startup regardless of the current date. When false, they are suppressed regardless of the date. A server owner who wants holidays to appear only during their natural season must manually edit Config.json twice a year -- enabling the key before Halloween and Christmas, disabling it after. There is no automatic scheduling mechanism for this in the server configuration.
Environment Controls
Disable_Foliage_Off enforces a minimum foliage density on every connected client. In Unturned's graphics options, players can set foliage quality to several levels, one of which is "Off" -- this removes grass, bushes, ground cover, and other vegetation from the rendered scene entirely. When Disable_Foliage_Off is true, the "Off" option is removed from the client-side foliage selector, and the lowest available quality setting becomes "Low." Players can still reduce foliage density, but they cannot eliminate it.
This key exists because foliage provides visual cover. Tall grass can hide a prone player. Bushes can obscure a placed trap or a dropped item. A player who disables foliage removes that cover from their view, making hidden players and objects visible against the bare terrain. This creates an information asymmetry: a player with foliage off can see a player with foliage on who is hiding in the grass, but the hiding player cannot see the searcher because the grass is still there from their perspective.
Forcing a minimum density of Low standardizes the playing field. Every player has at least some vegetation on their screen, so the visual cover that the map provides functions the same way for everyone. This is a common setting on PvP servers where hiding and camouflage are legitimate tactical options and where the foliage-off advantage is considered unfair.
Disable_Foliage_Off takes precedence over client settings. A player cannot override this with their local graphics configuration. It is one of the few server-side keys that directly constrains what the client is allowed to render, rather than simply controlling server-side game logic.
Fishing Challenge
Enable_Fishing_Catch_Challenge controls whether a skill-based minigame must be completed between the fish bite and the successful catch. When true, the fishing sequence has two stages. First, the player casts, waits through the bite interval (governed by the min and max bite interval keys), and receives the bite notification. Second, before the fish is added to inventory, the player must complete a short interactive challenge -- typically involving timed input such as pressing a key within a response window or following a moving indicator on screen. If the challenge is completed successfully, the fish is caught. If the challenge is failed, the fish escapes and the player must cast again.
When false, the second stage is skipped. The fish bite triggers the catch immediately with no player input beyond the initial cast. The bite interval alone determines the fishing outcome.
This key adds a mechanical skill element to fishing, converting it from a purely wait-based activity to a two-phase activity that rewards player attention and timing. A player who casts and then looks away from the screen risks missing the challenge window, which costs them the catch. A player who pays attention and executes the challenge cleanly catches fish reliably. Servers that enable this setting typically want fishing to feel like an active gameplay loop rather than an idle activity that runs in the background while the player does something else.
The challenge mechanic also introduces a failure state that the base fishing system does not have. On a server with the challenge disabled, every bite is a guaranteed catch. On a server with the challenge enabled, a bite only becomes a catch if the player passes the challenge. This means the effective fish-per-minute rate is lower on challenge-enabled servers, because some bites lead to escapes. Server owners adjusting fishing as a food source should account for this: a player fishing for ten minutes on a challenge-disabled server will catch every fish that bites. The same player on a challenge-enabled server may catch fewer, depending on their challenge success rate.
This key only takes effect on maps and fishing rods that implement the catch challenge system. The SDK source flags this explicitly: the mechanic is "only applicable for supported maps and fishing rods," meaning older custom maps and rod assets built before this mechanic was added to the game do not support the challenge. If the map does not define a challenge implementation, or if the rod does not reference one, enabling this key has no observable effect -- the game silently bypasses the challenge check because there is no challenge to present. On a server running exclusively modern maps with supported fishing rods, the key works as described. On a server with a mix of old and new content, the key will work on some maps and rods and silently do nothing on others.
Canned Beans
The Canned Beans -- the single most documented edible item in 57 Studios lore, tracked across maps, spawn tables, and cultural significance in the survivor world -- do not appear in the Gameplay section of Config.json. Not one of the 47 keys governs food, hunger, inventory contents, edible items, or any consumable mechanic. The Gameplay section defines the rules that the game world runs by; it does not define the objects that exist within that world. If you came to this article looking for the bean key in Config.json, you have read every key on this page and confirmed that it does not exist.
This is true of all food items in Unturned. Beans, bottled water, MREs, granola bars, vegetables, canned goods, and every other edible in the item catalog are defined in asset files, loot table definitions, and item data bundles that sit outside the scope of Config.json entirely. A server owner who wants to change how often beans spawn, what nutritional value a can provides, how many beans can stack in a single inventory slot, or where in the world beans appear must edit those asset files. The Gameplay section has no key for any of these things, and it has no hook through which an item's behaviour can be modified from the server configuration layer.
The separation is deliberate architecture. Config.json controls the environment -- the physics, the interface, the group mechanics, the timers, the damage rules. Asset files control the content -- the items, the weapons, the vehicles, the animals, the zombies, the map geometry. Beans belong to the content layer, and the content layer is configured through a different set of files: the .dat asset definitions in the game's bundled content, the loot table JSON documents that define spawn probabilities, and the map files that place spawn nodes in the world.
A server owner who wants to configure beans -- make them spawn more frequently, less frequently, or not at all; change how much hunger a can restores; add a custom can variant with a different model or effect -- must work in those asset files, not in Config.json. The Gameplay section is the wrong tool for the job, and searching for a bean key in the Gameplay block will return nothing because nothing was designed to be there.
This is true of every consumable item in the game. There is no Food_Value_Multiplier, no Drink_Value_Multiplier, no Item_Spawn_Rate, and no Edible_Stack_Size in the Gameplay section. These properties are all defined per-item in asset data. The Gameplay section governs the rules of the world, not the objects that populate it. Understanding this separation is one of the first things a server owner learns when they move from editing a single configuration file to administering the full content pipeline.
For the full documented history of the canned beans in Unturned, including can geometry verified against the game's rendering data, spawn tables mapped across every official release, nutritional mechanics within the survival system, and the spiritual significance of the can to long-running 57 Studios cohort survivors, see the Canned Beans Lore article.
Practical Use for Server Owners
Reading vs. Writing
Config.json is read at server startup and held in memory for the duration of the server process. It is never re-read during uptime. Every change you make to the Gameplay section -- adding a key, removing a key, changing a value -- requires a full server restart to take effect. There is no live-reload mechanism, no in-game console command, and no admin panel function that can refresh Config.json on a running server. Schedule your edits around planned restarts, and if your server has a regular player base, communicate downtime in advance.
This also means that Config.json is not a live tuning tool. You cannot adjust recoil, toggle hitmarkers, or change respawn timers and see the effect in real time on a populated server. Testing a configuration change requires a restart, joining the server, and observing the behaviour. For this reason, many server owners maintain a separate test instance -- a second server process on a different port, reading a test copy of Config.json -- where they validate changes before applying them to the production server.
Defaults and the Dash
Where the key table shows a dash (-) as the default, the game uses an internal default that is set in the compiled server executable, not in the configuration layer. Two implications follow from this.
First, you cannot learn the default value by reading the SDK source. The - means the value is not declared in the GameplayConfigData class fields. The actual default lives deeper in the server binary, and the only way to determine what it is on a given server build is to either observe the behaviour in-game with the key omitted or consult the game's release documentation if it publishes default values.
Second, if you want to be absolutely certain of the behaviour for a key with a dash default, you must set it explicitly. A Config.json with no Gameplay section at all runs entirely on internal defaults. A Config.json with a Gameplay section that omits some keys runs those omitted keys on internal defaults. Only keys you write explicitly override the built-in behaviour. If your server's identity depends on a specific boolean setting -- say, disabling hitmarkers -- write "Hitmarkers": false in your Config.json even if you believe the internal default is already false. Explicit values survive game updates that might silently change internal defaults.
For float keys that do show an explicit default (e.g., 1.0f, 2.0f, 0.0f), the value listed in the table is the canonical base value from the SDK. Writing the same value into your Config.json has no observable effect on gameplay -- you are explicitly setting the key to what it already was -- but it makes your intention visible to anyone reading the file later, including yourself when you return to the configuration after six months away.
Boolean Values in JSON
All bool keys in this section accept only the bare JSON values true and false -- lowercase, no quotes. Writing "true" (a quoted string) where the type system expects a boolean may produce a parse error or may be silently coerced to an unintended value, depending on which JSON parser the server build uses and how strict its type checking is. The behaviour is not guaranteed across server versions, and what works on one build may break on the next. Write true and false as bare tokens.
The same applies to numeric types. uint keys accept bare integers: write 30, not "30". float keys accept bare decimal numbers: write 1.0, not "1.0", and write 0.3, not "0.3". The type column in the key table -- bool, uint, float -- tells you which JSON type to use for each key. String values ("...") never appear as valid Gameplay section types.
uint (unsigned integer) specifically means the key accepts only non-negative whole numbers. Writing -1 or -5 for a uint key will produce undefined behaviour because unsigned integers cannot represent negative values. The server may clamp the value to zero, wrap it to a large positive number, or reject the file entirely. If you want a timer to be zero (instant), write 0, not a negative value.
Server Identity
The Gameplay section is where a server's mechanical identity lives. The word "vanilla," when used to describe a server, typically means the ballistics, hitmarker, group, and movement keys are at or near their defaults. The word "hardcore" typically means hitmarkers are disabled, the crosshair is hidden, the shoulder camera is off, group HUD markers are suppressed, foliage minimums are enforced, and respawn timers are long enough to make death punishing. The word "casual" typically means the chart, satellite, and compass are enabled for all players, friendly fire is off, and recoil and spread multipliers are tuned down to make shooting easier.
There is no objectively correct configuration. Every combination of these 47 keys is a valid server identity. The art of running a server is choosing the combination that aligns with what your community expects and communicating those choices clearly to players who join. A configuration that works for a competitive PvP community will frustrate a cooperative survival community, and vice versa.
A practical step after configuring your Gameplay section is to document the key differences from default in a visible location -- a Discord rules channel, a server MOTD, a spawn-area sign, or a welcome message. A player who joins expecting ballistics and finds hitscan, or who expects a crosshair and finds none, may leave immediately because the server does not match their expectations. A one-sentence summary of what kind of gameplay your settings produce ("ballistics on, hitmarkers off, first-person only") prevents that mismatch.
Interaction Effects
Many keys in the Gameplay section interact with each other in ways that produce combined effects larger than what either key produces alone. Understanding these interactions is important because a server owner who changes keys one at a time and tests each in isolation may miss the compound behaviour that emerges when two or three keys are changed together.
Disabling Crosshair and disabling Hitmarkers together creates a combat environment where the player has no on-screen aim reference and no automatic feedback that shots are connecting. Each key alone reduces the player's information. Together they strip the shooting interface almost entirely, leaving only visual observation of the target -- watching the enemy's health bar, watching their flinch animation, watching them fall -- to tell the player whether they hit. This combination creates a combat experience where every shot is uncertain until the target's reaction confirms the hit.
Enabling Friendly_Fire while disabling both Group_HUD and Group_Map creates an environment where groups are mechanically dangerous to each other and information-poor. A player who rounds a corner and sees a figure has no HUD marker to identify them as a groupmate or an enemy. If they fire before identifying the target, they may kill a teammate. If they wait to identify, an enemy may fire first. This combination rewards cautious play, clear verbal communication, and visual target identification over interface reliance.
Setting Bypass_Building_In_Safezones = true while leaving Friendly_Fire = false creates a scenario where groups can build inside safezones and are immune to damage from each other within those structures. The base is unraidable because nothing outside the safezone can damage it and nothing inside can harm the occupants. This combination, intentionally or not, enables permanent invulnerability that no normal gameplay mechanic can circumvent.
Enabling all three navigation keys (Chart, Satellite, Compass) while disabling all three group information keys (Group_Map, Group_HUD, Group_Player_List) creates a server where every player can navigate independently and see the full map layout, but groups must communicate their positions manually. A group leader navigating with satellite detail cannot see where their groupmates are on that satellite map. Meeting up requires coordinates and descriptions: "meet at the gas station at grid D-7, west of the bridge."
Setting Timer_Respawn = 0 and Timer_Home = 0 together eliminates all death penalties. A player who dies returns instantly, whether to a random spawn or to their bed. Combined with Can_Suicide = true, this creates a teleportation system: a player can suicide and respawn at a bed anywhere on the map with zero waiting time. This combination effectively removes travel as a mechanic and should be adopted with full awareness of how it reshapes player movement behaviour.
Testing a Configuration
The most reliable way to test a gameplay configuration is to join the server yourself after a restart and walk through every system you changed. Config.json is a text file, but its output is the entire player experience, and text-validating the JSON is not enough -- you must test in-game against the actual server process.
Start with the most impactful changes. If you adjusted recoil multipliers, fire weapons in both first-person and third-person and feel the difference in kick between perspectives. Fire several magazines to get a sense of the sustained-fire pattern, not just the first shot. If you changed respawn timers, die intentionally -- fall damage is the most controlled way -- and count the seconds on the respawn screen with a stopwatch or phone timer. Verify both the standard respawn and the home respawn timers independently.
If you toggled building bypass keys, attempt to place a structure in a zone where it was previously blocked. Walk to a known safezone, a known no-building zone, and a vehicle, and try to place each type of buildable that should now be allowed. Do not assume the bypass works; place the object and confirm it snaps. If you adjusted air-strafing values, jump and try to change direction midair. Run forward, jump, and hold a side key to feel how sharply the character turns. If you enabled or disabled fishing challenges, cast a line into water and verify whether the challenge interface fires when a fish bites.
If you changed group HUD or group information settings, test with at least one other player. Config.json changes that affect group information are not testable solo because you need a groupmate to verify whether their name appears through walls, on the map, or on the player list. Recruit a friend or use a second account to join the server and confirm each group-related key.
Text-validating the JSON file with a linter confirms only that the syntax is parseable. It does not confirm that the values produce the intended gameplay experience. A value of 2.0 is valid JSON but may represent twice the recoil you intended if you meant to write 0.5. A value of 300 for a respawn timer is valid but represents five minutes when you may have intended thirty seconds. In-game testing catches these semantic errors. On a critical server, test every meaningful key change individually rather than making a batch of twenty changes and hoping they all land correctly. Change one key, restart, test, and only then move to the next.
File Backup
Before making any significant change to Config.json, copy the working file to a backup name. A timestamped filename like Config.json.2026-07-28-backup is clear and sortable. If the server fails to start after your edit -- which happens most commonly because of a missing comma, an extra brace, or a stray character introduced during editing -- revert to the backup by copying it over the broken file, then restart. The server will load the last known good configuration.
Do not rely on undo in your text editor. If you make several edits, save, close the file, and the server fails to start, the undo history may not be available. A physical backup file sitting in the server directory is faster to revert from than any other recovery path.
When the server starts successfully on the new configuration, keep the backup for at least one full play session. If a bug surfaces that you did not catch in testing -- a respawn timer that is thirty times longer than intended because you wrote 300 instead of 30, for example -- you can revert to the backup, restart, and fix the value after the server is stable again.
Working with Multiple Server Instances
If you run more than one Unturned server -- a PvP server and a PvE server, for example, or servers on different maps -- keep a separate Config.json for each instance. Do not share a single Config.json between servers with different identities. The Gameplay section of a hardcore PvP server should not be identical to the Gameplay section of a casual PvE server, and the easiest way to keep them distinct is to maintain separate files. Name them by their server identity: Config.pvp.json, Config.pve.json, Config.events.json. When you start a server, point it at the correct file.
This also means that when you change a key for one server, you do not accidentally change it for the others. A recoil multiplier tuned for a competitive environment is not automatically appropriate for a creative building server, and a shared Config.json makes it too easy to apply a change globally without considering each server's needs.
JSON Structure Reference
For a server owner writing a Config.json from scratch, here is the minimum valid structure for including Gameplay keys:
json
{
"Gameplay": {
"Ballistics": true,
"Hitmarkers": true,
"Crosshair": true
}
}The Gameplay object goes at the top level of the JSON document, alongside other top-level sections like Server, Browser, and Workshop. Every key in this article goes inside the Gameplay object. The order of keys inside the object does not matter -- the server reads them by name, not by position -- but keeping them in a consistent order (such as the order they appear in the key table above) makes the file easier to scan when you return to it later.
Keys you do not include in the Gameplay object are not set to false or 0. They are simply absent, and the server uses its internal default for that key. An absent key and a key explicitly set to the internal default produce the same behaviour, but only the explicitly set key documents your intent. For keys where the internal default may change across game updates, writing the value explicitly protects your configuration from silent changes.
Verifying After a Game Update
When Unturned receives a major update -- the kind that changes the server executable, not just a workshop content patch -- the Gameplay section of Config.json may gain new keys, lose deprecated keys, or change the internal defaults of existing keys. After updating the server, compare your Config.json against the key table in this article (or against the current SDK source if this article was written for a prior version). If a new key has been added, decide whether to include it in your Config.json or let it run on its internal default. If a key has been removed, delete it from your file; a removed key becomes dead weight that may produce a warning in server logs. If an internal default has changed, and your Config.json relies on that default, you may need to explicitly set the key for the first time to preserve the previous behaviour.
A full server restart after an update is always required. An update that changes the server executable also changes the config-reading code, and a running server will not pick up new configuration expectations until it is stopped and started again on the new executable.
Getting Help
When asking for help with Config.json -- in a Discord server, a forum thread, or a direct message to another server owner -- include the exact text of your Gameplay block, not a description of what you think you set. "I think I have ballistics turned on" is not actionable. The JSON itself is. Paste the block, wrapped in a code fence, so that the person helping you can read the actual values and spot the actual problem. If you are troubleshooting a specific behaviour, mention which key or keys you believe affect that behaviour and what you expected to happen versus what actually happened.