Config.json Players Section Reference

Beginner25-35 minutesCross-platformConfig.jsonDedicated ServerText Editor

The Players section of an Unturned dedicated server Config.json governs everything about player survival: starting health and vitals, how quickly those meters drain, what happens when a player dies, what skills and items they retain, and how the world detects and reacts to them. If you are editing Config.json for the first time and want to tune the difficulty, fairness, or pace of your server, this is the section you need.

All 47 keys belong to the top-level "Players" object in Config.json. Every key listed below is a direct child of that object; there are no nested sub-objects. The section is self-contained: it does not reference keys from other Config.json sections, and other sections do not depend on these keys. You can edit the Players section in isolation and your changes will take effect without needing to touch any other part of the file.

The JSON structure looks like this at the file level (other sections omitted for clarity):

{
  "Easy": { ... },
  "Normal": { ... },
  "Hard": { ... },
  "Players": {
    "Health_Default": 100,
    "Food_Default": 100,
    ...all 47 keys go here...
  },
  "Objects": { ... },
  "Vehicles": { ... }
}

The "Players" key is a top-level property of the root JSON object. All 47 configuration keys live inside the value of that property, which is itself a JSON object. You add, remove, or edit key-value pairs within that object, and you must maintain valid JSON syntax throughout the file -- one missing comma or misplaced brace in any section will prevent the entire Config.json from loading.

Keys with the type uint accept whole numbers (0, 50, 100). Keys with the type float accept decimal values, and where the source notes indicate a 0-to-1 range, that range represents a percentage -- a value of 0.5 means 50%, a value of 0.25 means 25%. Keys with the type bool accept true or false (lowercase, without quotes in the JSON file). Keys whose default column shows a hyphen use the game's own internal fallback value; the hyphen means "not explicitly set, use the hardcoded game default."

The table below is the full key inventory. If a key does not appear in this table, it is not part of the Players section. Do not invent keys or copy keys from other sections into this object. The game will ignore unrecognised keys, but they clutter your config and may mislead anyone else who reads the file.

Understanding the tick system

Before diving into individual keys, it helps to understand how Unturned processes time for meter depletion and regeneration. The game runs on a server-side tick loop: a fixed number of times per second, the server advances all game state -- creature AI, projectile physics, player meter values, status effect timers. Many of the keys in the Players section are named with a _Ticks suffix, and they all follow the same logic.

A tick key sets the interval between events. Each server tick, a counter increments. When the counter reaches the value of the tick key, the event fires (the player takes damage from bleeding, their food meter drops by one unit, their health regenerates by one unit, and so on) and the counter resets to zero. The critical detail for tuning is the direction of the relationship: lower tick values mean the event fires more often, higher tick values mean the event fires less often.

This is counterintuitive for some server owners because many config files in other games use values where "higher means faster." In Unturned's Players section, a low number means fast. If you want food to drain rapidly, you set Food_Use_Ticks to a low value. If you want health to regenerate quickly, you set Health_Regen_Ticks to a low value. If you want a starving player to die slowly, you set Food_Damage_Ticks to a high value -- the damage ticks arrive less often.

Every tick key in this section works on this same principle. The explanation for each key below will state the direction explicitly, but once you internalise "lower equals more frequent," you can read every _Ticks key in the table and know which direction to push it to achieve your goal.

Complete key table

The following table lists every key in the Players section, its data type, and its default value as defined by the game. Use this as your quick reference for what is available to configure.

Key	Type	Default
Health_Default	uint	-
Health_Regen_Min_Food	uint	-
Health_Regen_Min_Water	uint	-
Health_Regen_Ticks	uint	-
Food_Default	uint	-
Food_Use_Ticks	uint	-
Food_Damage_Ticks	uint	-
Water_Default	uint	-
Water_Use_Ticks	uint	-
Water_Damage_Ticks	uint	-
Virus_Default	uint	-
Virus_Infect	uint	-
Virus_Use_Ticks	uint	-
Virus_Damage_Ticks	uint	-
Leg_Regen_Ticks	uint	-
Bleed_Damage_Ticks	uint	-
Bleed_Regen_Ticks	uint	-
Armor_Multiplier	float	-
Experience_Multiplier	float	-
Detect_Radius_Multiplier	float	-
Ray_Aggressor_Distance	float	-
Lose_Skills_PvP	float	-
Lose_Skills_PvE	float	-
Lose_Skill_Levels_PvP	uint	-
Lose_Skill_Levels_PvE	uint	-
Lose_Experience_PvP	float	-
Lose_Experience_PvE	float	-
Skill_Cost_Multiplier	float	-
Lose_Items_PvP	float	-
Lose_Items_PvE	float	-
Lose_Clothes_PvP	bool	-
Lose_Clothes_PvE	bool	-
Lose_Weapons_PvP	bool	-
Lose_Weapons_PvE	bool	-
Can_Hurt_Legs	bool	-
Can_Break_Legs	bool	-
Can_Fix_Legs	bool	-
Can_Start_Bleeding	bool	-
Can_Stop_Bleeding	bool	-
Spawn_With_Max_Skills	bool	-
Spawn_With_Stamina_Skills	bool	-
Skillset_Reduces_Skill_Cost	bool	true
Skillset_Prevents_Skill_Loss	bool	true
Prevent_Level_Skill_Overrides	bool	-
Allow_Instakill_Headshots	bool	-
Allow_Per_Character_Saves	bool	-
Enable_Terrain_Color_Kick	bool	true

Health and vitals

This group controls the four core survival meters every player must manage: health, food, water, and immunity. Together they define how much of each resource a player starts with, what thresholds trigger regeneration, how fast the meters deplete under normal conditions, and how fast things go wrong when those meters run empty. A server owner tuning these keys is setting the baseline survival pressure -- are your players scrambling for supplies, or comfortably exploring with full bars?

Each meter follows a similar two-phase model. In the first phase, the meter drains gradually through normal gameplay. The player can eat, drink, or use medical items to replenish the meter. In the second phase, triggered when the meter hits zero, the player takes damage at a steady interval until they die or restore the meter above zero. The tick keys in this group let you control the speed of both phases independently for each meter.

Starting values

Health_Default sets the amount of health a newly spawned player begins with. The valid range is 0 to 100, where 100 is full health and 0 is dead. A value of 0 would spawn players dead, which is not useful. Most servers set this somewhere between 80 and the maximum of 100, depending on how fragile you want the opening moments of a session to feel. A player who spawns at 80 health can survive one or two hits from a zombie before needing to heal; a player who spawns at 100 has a full buffer against the first encounter.

Food_Default and Water_Default work the same way for the hunger and thirst meters. Both accept values from 0 to 100. A freshly spawned player receives exactly these amounts. Setting both to 100 means a new player arrives fully fed and hydrated with no immediate pressure to find supplies. Setting them to 50 means the player must locate food and water within the first few minutes of gameplay before the meters drain to dangerous levels. Setting them to 25 creates urgent pressure right out of the spawn screen.

The interaction between these three keys matters. A player who spawns with full food and water but only 50 health is in a manageable state: they can regenerate their missing health through the regeneration system (described below) because their food and water are full, and they have time to find supplies. A player who spawns with full health but food and water at 10 is in worse shape: they are not immediately injured, but they are minutes away from starvation and dehydration with no way to regenerate health once they do take damage.

Virus_Default sets the starting immunity value, also in the 0-to-100 range. Immunity is the counter that determines whether a player is susceptible to the zombie virus. A value of 100 means the player is fully immune at spawn and will not begin the infection process until something reduces their immunity -- typically a zombie attack or consumption of a contaminated item. A value of 50 means the player starts halfway toward the infection threshold (governed by Virus_Infect, discussed below). A value of 0 means the player begins the game already infected and taking virus damage immediately.

Health regeneration thresholds

Health does not regenerate at all times -- it only restores when the player has both sufficient food and sufficient water simultaneously. Two keys set the minimum thresholds that must be exceeded.

Health_Regen_Min_Food is the minimum food level a player must carry before health regeneration will begin. The source note specifies "more than this amount," meaning the player must strictly exceed the threshold. If you set this to 50, a player at exactly 50 food will not regenerate; they must be at 51 or above. A value of 0 effectively disables the food requirement for regeneration -- the player will regenerate health as long as the water condition is also met. A value of 90 makes regeneration extremely demanding, requiring the player to stay nearly full on food to heal.

Health_Regen_Min_Water is the equivalent threshold for the water meter. The same "more than" rule applies. Both conditions must be true at the same time for health to begin recovering. A player who exceeds the food threshold but is below the water threshold will not regenerate health, and vice versa. The practical effect is that players who neglect one meter while maintaining the other are in the same position as players who neglect both: no passive healing.

If you want regeneration to be generous, set both thresholds low (0 or 10). The player will regenerate health almost any time they have eaten or drunk recently, and only extreme neglect will shut regeneration off. If you want regeneration to be scarce and demanding, set both thresholds high (80 or 90). The player must actively maintain near-full meters to receive any passive healing, and the moment they dip below either threshold the healing stops. A common middle ground is to set both thresholds to 50: the player must keep their meters above half to regenerate, which is achievable with regular attention but punishes a player who lets both bars run low.

Health regeneration speed

Health_Regen_Ticks controls how fast health regenerates once both food and water conditions are met. Following the tick system logic described above, lower values mean faster regeneration because the counter reaches its target sooner and the healing tick fires more frequently. Higher values mean the counter runs longer between each healing tick, so health recovers more slowly.

This key does not change how much health is restored per tick -- it only changes the interval between ticks. A very low value produces near-continuous healing ticks, which can make players effectively unkillable as long as their food and water are maintained. A very high value makes regeneration so slow that it is barely perceptible, useful for servers where healing should come primarily from medical items (bandages, medkits, vaccines) rather than passive recovery. On a server where you want regeneration to be a background convenience rather than a combat mechanic, set this moderately low. On a hardcore server where regeneration should be too slow to matter during a fight, set this high.

Food meter depletion and starvation

The food meter does not stay where it starts -- it drains over time as the player moves, fights, gathers, and exists in the world. Two keys per meter govern the two phases of depletion.

Food_Use_Ticks controls how fast the food meter empties under normal conditions, when the meter is above zero. Lower values make the food meter drain more quickly, which forces players to eat more often and spend more time looking for food. Higher values slow the drain, extending the time between meals and reducing the survival pressure. If you set this very high, the food meter barely moves and players can ignore hunger almost entirely. If you set it very low, players will be in a constant race to find their next meal before the meter hits zero.

The key interaction here is between Food_Use_Ticks and Food_Default. If a player spawns with 100 food and the use ticks are set to drain slowly, they have a generous grace period before hunger becomes a concern -- they can explore, gather basic gear, and locate a town before worrying about food. If they spawn with 25 food and the use ticks drain rapidly, they are in trouble within the first minute and must find food immediately. Tuning both values together lets you set the initial urgency of food gathering and the long-term maintenance rhythm.

Food_Damage_Ticks takes over when the food meter hits zero. At that point the player is starving, and this key determines how rapidly the starvation damage ticks arrive. Each tick deals damage to the player's health. Lower values mean the damage ticks happen more frequently, so a starving player dies faster. Higher values space the damage ticks further apart, giving the player more time to find food and eat before the accumulating damage kills them.

The relationship between Food_Use_Ticks and Food_Damage_Ticks creates the full hunger curve. Food_Use_Ticks controls how long it takes to reach zero from any given starting value. Food_Damage_Ticks controls how long the player survives after reaching zero. If you want hunger to be a slow-burn background threat, set both high: the meter drains slowly, and even when empty the player has a generous window to recover. If you want hunger to be an urgent kill pressure, set both low: the meter drains fast and starvation kills fast. If you want hunger to drain quickly but kill slowly, set Food_Use_Ticks low and Food_Damage_Ticks high -- the player feels constant time pressure but is not immediately doomed by a single lapse.

Water meter depletion and dehydration

Water_Use_Ticks and Water_Damage_Ticks mirror the food system exactly but for the thirst meter.

Water_Use_Ticks governs how fast the water meter depletes during normal gameplay. Lower values make thirst drain faster; higher values make it drain slower. The same tuning principle applies as with food: pair this with Water_Default to set how quickly a newly spawned player needs to find a water source. A low default plus low use ticks means immediate pressure. A high default plus high use ticks means thirst is barely a factor.

Water_Damage_Ticks governs how quickly dehydration kills the player once the water meter reaches zero. Each damage tick removes health at the interval defined by this key. Lower values kill faster; higher values buy more time to find water before dying. The same asymmetric tuning strategy applies: you can make thirst drain quickly (low Water_Use_Ticks) but kill slowly (high Water_Damage_Ticks), creating constant pressure to drink but not a fast death spiral.

If you want food and water to be symmetric threats with identical tuning, set the four food and water tick keys to matching pairs: Food_Use_Ticks equals Water_Use_Ticks, and Food_Damage_Ticks equals Water_Damage_Ticks. If you want one meter to drain faster than the other -- for example, if your server is set on a desert map where thirst should be the dominant survival mechanic -- set the water tick values lower (faster drain, faster death) than the food tick values.

Immunity and infection

The immunity meter (often referred to as the virus meter) follows a similar depletion pattern but with an extra threshold step. The meter does not begin depleting immediately when the player spawns. It only starts to drain on its own once immunity falls below a threshold set by a separate key.

Virus_Infect sets the threshold below which immunity begins to deplete on its own. When the player's immunity is above this value, the immunity meter stays stable and does not drift downward. The player must actively take immunity damage (from zombie hits, contaminated consumables, or other sources) to reduce their immunity into the danger zone. When immunity drops below the Virus_Infect value, the meter begins a self-sustaining drain toward zero. A higher value for this key means players enter the infection state sooner; they do not need to take much immunity damage before the automatic drain begins. A lower value gives them a wider safe zone where their immunity is stable.

Virus_Use_Ticks governs the rate at which immunity drains while the player is below the Virus_Infect threshold. This is the key that makes infection feel fast or slow. Lower values strip immunity faster, pushing the player more aggressively toward zero. Higher values give the player more time to find a cure or vaccine before their immunity fully collapses. This key only matters while the player is infected (below the Virus_Infect threshold). A player with immunity above the threshold is not affected by this key at all -- their immunity is static.

Virus_Damage_Ticks determines how quickly the player dies once immunity reaches zero. At zero immunity the player is fully infected, and this key sets the pace of the final damage ticks. Each tick deals health damage. Lower values mean the ticks arrive more frequently, killing the player faster. Higher values space the ticks out, buying desperate time to find a cure even with zero immunity remaining.

The three virus keys together form a complete infection timeline with three distinct phases. Phase 1 (immunity above Virus_Infect): stable, no automatic drain -- the player is safe until they take more immunity damage. Phase 2 (immunity below Virus_Infect but above zero): immunity drains at the rate set by Virus_Use_Ticks -- the player is on a timer. Phase 3 (immunity at zero): the player takes damage at the rate set by Virus_Damage_Ticks until they die or cure themselves. A server that wants virus to be a slow, manageable threat would set Virus_Infect low (wide safe zone), Virus_Use_Ticks high (slow drain), and Virus_Damage_Ticks high (slow death). A server that wants virus to be a rapid death sentence would set Virus_Infect high (narrow safe zone), Virus_Use_Ticks low (fast drain), and Virus_Damage_Ticks low (fast death).

Global damage scaling

Armor_Multiplier is a float that acts as a global damage modifier applied to all damage players receive, regardless of the damage source -- zombie claws, animal bites, player gunfire, fall damage, environmental hazards. A value of 1.0 means damage is unchanged: a hit that would normally deal 30 damage deals exactly 30. A value of 0.5 halves all incoming damage, so that same 30-damage hit deals only 15. A value of 2.0 doubles all incoming damage, making that hit deal 60.

This multiplier applies before any per-item armour calculations. If a player is wearing armour that provides a 20% damage reduction, and Armor_Multiplier is set to 0.5, the incoming damage is first halved by the multiplier and then further reduced by the armour piece. The order is multiplicative: base damage gets multiplied by Armor_Multiplier, and then the result gets multiplied by the armour's reduction factor. A 30-damage hit on a player with 20% armour and an Armor_Multiplier of 0.5 becomes 30 times 0.5 equals 15, and then 15 times 0.8 equals 12 final damage.

This key is one of the fastest ways to change the overall feel of combat on your server. A survival server where combat should be dangerous and deliberate would run this at 1.0 or slightly above. A creative or roleplay server where combat should be forgiving and not disrupt the flow of activity would run it at 0.5 or lower. A hardcore server where every hit is potentially fatal and combat demands perfect play would run it at 2.0 or above. Adjust this key in small increments -- the difference between 0.8 and 1.2 is already a 50% swing in effective player durability.

Stat regeneration

Stat regeneration covers the two secondary conditions a player can suffer beyond raw health loss: broken legs and bleeding. These are status effects that persist independently of the health meter. A player can have full health but still be limping on a broken leg, their movement speed reduced until treatment or natural recovery. A player can have full health but still be losing health steadily from an open wound, each bleed tick chipping away at their bar. The keys in this group determine whether these conditions can occur at all, and if they do, how quickly they resolve.

Broken legs: the gate keys

The leg system uses three boolean keys arranged in a dependency chain, plus one uint key that controls recovery speed. Understanding the chain is important because disabling an earlier key makes later keys irrelevant.

Can_Hurt_Legs is the broadest gate. When set to false, players take no health damage from falling, regardless of the fall distance. Note the specific wording in the source note: "no health loss from falling long distances." This key does not physically prevent the fall -- the player can still drop from any height, climb down cliffs, or jump off rooftops. What it prevents is health being subtracted from the player's health meter as a result of that fall. When set to true, fall damage operates normally: the longer the fall, the more health is lost. The two boolean keys below become relevant only when this key is true.

Can_Break_Legs determines whether a fall that deals damage can additionally inflict the broken-leg status effect. A broken leg is a mobility penalty: the affected player moves at reduced speed, cannot sprint, and may have other movement constraints until the leg heals or is splinted. The key depends on Can_Hurt_Legs: if a fall does not deal damage (because Can_Hurt_Legs is false), there is no damage event to trigger a break check. If Can_Hurt_Legs is true but Can_Break_Legs is false, falls deal health damage but never result in a mobility penalty -- the player loses health but can keep running. If both are true, a sufficiently damaging fall can both hurt the player (health loss) and break their legs (mobility loss), creating a double consequence for bad terrain navigation.

Can_Fix_Legs governs whether broken legs heal automatically over time. When set to true, a player with broken legs will see the condition clear on its own after enough time passes. The exact duration is governed by the Leg_Regen_Ticks key described below. The player does not need to do anything; they can simply wait, and the leg will mend. When set to false, a broken leg is permanent until the player actively uses a splint, medkit, vaccine, or other in-game item that treats the broken-leg condition. Time alone will not fix it, and the mobility penalty persists indefinitely without treatment.

These three boolean keys let you construct several distinct fall-consequence models. A server with all three set to true has realistic fall consequences: damage and potential mobility loss, but natural recovery over time. A server with only Can_Hurt_Legs set to false has consequence-free vertical movement -- players can navigate the map's vertical dimension without any risk. A server with Can_Hurt_Legs true, Can_Break_Legs true, and Can_Fix_Legs false forces players to carry splints or risk being crippled indefinitely after a bad fall, adding inventory management pressure and making falls a serious strategic error rather than a temporary inconvenience.

Broken legs: recovery speed

Leg_Regen_Ticks sets how quickly broken legs heal when Can_Fix_Legs is true. As with all tick keys in this section, lower values mean faster recovery and higher values mean slower recovery. If you set this very low, a broken leg clears almost immediately after the fall, making the mobility penalty so brief that it hardly registers. If you set it to a moderate value, the player limps for a noticeable but survivable duration -- long enough to matter during an escape from zombies, short enough that waiting it out is viable. If you set it very high, the player limps for an extended period, making falls a serious strategic mistake with lasting consequences.

This key has no effect when Can_Fix_Legs is false, because automatic recovery is disabled entirely. In that case, the only way to clear a broken leg is through an item, and the tick value is bypassed.

Bleeding: the gate keys

The bleeding system parallels the leg system in structure: two boolean master switches and two uint timing keys. The same dependency logic applies.

Can_Start_Bleeding is the gate for whether any damage source can cause the bleeding status effect at all. When set to false, no attack -- from zombies, animals, other players, falls, or environmental hazards -- will produce the bleeding status effect. Players still take the initial hit damage from the attack, but no ongoing health drain follows. The damage is a one-time event, and once the hit lands, the player's health stops decreasing (until the next hit). When set to true, certain attacks can cause bleeding alongside the hit damage, initiating a health drain that continues until the bleed is treated or resolves naturally.

Can_Stop_Bleeding controls whether bleeding heals automatically over time. When set to true, a bleeding player will eventually stop bleeding on their own if they survive long enough without taking additional damage. The timing is governed by Bleed_Regen_Ticks. When set to false, bleeding is permanent until the player uses a bandage, medkit, or similar item. Without active treatment, the player will take bleed damage ticks indefinitely until they die.

These two keys create a similar model space to the leg keys. Both false: bleeding never starts, so the timing keys are irrelevant -- the server has no bleed mechanic at all. Can_Start_Bleeding true and Can_Stop_Bleeding false: bleeding can start but will not stop without medical intervention, creating strong pressure to carry bandages at all times and making every fight a potential death sentence if the player runs out of medical supplies. Both true: bleeding can start but resolves naturally if the player survives long enough, so bandages are a convenience that speeds recovery rather than a hard requirement for survival.

Bleeding: damage and recovery speed

Bleed_Damage_Ticks determines how frequently a bleeding player takes damage. Each tick of this counter inflicts health loss while the bleed status persists. Lower values mean damage ticks arrive more often, so a bleeding player loses health faster and dies sooner if untreated. Higher values space the damage ticks further apart, giving the player more time between each increment of health loss to find treatment or wait for natural recovery.

Bleed_Regen_Ticks sets how quickly the bleed status clears on its own when Can_Stop_Bleeding is true. Lower values mean the bleeding stops sooner; higher values mean the player endures more damage ticks (and thus more total health loss) before the wound closes. The relationship between these two keys determines the total health cost of an untreated bleed. If Bleed_Damage_Ticks is low (frequent damage) and Bleed_Regen_Ticks is high (slow recovery), a single bleed event subjects the player to many rapid damage ticks over a long period, which can be lethal. If both are balanced -- moderate damage rate, moderate recovery speed -- a bleed is a manageable pressure that encourages the player to find cover, wait, and avoid further damage until the bleed clears.

Experience gain modifier

Experience_Multiplier is a float that scales every source of experience points on the server. It applies globally to all activities: killing zombies, harvesting resources, crafting items, fishing, completing quests or objectives, and any other action that awards XP. A value of 1.0 means normal XP rates. A value of 2.0 doubles all XP gain, meaning players level up and unlock skills twice as fast. A value of 0.5 halves all XP gain, effectively doubling the time investment required to reach the same skill levels.

This key is independent of Skill_Cost_Multiplier, which is discussed below under death penalties. The two keys together form the server's progression economy. Experience_Multiplier controls how fast XP enters the economy. Skill_Cost_Multiplier controls how much XP leaves the economy each time a player buys a skill. The combination determines how many skills a player of a given playtime will have unlocked.

Death penalties

When a player dies, the game applies a configurable set of penalties: the player loses some combination of skills, skill levels, experience points, and inventory items. The Players section separates every penalty into a PvP variant (death caused by another player) and a PvE variant (death caused by zombies, animals, hunger, thirst, fall damage, drowning, or any other non-player source). This split lets you design distinct risk profiles: dying to the environment can be more or less punishing than dying to another player, depending on the server's goals.

Understanding the two-tier skill penalty system

Skill loss on death works through two independent mechanisms that apply sequentially: a percentage retention and a flat level subtraction. Understanding the order of operations is important because the two mechanisms interact.

The percentage retention keys -- Lose_Skills_PvP and Lose_Skills_PvE -- are float values between 0 and 1. Despite their "Lose" prefix in the key name, they actually represent how much the player retains. A value of 1.0 means the player retains all of their skill levels and loses nothing. A value of 0.75 means the player retains 75% of their levels and loses the remaining 25%. A value of 0.0 means the player loses everything and all skills reset to zero.

The flat subtraction keys -- Lose_Skill_Levels_PvP and Lose_Skill_Levels_PvE -- subtract a fixed number of levels from every skill after the percentage retention is applied. These are uint values, representing whole numbers of levels. If a player has 10 levels in a skill, Lose_Skills_PvP is 1.0 (full retention from the percentage step), and Lose_Skill_Levels_PvP is 2, the player drops from 10 to 8 levels in that skill. If the flat subtraction would push a skill below zero, the result is clamped to zero -- a skill cannot go negative.

The two mechanisms combine in order. The game first applies the percentage retention step to determine the base value after proportional loss, then subtracts the flat level count from that base. Here is the full sequence for a player with 20 levels in a skill, Lose_Skills_PvP set to 0.5, and Lose_Skill_Levels_PvP set to 3:

1. The game applies Lose_Skills_PvP (0.5). The player's 20 levels are multiplied by 0.5, yielding 10 levels remaining.
2. The game applies Lose_Skill_Levels_PvP (3). Three levels are subtracted from the remaining 10, yielding 7 levels remaining.
3. The result is clamped to a minimum of zero. Since 7 is above zero, the final level is 7.

If the same player had only 4 levels in the skill, step 1 would yield 2 levels remaining (4 times 0.5), step 2 would attempt to subtract 3 (resulting in negative 1), and step 3 would clamp the result to 0. The skill would be wiped.

A server owner who wants death to cost a fixed, predictable penalty regardless of how high the player has levelled could set Lose_Skills to 1.0 (no percentage loss) and Lose_Skill_Levels to a modest number like 2 or 3. Every death costs exactly that many levels per skill, whether the player had 5 levels or 50. A server owner who wants death to be proportionally punishing -- hitting high-level players harder in absolute terms than low-level players -- could set Lose_Skills to 0.75 or 0.5 and Lose_Skill_Levels to 0. The percentage mechanism naturally scales with the player's investment, so an endgame player with maxed skills loses far more levels than a new player with only a few.

Experience point loss on death

Lose_Experience_PvP and Lose_Experience_PvE are float values between 0 and 1 that represent what fraction of the player's accumulated, unspent experience points they keep after death. These keys govern the XP pool -- the number that sits on the player's HUD and can be spent on skill purchases -- not the skill levels. A value of 1.0 means the player retains all accumulated XP. A value of 0.5 means they lose half of their current unspent XP. A value of 0.0 means all unspent XP is wiped.

Unlike skill levels, which are partially protected by the skillset keys discussed below, there is no specialisation-based protection for XP loss. If Lose_Experience_PvP is set to anything below 1.0, a PvP death will always cost some fraction of the player's unspent XP, regardless of their specialisation. The server owner's decision here is about whether XP should function as a safe bank that the player can accumulate without risk (by setting both to 1.0) or as a volatile resource the player is incentivised to spend before risking combat (by setting one or both below 1.0). When XP is volatile, players must make a constant tactical choice: do I save XP to buy an expensive high-tier skill, or do I spend now on smaller upgrades to avoid losing progress on death?

Inventory and equipment loss

When a player dies, their carried items can drop to the ground where they remain for other players to pick up, or for the original player to recover by returning to their death location. The following keys determine which items drop and which stay with the player through death.

Lose_Items_PvP and Lose_Items_PvE are float values between 0 and 1 that represent the per-item chance of dropping when the player dies. The game evaluates this percentage independently for each item in the player's inventory. A value of 0.5 means each individual item has a 50% chance of dropping when the player dies. A value of 1.0 means every item drops -- no roll, all items hit the ground. A value of 0.0 means no items drop at all -- the player respawns with their full inventory intact, as if death had not occurred.

Lose_Clothes_PvP and Lose_Clothes_PvE are boolean keys that determine whether equipped clothing items drop on death. When set to true, every piece of clothing the player is wearing -- shirt, pants, vest, hat, backpack, and any other worn slot -- falls to the ground as a dropped item. This matters beyond the cosmetic loss because many clothing items in Unturned provide inventory storage slots that expand the player's carrying capacity. When clothing drops, any items stored inside those clothing slots are forced to drop as well, regardless of the individual Lose_Items roll for each contained item. The contained items follow their container: if the backpack drops, everything inside the backpack drops with it.

This container-dependency rule means the practical impact of Lose_Clothes can be much larger than just losing the clothing items themselves. If a player is wearing a backpack full of supplies, a vest full of ammunition, and cargo pants full of medical items, and Lose_Clothes_PvP is true, every piece of clothing drops and all contained supplies come with it. The Lose_Items percentage is irrelevant for contained items because the container dropping forces their drop. If Lose_Clothes_PvP is false, the clothing stays on the player, and the supplies inside are subject only to their individual Lose_Items rolls -- each supply item gets its PvP percentage chance of dropping independently.

Lose_Weapons_PvP and Lose_Weapons_PvE are boolean keys that determine whether the player's equipped primary and secondary weapons drop on death. When set to true, the weapons in the two dedicated weapon slots (typically the primary long gun or bow, and the secondary pistol, melee weapon, or tool) fall to the ground. The hotbar items, tools, consumables, and other held items are not covered by this key; they are governed by the Lose_Items percentage instead. This separation lets a server owner create a specific rule for weapons that differs from the general inventory rule. For example, you might set Lose_Items_PvP to 0.5 (half of all items drop) and Lose_Weapons_PvP to true, meaning weapons always drop while other items only have a 50% chance.

The complete item-loss model on death is the combination of all three pairs: the per-item percentage, the clothing boolean, and the weapons boolean. Understanding how they interact helps avoid unintended configurations. If Lose_Items_PvP is 0.0 but Lose_Clothes_PvP is true, the player drops all clothing and everything stored in clothing, but items in non-clothing inventory slots are safe. If Lose_Weapons_PvP is true and Lose_Items_PvP is 0.0, weapons drop but other items are safe. If all three are set to true or 1.0 in the PvP column, the player drops absolutely everything on a PvP death.

Skill cost modifier

Skill_Cost_Multiplier is a float that scales the experience point cost of purchasing or upgrading any skill in the skill tree. A value of 1.0 means skills cost their normal amount of XP. A value of 2.0 doubles every skill purchase price across the entire tree. A value of 0.5 cuts all skill costs in half. This multiplier applies globally to every skill; you cannot set different costs for different individual skills through this key alone.

The relationship between Skill_Cost_Multiplier and Experience_Multiplier is important for progression tuning. Experience_Multiplier controls how fast XP enters the economy -- how much XP a player earns from activities. Skill_Cost_Multiplier controls how much XP leaves the economy each time a player buys or upgrades a skill. The two together determine net progression speed. If Experience_Multiplier is 2.0 and Skill_Cost_Multiplier is 0.5, XP comes in twice as fast and costs half as much, resulting in roughly 4x effective progression speed. If Experience_Multiplier is 0.5 and Skill_Cost_Multiplier is 2.0, XP comes in half as fast and costs twice as much, resulting in roughly 0.25x effective progression speed. Most servers pick one lever to adjust and leave the other at 1.0 for simpler reasoning about progression rates.

Respawn

This group controls what state a player returns in when they respawn after death, how the specialisation (skillset) system interacts with skill costs and death penalties, and several toggles that shape the spawn experience.

Initial skill state at spawn

Spawn_With_Max_Skills is a boolean that, when set to true, gives every newly spawned player the maximum possible level in every skill. The practical effect is that the entire skill progression system is removed. Players arrive in the world fully capable, with every ability unlocked at its highest tier, and have no skills to train or upgrade. This configuration is common on PvP arena servers where balance depends on everyone having identical capabilities, and on roleplay servers where skill grinding is not part of the intended player experience. When set to false or left at its default, players begin with the standard base skill levels -- typically zero in most skills -- and must earn upgrades through gameplay.

Spawn_With_Stamina_Skills is a more targeted version of the above. When set to true, newly spawned players receive maximum levels in four specific stamina-related skills: cardio, diving, exercise, and parkour. All other skills remain at their default starting levels. These four skills primarily affect how long the player can sprint before exhausting, how long they can hold their breath while underwater, and how efficiently they traverse the world. By maxing only the stamina skills, you remove the early-game frustration of running out of breath constantly -- which disproportionately affects new players who do not yet know the map well enough to plan efficient routes -- while preserving the full progression loop for the combat, crafting, healing, and survival skill categories. A player still needs to earn their combat skills, but they can run between objectives without stamina being the limiting factor.

If both Spawn_With_Max_Skills and Spawn_With_Stamina_Skills are true, the broader key takes precedence: all skills are maxed, so the stamina-specific key adds nothing further. The stamina key only produces a distinct outcome when Spawn_With_Max_Skills is false. You can use this interaction intentionally: set the broader key to false to keep skill progression in place, then set the stamina key to true to give players mobility without giving them power.

Specialisation bonuses

The skillset system in Unturned lets each player choose a specialisation -- such as offence, defence, or support -- that defines their character's role. Two keys control how that specialisation interacts with the skill economy and death penalty system.

Skillset_Reduces_Skill_Cost defaults to true. When enabled, any skill that belongs to the player's chosen specialisation costs half the normal experience to purchase or upgrade. Skills outside the specialisation cost the standard amount. This discount interacts with Skill_Cost_Multiplier multiplicatively. If Skill_Cost_Multiplier is set to 2.0 (double all costs) and a skill is within the player's specialisation, the effective cost is 2.0 multiplied by 0.5, which equals the normal base cost. The specialisation discount offsets the global markup. The mechanic rewards players for developing the skills that match their chosen role: an offence-specialised player gets cheaper combat skills, a support-specialised player gets cheaper healing and repair skills. This encourages specialisation rather than generalist builds where every player tries to max every skill.

Skillset_Prevents_Skill_Loss defaults to true. When enabled, any skill within the player's specialisation is completely immune to the death penalty keys. Even if Lose_Skills_PvP is set to 0.0 (the player loses everything on death) and Lose_Skill_Levels_PvP is set to a high number (flat subtraction from every skill), the specialisation skills remain untouched at their full current levels. Only skills outside the specialisation are subject to the death penalty calculations. This protection preserves role identity through death: a medic always retains their healing skill levels, a builder always retains their crafting and construction skills, regardless of how many times they die. In gameplay terms, this means a player can die repeatedly and still perform their role for their group, even if their non-specialisation skills have been reduced.

Setting this key to false removes the protection. All skills are equally vulnerable to death penalties, regardless of specialisation. The player's specialisation choice becomes a purely economic decision (which skills are cheaper to buy) rather than a safety net. A string of bad deaths can strip a medic of their healing capabilities as thoroughly as it strips their combat skills.

Level override prevention

Prevent_Level_Skill_Overrides is a boolean that, when set to true, blocks external sources from modifying skill starting levels, skill costs, and maximum skill levels. The main external sources that might try to override these values are workshop mods and server plugins that adjust the skill system to fit their own balance models. When this key is true, the server tells the game engine to use only the base game's hardcoded skill configuration and to ignore any modifications from loaded addons.

When this key is false or left at its default, mods are free to override skill parameters. This is the expected behaviour on most modded servers: if a mod says a particular skill should start at level 5 instead of level 0, or that the maximum level for a skill should be 10 instead of 7, or that skill costs should follow a different curve, those overrides take effect. Setting this to true is a lockdown measure for servers that want strict vanilla skill progression even when mods are installed -- for example, a server that uses mods for map content and items but wants the skill system to remain exactly as the base game defines it.

Headshot behaviour

Allow_Instakill_Headshots is a boolean that governs whether weapons with the instakill-headshots property bypass armour when they land a headshot. In the Unturned weapon system, certain weapons -- predominantly sniper rifles and some high-calibre firearms -- are flagged with a special property that enables instant-kill headshots. When this key is true, a headshot from such a flagged weapon ignores the target's armour multiplier entirely. The shot deals its full base damage directly to the target's health, without any damage reduction from worn armour. When this key is false, armour applies its normal damage reduction even on a headshot from an instakill-capable weapon. The headshot still does bonus damage as a headshot normally would, but armour reduces that damage per its usual rules.

This key only affects weapons explicitly tagged with the instakill-headshots property in the game's weapon data. It does not make all weapons capable of bypassing armour on a headshot. A pistol, submachine gun, or assault rifle that lands a headshot will still have its damage reduced by the target's armour, regardless of how this key is set, unless that specific weapon also carries the instakill-headshots property flag.

Per-character save data

Allow_Per_Character_Saves is a boolean that controls how player save data is organised and persisted on the server. When set to true, each character slot on a player's account receives its own independent save file. Skills, inventory contents, position on the map, and all other persisted player state are separate per character slot. Switching to a different character slot -- for example, from slot 1 to slot 2 in the character selection menu -- gives the player a completely fresh character with independent skills, independent inventory, and an independent position in the world.

When set to false, all character slots on a single account share one save file. Switching characters does not change the player's skills, inventory, position, or any other persisted state. The character slot becomes purely a cosmetic choice: a different visual appearance (name, skin colour, hair, face) with the same underlying game progress and inventory.

This key matters most on servers where players might want to maintain distinct characters for different playstyles. With per-character saves enabled, a player could run a dedicated builder character with high crafting and construction skills in slot 1, a dedicated combat character with high offence and defence skills in slot 2, and a dedicated scavenger or farmer character in slot 3 -- each on a different slot with completely independent progression, inventory, and world position. With shared saves, the player effectively has one character spread across multiple cosmetic appearances.

Movement and stamina

This group covers keys that affect how players interact with the world through detection, distance-based combat events, mobility consequences from leg damage, and an anti-cheat skin-colour check. These keys do not directly set movement speed values or stamina consumption rates -- those are governed by the game's skill system and creature data -- but they shape the player's experience of moving through and being perceived within the game world.

Detection radius

Detect_Radius_Multiplier is a float that scales the distance at which zombies and animals detect a player. Every zombie type and animal type in Unturned has a base detection radius defined in its individual creature data asset. This key takes that base radius and multiplies it globally for all creatures on the server. A value of 1.0 uses each creature's default detection range without any modification -- the server respects whatever detection distance the creature data specifies. A value of 0.5 halves the detection radius across the board, letting players get much closer to threats before being noticed, which makes stealth and avoidance viable strategies. A value of 2.0 doubles the detection radius, meaning creatures spot the player from much further away, making encounters harder to avoid.

The practical gameplay effect is about player agency and encounter control. With a low detection multiplier, players can choose whether to engage or avoid most encounters. They can sneak through towns and past zombie groups by moving carefully and staying outside the reduced detection range. With a high detection multiplier, encounters are more often forced because creatures notice the player from a distance -- the player does not get to choose when a fight starts. This key is particularly relevant on servers with large, open maps (such as the official PEI or Russia maps) where long sightlines mean detection checks happen at range.

This key applies uniformly to both zombies and animals. There is no separate multiplier for each creature type within the Players section. If you want different detection ranges for zombies versus animals on the same server, that differentiation must come from editing the creature data assets themselves, which is outside the scope of Config.json.

A useful way to think about this key is in terms of encounter pacing. On a server with Detect_Radius_Multiplier set to 0.5, a player walking through a town will only trigger zombies they pass close to. They can choose their fights. On a server with the multiplier at 2.0, a player entering a town may trigger every zombie within a wide radius, turning a simple supply run into an overwhelming horde event. The choice is about whether zombies are obstacles the player can navigate around or threats that demand constant combat.

Aggressor distance

Ray_Aggressor_Distance is a float that defines the proximity threshold for marking a player as the aggressor in a combat event. When a projectile -- a bullet, arrow, rocket, thrown item, or any other fired or launched object -- travels through the game world, the server traces its path from the firing point along its trajectory. If that traced path passes within the distance defined by this key of another player's position, the shooter is recorded as having taken an aggressive action against that player, even if the shot did not actually hit.

This mechanic matters for several server-side systems. The PvP/PvE death penalty split discussed earlier uses the aggressor flag to determine whether a death was caused by another player (activating the PvP penalty column) or by the environment (activating the PvE penalty column). Server plugins commonly read aggressor data for kill-feed messages, combat-logging detection, anti-griefing protection, PvP flagging and reputation systems, and admin logging. The distance value set here determines how close a shot must pass to count as aggression. A small value means only near-misses and direct hits register as hostile actions -- a shot that passes well wide of a player is treated as neutral. A large value means even a shot that passes at some distance from a player registers as aggression, which could lead to false positives if players are fighting in the same general area but not actually targeting each other.

Tuning this key is about finding the right threshold for your server's playstyle and typical engagement distances. On a close-quarters urban map where most combat happens within a few metres, a small value works well because near-misses are rare and every shot that passes close to a player was likely aimed at them. On an open-field map where sniping at long range is common, a larger value may be needed to ensure that shots fired at a distant player are correctly attributed as aggression even if they miss by a margin. A value that is too large creates false positives; a value that is too small lets players fire near each other without the server recognising it as PvP activity.

Falling and mobility

The leg-damage keys Can_Hurt_Legs and Can_Break_Legs were covered in detail above under health and stat regeneration, but they merit a second discussion here because their primary gameplay impact is on movement. A server owner thinking about health asks "how much damage did the fall deal?" A server owner thinking about movement asks "can the player still run after the fall?" Both questions are answered by the same keys, and the answer depends on which boolean gates are open.

When Can_Hurt_Legs is false, the player never takes fall damage and their movement is never interrupted by a sudden health drop from a long drop. Steep terrain, cliffs, rooftops, and watchtowers become freely navigable vertical shortcuts with no penalty. When Can_Hurt_Legs is true but Can_Break_Legs is false, falls deal health damage but never inflict the broken-leg movement penalty. The player may lose health from a bad jump but retains full sprint and movement speed. When both are true, a long fall both hurts the player's health bar and potentially cripples their movement speed through the broken-leg status until the leg heals or is splinted.

Together with Can_Fix_Legs and Leg_Regen_Ticks, these four keys form the complete fall-consequence system. A server that wants vertical movement to be risky and consequential sets all three booleans to true and Leg_Regen_Ticks to a moderate or high value -- the player is punished for careless movement with both health loss and temporary crippling, and the crippling lasts long enough to matter during the session. A server that wants players to move freely through all three dimensions without worrying about falls sets Can_Hurt_Legs to false and renders the three downstream keys irrelevant. A server that wants an intermediate position -- falls hurt but never cripple, so players can still run after a bad jump -- sets Can_Hurt_Legs to true and Can_Break_Legs to false.

The connection between the leg keys and movement is the most important design question in this group. Is your server's map vertical? Does it reward players who take risky climbing routes, or punish them? The answer determines whether the leg keys should be permissive or punitive. A flat map with little verticality can use punitive settings without much gameplay impact because players rarely fall. A mountainous or urban map with tall buildings will see constant fall events, and punitive settings will dominate the player experience.

Terrain colour anti-cheat check

Enable_Terrain_Color_Kick is a boolean that defaults to true. When enabled, the server performs a comparison each time a player joins the server or changes their character appearance: it evaluates the player's chosen skin colour against the dominant terrain colours of the currently loaded level. If the skin colour is determined to be too close to one of the terrain colours -- close enough to provide a camouflage advantage that the game's designers did not intend -- the player is automatically kicked from the server.

The purpose of this check is anti-cheat. In Unturned, a player can set their character's skin colour freely in the character customisation menu. A player who selects a skin colour that closely matches the ground colour, wall colour, or foliage colour of a specific map gains a visual advantage because other players have difficulty spotting them against the matching background. This advantage is not part of the intended game balance, so the terrain-colour kick acts as a server-side enforcement mechanism that prevents players from joining with a camouflage skin tone. Setting this key to false disables the check entirely and allows any skin colour, including terrain-matching colours.

This key only checks the player's skin colour. It does not evaluate clothing colours, weapon skins, vehicle colours, or any other cosmetic element. If a player chooses a safe skin colour but wears clothing items that happen to blend into the environment, that is not caught by this check. The protection is narrow: it targets only the specific exploit of using skin colour as camouflage.

On a roleplay or PvE server where player-versus-player spotting is not a competitive concern, setting this to false removes an unnecessary restriction and lets players choose whatever skin colour fits their character concept. On a PvP server, keeping this true prevents one category of unfair visual advantage and is recommended.

Canned Beans

The Players section of Config.json has no keys that reference Canned Beans or any other specific food item. Food and water are governed entirely through abstract meter values: Food_Default sets the starting food level, Food_Use_Ticks controls how fast the food meter drains during normal gameplay, and Food_Damage_Ticks controls how fast starvation kills once the meter reaches zero. None of these keys name a consumable item, assign an item ID or GUID, or connect to any particular food or drink entry in the game's item data tables.

This absence is worth stating plainly because Canned Beans occupy a recurring and well-recognised role across the broader Unturned ecosystem. They are the game's most iconic starter food item, appearing frequently in civilian loot tables, kitchen counters, and grocery store spawns across every official and community map. In many Unturned servers, a new player's first meaningful action after spawning is finding and consuming a can of beans to stabilise their falling food meter. The can of beans has become a community symbol -- shorthand for the survival loop itself, a meme that every Unturned player understands regardless of how many hours they have in the game.

But the behaviour of that specific can -- how many food points it restores when consumed, how long the consumption animation takes, whether it can be crafted into other recipes like bean soup or bean salad, whether it spawns in certain container types at certain probability rates -- is all defined in the game's item data assets, spawn table configuration files, and crafting blueprint data. None of those systems live in Config.json, and none of them live in the Players section. The Players section only governs the meter itself: its capacity, its drain rate, its damage rate at zero. The item data governs the bean.

When a player eats a Canned Bean, the game looks up the item's data definition to learn how many food points that specific bean restores, adds that number to the player's current food meter, and then the Players section's depletion tick keys (Food_Use_Ticks and Food_Damage_Ticks) take over from there to determine how fast that restored food value drains away again. The Players section is the rules of the meter. The item data is the value of the bean. The two systems are connected because the bean feeds the meter, but they are configured in entirely different places.

If you want to change how much hunger a Canned Bean restores when eaten, where it spawns in the world, how often it appears in loot containers, or what recipes it participates in, you need to look at the game's item definition assets (typically .dat files in the game's Bundles directory or served through a workshop mod), spawn table configuration, and crafting blueprint data. None of these are accessible through Config.json, and none of this article's 47 keys will help you adjust bean-specific behaviour. If all you want to do is change how fast players get hungry -- how quickly the meter that beans refill drains -- then Food_Use_Ticks is the key you want, and it lives right here in the Players section.

For the broader cultural role of Canned Beans in the Unturned community, their many appearances across the game's history, and their status as the game's unofficial mascot item, see the Canned Beans lore article.

Practical use for server owners

Choosing a difficulty profile

The Players section is the primary tool for setting your server's difficulty and feel. The 47 keys organise naturally into several high-level tuning dimensions, each corresponding to a distinct aspect of the player experience.

Note that Unturned's Config.json also contains three difficulty preset sections: "Easy", "Normal", and "Hard". These presets may set default values for some of the keys in the Players section. The exact relationship -- whether the Players section overrides the difficulty preset, whether the preset overrides the Players section, or whether they combine -- depends on the server version and which difficulty the server is running under. If you set a value in the Players section and it does not seem to take effect, check whether the active difficulty preset is overriding it. As a general practice, set the values you care about directly in the Players section and leave the difficulty preset sections at their defaults, or vice versa -- but do not set conflicting values in both places.

Survival pressure is the combined effect of the food, water, and virus systems. To create high survival pressure: lower the starting meter values (Food_Default, Water_Default, Virus_Default) so players begin with deficits they must immediately address. Lower the depletion tick keys (Food_Use_Ticks, Water_Use_Ticks, Virus_Use_Ticks) so meters drain faster during normal gameplay. Lower the damage tick keys (Food_Damage_Ticks, Water_Damage_Ticks, Virus_Damage_Ticks) so reaching zero on any meter kills quickly, creating urgency to act before the meter runs out. To create low survival pressure, reverse every one of these: high starting values, high depletion ticks (slow drain), high damage ticks (slow death).

Combat difficulty has two primary levers. Armor_Multiplier is the global damage scalar: set it below 1.0 to make players tankier and combat more forgiving, or above 1.0 to make every hit more lethal and combat more punishing. Allow_Instakill_Headshots determines whether designated sniper weapons bypass armour on headshots: true for servers where positioning and marksmanship determine fight outcomes, false for servers where armour should provide protection against all damage sources including headshots.

Death consequences are the full PvP/PvE penalty split. A common and effective pattern is to make PvE deaths relatively forgiving (set Lose_Skills_PvE high, near 1.0 for high retention; set Lose_Items_PvE low, near 0.0; set Lose_Clothes_PvE and Lose_Weapons_PvE to false) while making PvP deaths punishing (set Lose_Skills_PvP lower, around 0.5 to 0.75; set Lose_Items_PvP high, around 0.75 to 1.0; set Lose_Clothes_PvP and Lose_Weapons_PvP to true). This split creates a world where the environment is dangerous but not demoralising -- a zombie death is a setback, not a wipe -- while player-versus-player combat carries high stakes where winning means taking your opponent's gear and losing means surrendering yours.

Progression speed is controlled by the combination of Experience_Multiplier and Skill_Cost_Multiplier. A fast-progression server might set Experience_Multiplier to 2.0 and leave Skill_Cost_Multiplier at 1.0. A slow, deliberate server might set Experience_Multiplier to 0.5 and Skill_Cost_Multiplier to 2.0. The Spawn_With_Max_Skills and Spawn_With_Stamina_Skills keys let you bypass progression entirely for specific categories when skill grinding is not part of your server's intended loop.

Common server archetypes

The death-penalty and spawn keys support several established server archetypes with minimal additional configuration beyond the Players section itself.

Hardcore survival. Set Food_Default and Water_Default to 50 or lower so players start with deficits. Set Food_Use_Ticks and Water_Use_Ticks low enough that meters drain significantly within the first several minutes of gameplay. Set Food_Damage_Ticks and Water_Damage_Ticks low so starvation and dehydration kill quickly once a meter hits zero. Set Armor_Multiplier to 1.0 or higher. Set Lose_Skills_PvE to 0.5 or lower (lose at least half of skill levels on death to the environment). Set Lose_Items_PvE to 1.0 (drop everything). Set Lose_Clothes_PvE and Lose_Weapons_PvE both to true. Set Can_Start_Bleeding to true and Can_Stop_Bleeding to false (bleeding requires active treatment with bandages). Set Can_Hurt_Legs to true, Can_Break_Legs to true, and Can_Fix_Legs to false (broken legs require splints; no natural recovery). Every death to the environment is a significant setback, and the world itself is hostile.

Casual PvE. Set Food_Default and Water_Default to 100 so players start fully supplied. Set the depletion ticks high enough that meters drain extremely slowly -- players can go long periods without eating or drinking. Set Armor_Multiplier to 0.5 so players take half damage from all sources. Set Lose_Skills_PvE to 1.0 (retain everything). Set Lose_Experience_PvE to 1.0 (retain all XP). Set Lose_Items_PvE to 0.0 (drop nothing). Set Lose_Clothes_PvE and Lose_Weapons_PvE to false. Set Can_Start_Bleeding to false so bleeding never begins. Set Can_Break_Legs to false so falls never cripple movement. Death is a momentary teleport back to spawn rather than a meaningful penalty; the server experience is about building, exploring, and cooperating without frustrating setbacks.

PvP arena. Set Spawn_With_Max_Skills to true and Spawn_With_Stamina_Skills to true so every player arrives fully capable regardless of playtime. Set Lose_Items_PvP to 1.0 (full loot drop on death to another player). Set Lose_Clothes_PvP to true and Lose_Weapons_PvP to true. Set Lose_Skills_PvP to 1.0 (no skill loss from PvP death) so players always fight at equal capability. The Spawn_With_Max_Skills key ensures a level playing field regardless of how long any individual player has been on the server. Gear -- not skill levels -- is the differentiator between players, and gear changes hands through combat.

Roleplay server. Set Lose_Clothes_PvP and Lose_Clothes_PvE both to false so players always keep their outfits on death, preserving their character's visual identity. Set Lose_Weapons_PvP and Lose_Weapons_PvE to false so faction-assigned or service weapons persist through death and do not need to be re-issued by faction leadership. Set Skillset_Prevents_Skill_Loss to true so career-defining specialisation skills are protected from death penalties -- a medic remains a medic, a mechanic remains a mechanic. Set Lose_Skills_PvE to 1.0 and Lose_Experience_PvE to 1.0 for full retention, so death does not disrupt character progression narratives. Set Armor_Multiplier to 0.5 or 0.75 if combat should be forgiving and not disrupt ongoing roleplay scenes, or at 1.0 if combat should carry dramatic weight. Set Allow_Instakill_Headshots to false so armour always provides protection, preventing one-shot kills that abruptly end narrative scenarios. Set Can_Hurt_Legs to false so players never take fall damage -- roleplay servers often feature constructed buildings, rooftops, and scenic overlooks where falls should not be a gameplay concern. Optionally set Spawn_With_Stamina_Skills to true so players can move freely without stamina management interrupting roleplay.

Testing your configuration

After editing the Players section, restart the server and systematically verify each change from a player's perspective. Testing is not optional: tick-based keys in particular are hard to reason about from numbers alone, and the only reliable way to know whether a drain rate or regeneration speed feels right is to experience it in-game. The following checklist covers the major systems in a logical order, building from passive observation to active death-and-respawn testing.

For each test step, join the server as a normal player (not an admin, unless admin status changes how the game processes your character -- if in doubt, test as a regular player to see what your community will see). Keep notes on which keys you changed and what values you set, so you can correlate what you observe with what you configured.

1. Spawn a fresh character. Open the player HUD and check the health, food, water, and immunity values against what you set in Health_Default, Food_Default, Water_Default, and Virus_Default. Open the skills menu and verify that Spawn_With_Max_Skills and Spawn_With_Stamina_Skills are behaving as expected by checking the affected skill levels. If you set Allow_Per_Character_Saves to true, switch to a different character slot and confirm the second character has independent skills and inventory.

2. Let the meters drain. Stand idle or perform light activity (walking, harvesting a tree) and watch the food, water, and virus meters. Note how quickly each bar decreases. If you set aggressive depletion tick values, confirm that players have enough time to reach a likely food or water source on your map before hitting zero. If meter drain is too fast, raise the _Use_Ticks values. If it is too slow, lower them.

3. Reach zero on each meter. In separate tests, starve yourself (let food hit zero), dehydrate yourself (let water hit zero), and let virus immunity hit zero. Each time, observe how quickly the damage ticks arrive and how much health you lose per tick. Confirm the pace matches your design intent. If Food_Damage_Ticks is supposed to kill slowly, verify that a player can realistically survive long enough at zero food to find and consume something. If damage is too fast, raise the _Damage_Ticks value. If it is too slow, lower it.

4. Die to a zombie or environmental hazard. After respawning, check your skill levels against what you had before the death and confirm the PvE penalty keys (Lose_Skills_PvE, Lose_Skill_Levels_PvE, Lose_Experience_PvE) are applying the retention and subtraction you set. Check your inventory for dropped items and confirm the Lose_Items_PvE per-item percentage is working. Check whether clothing and weapons dropped based on the boolean keys (Lose_Clothes_PvE, Lose_Weapons_PvE).

5. Die to another player (if PvP is enabled on your server). Repeat the same checks against the PvP penalty keys. Confirm that the PvP and PvE death experiences are distinct if you configured them to be different. If you set PvP deaths to be more punishing than PvE deaths, verify that the difference is noticeable and intentional.

6. Take fall damage. Jump from progressively higher ledges. Start with a short drop and work up to a long fall. Confirm whether Can_Hurt_Legs is allowing fall damage to register. Jump from a height that should trigger a leg break and confirm whether Can_Break_Legs is producing the broken-leg status effect. If legs break, time the recovery period against the value you set for Leg_Regen_Ticks and confirm Can_Fix_Legs is allowing natural recovery if you set it to true. If you set Can_Fix_Legs to false, confirm that the broken leg persists until you use a splint.

7. Get hit until bleeding starts. Engage a zombie or another player and take enough hits to trigger the bleed status. Confirm whether Can_Start_Bleeding is allowing the status to activate. Once bleeding, watch the damage ticks arrive and compare their frequency to the value you set for Bleed_Damage_Ticks. Time the natural recovery period against Bleed_Regen_Ticks and confirm Can_Stop_Bleeding is allowing natural recovery if you set it to true. If you set Can_Stop_Bleeding to false, confirm the bleed persists until you use a bandage.

8. Test specialisation behaviour. With Skillset_Reduces_Skill_Cost set to true, select a specialisation and attempt to purchase a skill inside your specialisation and a skill outside it. Confirm that the specialisation skill costs noticeably less -- specifically, half the cost of the non-specialisation skill. With Skillset_Prevents_Skill_Loss set to true, die and confirm that your specialisation skill levels were untouched while non-specialisation skill levels (if any) were affected by the death penalty keys.

9. Test detection and aggression. Walk toward a zombie from a distance and note the point at which it begins pursuing you. Compare this to the creature's expected detection radius multiplied by your Detect_Radius_Multiplier value. For Ray_Aggressor_Distance, have another player fire past you at varying distances and verify when the aggressor flag triggers. This is harder to test without server logs or a plugin that surfaces aggressor data, but the detection radius test is straightforward.

10. Test terrain colour kick. If Enable_Terrain_Color_Kick is true, attempt to join the server with a deliberately terrain-matching skin colour (for example, green skin on a forest map, tan skin on a desert map). Confirm the server kicks the player. If the key is false, confirm the terrain-matching skin colour is accepted without a kick.

Incremental tuning strategy

Tick-based keys are the most sensitive to small changes. A difference of 10 or 20 on a tick value can be the difference between a meter that drains over the course of an hour and a meter that drains over the course of five minutes. The following approach avoids frustration:

1. Start with a baseline: note the current tick values, or if you are building a fresh config, start with moderate values (neither extremely high nor extremely low).
2. Change exactly one tick key at a time and restart the server.
3. Time the effect with a stopwatch or in-game clock: how many real-time seconds pass between food meter ticks? Between bleed damage ticks? Between health regeneration ticks?
4. Adjust by small increments. If a meter drains too fast, raise the tick key by 50 or 100 and retest. If it drains too slow, lower by the same amount.
5. Once the timing feels right, move to the next tick key.

This methodical approach is slower than changing ten keys at once, but it prevents the situation where you have made multiple changes, the result feels wrong, and you cannot identify which key is responsible for the problem.

Key interaction summary

Key interaction summary

The following is a quick reference for keys that affect each other and should be tuned together rather than in isolation.

• Health_Regen_Min_Food and Health_Regen_Min_Water must both be satisfied simultaneously for health regeneration to occur. Raising only one creates a bottleneck where the other becomes the sole gate on regeneration.

• Food_Use_Ticks and Food_Damage_Ticks form the complete hunger curve. The first controls time-to-zero; the second controls survival time at zero. Changing one without considering the other can produce unintended difficulty spikes.

• Water_Use_Ticks and Water_Damage_Ticks mirror the food pair. The same consideration applies.

• Virus_Infect, Virus_Use_Ticks, and Virus_Damage_Ticks form a three-phase infection timeline. Changing Virus_Infect changes when the clock starts; changing Virus_Use_Ticks changes how fast the clock runs; changing Virus_Damage_Ticks changes how fast death arrives when the clock expires.

• Can_Hurt_Legs, Can_Break_Legs, Can_Fix_Legs, and Leg_Regen_Ticks form a four-key chain where earlier keys gate later keys. If Can_Hurt_Legs is false, the other three are irrelevant. If Can_Fix_Legs is false, Leg_Regen_Ticks is irrelevant.

• Can_Start_Bleeding, Can_Stop_Bleeding, Bleed_Damage_Ticks, and Bleed_Regen_Ticks form the same four-key chain for the bleed system. If Can_Start_Bleeding is false, the other three are irrelevant.

• Lose_Skills and Lose_Skill_Levels apply sequentially: percentage retention first, then flat subtraction. The combined result is the actual post-death skill value. Tune both with awareness of the other.

• Lose_Items, Lose_Clothes, and Lose_Weapons interact through the container-dependency rule. If Lose_Clothes is true, all items stored in clothing drop regardless of the Lose_Items percentage. The Lose_Items percentage only applies to items in non-clothing inventory slots.

• Experience_Multiplier and Skill_Cost_Multiplier together determine net progression speed. Their effects are multiplicative: doubling XP gain and halving skill costs results in four times the effective progression rate.

• Spawn_With_Max_Skills and Spawn_With_Stamina_Skills have a precedence relationship: if the broader key is true, the stamina key adds nothing. The stamina key only produces a distinct result when the broader key is false.

Common configuration mistakes

The following are misconfigurations that produce unintended behaviour even when the JSON is syntactically valid. Each is a case where the numbers are legal but the result is not what the server owner expected.

Setting a [0 to 100] uint key above 100 or below 0. The health, food, water, and virus default keys all accept values from 0 to 100. The game may clamp out-of-range values or treat them as zero, depending on the specific key and version. If you accidentally write 200 for Health_Default, the player may spawn with 200 health -- exceeding the intended maximum -- or the game may clamp it to 100 silently. Either way, the result is not what the key's documented range intends. Stay within the stated bounds.

Confusing the direction of tick keys. Every _Ticks key in this section follows the same rule: lower equals faster, higher equals slower. A server owner who wants food to drain slowly but sets Food_Use_Ticks to a low number (thinking "low food use means slow food use") will get the opposite result: food drains rapidly. Before changing a tick key, confirm which direction you intend by testing with an extreme value first -- set it to a very high number and confirm the meter barely moves, then set it to the desired value.

Setting Lose_Skills to 0.0 alongside a high Lose_Skill_Levels. When Lose_Skills is 0.0, the percentage step reduces every skill to zero. The flat subtraction step then runs on top of zero, and since the result is clamped at zero, the Lose_Skill_Levels value has no practical effect. If your intent was for players to lose a fixed number of levels per death, set Lose_Skills to 1.0 (full retention in the percentage step) and use Lose_Skill_Levels for the flat subtraction. If your intent was to wipe skills entirely, set Lose_Skills to 0.0 and Lose_Skill_Levels to 0.

Enabling Lose_Clothes without understanding the container rule. When Lose_Clothes_PvP or Lose_Clothes_PvE is true, clothing drops and forces all contained items to drop with it, bypassing the Lose_Items percentage entirely for those contained items. A server owner who sets Lose_Items_PvP to 0.2 (only 20% chance per item) but also sets Lose_Clothes_PvP to true has created a system where items in inventory slots may survive but items stored in clothing always drop. If you want all items to follow the Lose_Items percentage, set Lose_Clothes to false.

Setting contradictory regeneration gates. If Health_Regen_Min_Food is set to 90 but Food_Default is 100, a newly spawned player can regenerate health briefly -- until their food meter drops below 91, at which point regeneration stops. The player's regeneration window is only 9 food points wide. If Food_Use_Ticks is also set low (fast drain), that window closes almost immediately. A player who does not immediately eat after spawning may never see health regeneration at all. If your intent is for regeneration to be a common, accessible mechanic, ensure the default values leave a reasonable gap above the regeneration thresholds.

Setting Can_Start_Bleeding to false but tuning Bleed_Damage_Ticks. If bleeding can never start, the damage rate of a non-existent bleed is meaningless. The tick key will never be evaluated because the boolean gate is closed. The same applies to Can_Stop_Bleeding and Bleed_Regen_Ticks, and to Can_Fix_Legs and Leg_Regen_Ticks. When you close a boolean gate, the downstream tick keys become dead configuration. If you find yourself tuning tick values but seeing no effect, check whether the upstream boolean gate is set to false.

Expecting Skillset_Prevents_Skill_Loss to protect XP. The skillset loss prevention key protects skill levels only -- it does not protect accumulated XP. If Lose_Experience_PvP is set to 0.5 (lose half of unspent XP on PvP death), that penalty applies regardless of specialisation. A player with Skillset_Prevents_Skill_Loss set to true will keep their specialisation skill levels on death but still lose half their unspent XP.

Changing values on an existing server

Changing keys in the Players section does not wipe player data, but some changes only apply to future events while others affect all players immediately.

Keys that apply on spawn. Health_Default, Food_Default, Water_Default, Virus_Default, Spawn_With_Max_Skills, and Spawn_With_Stamina_Skills take effect the next time a player respawns or creates a new character. Existing players who are currently alive on the server are not affected until they die and respawn. If you change Health_Default from 100 to 50, a player who is already alive with 87 health stays at 87 health. The new value only applies when they next respawn.

Keys that apply continuously. All tick-based keys (Food_Use_Ticks, Health_Regen_Ticks, Bleed_Damage_Ticks, and every other _Ticks key), multiplier keys (Armor_Multiplier, Experience_Multiplier, Detect_Radius_Multiplier, Skill_Cost_Multiplier), and boolean switch keys (Can_Hurt_Legs, Can_Start_Bleeding, Skillset_Reduces_Skill_Cost, and others) take effect immediately for all players on the server. The next tick cycle, detection check, damage calculation, or skill purchase uses the new value. No respawn or reconnect is required.

Keys that affect death events. All Lose_* penalty keys apply at the moment of death. If you change Lose_Items_PvE from 0.5 to 1.0 and a player dies thirty seconds later, the player experiences the new 1.0 drop rate (everything drops). There is no grace period or grandfathering of old penalty values. If you are making death penalties significantly harsher, announce the change to your player community before the restart so they are not surprised by an unexpectedly punishing death.

Keys that affect character saves. Allow_Per_Character_Saves changes how the server organises save data on disk. Switching this key from false (shared saves) to true (per-character saves) mid-server-life means existing characters may behave unexpectedly: the shared save data may attach to only one character slot, and the other slots may appear as fresh characters. This is the one key in the Players section where changing the value on an established server has the highest risk of confusing or disrupting players. If you need to change this value, plan to do it alongside a full server wipe, or communicate clearly to your players about which character slot retains their progression.

Edge cases and extreme values

Setting any key to its extreme -- zero, maximum, or the logical opposite of its intent -- produces edge-case behaviour worth understanding before you commit to unusual configurations.

Zero starting values. Setting Health_Default to 0 spawns players dead. The server may immediately trigger a respawn loop where the player dies, respawns, and dies again because they keep spawning at 0 health. Setting Food_Default or Water_Default to 0 combined with very fast _Damage_Ticks creates a similar death-loop at spawn. If you want to make survival punishing, use low values like 10 or 20 rather than absolute zero, so the player has at least a few seconds to act before dying.

Very low tick values. Setting a tick key to 1 or 0 means the event fires on every single server tick. For a damage tick like Food_Damage_Ticks, this means the player takes damage every tick, effectively killing them in under a second once the meter hits zero. For a use tick like Food_Use_Ticks, the meter depletes at the maximum possible rate, draining from full to empty in moments. Very low tick values are valid configurations, but they produce behaviour that is indistinguishable from instant death or instant drain. Test with a moderate value first, then lower incrementally until you reach the desired pace.

Very high tick values. Setting a tick key to an extremely high number means the event practically never fires. A Health_Regen_Ticks value in the millions means health regeneration works in theory but never triggers in practice because no player stays alive long enough for the counter to reach its target. This is functionally equivalent to disabling the mechanic but is less clear to anyone reading the config file. If you want a mechanic disabled, use the boolean gate key if one exists (for example, Can_Stop_Bleeding false instead of Bleed_Regen_Ticks at an astronomical value). If no boolean gate exists, a very high tick value is the available workaround.

Zero or negative multipliers. Setting Armor_Multiplier to 0.0 would theoretically reduce all incoming damage to zero, making players invulnerable. The game may or may not enforce a minimum multiplier internally, but a value this low makes combat meaningless. Setting Experience_Multiplier or Skill_Cost_Multiplier to 0.0 means no XP is ever earned or all skills are free. Setting Detect_Radius_Multiplier to 0.0 means zombies and animals never detect players, functionally removing creature AI from the server experience. These extreme values are valid JSON but produce configurations that remove whole gameplay systems. If that is your intent -- for example, a pure building server where zombies should never be a factor -- understand that you are disabling the system entirely, not just tuning it.

Zero retention on all PvE death penalties. Setting Lose_Skills_PvE to 0.0, Lose_Skill_Levels_PvE high, Lose_Experience_PvE to 0.0, Lose_Items_PvE to 1.0, Lose_Clothes_PvE true, and Lose_Weapons_PvE true means a single death to any environmental source wipes the player's entire progression and inventory. On a server where environmental deaths are common (zombie hordes, fall damage, starvation), this creates a death-spiral where a player who dies once has nothing and must rebuild from zero -- and may die again immediately because they have no gear. This is a valid hardcore configuration, but confirm it is what you intend before deploying it to players.

JSON syntax checklist

The Players section lives inside a .json file, so every edit must produce valid JSON syntax. The following are the most frequent errors and how to avoid them.

• Trailing comma after the last key-value pair. JSON does not permit a comma after the final entry in an object. If your Players block ends with "Enable_Terrain_Color_Kick": true, followed by the closing }, the file will not parse. Remove that last comma.
• Missing comma between key-value pairs. Every entry except the last must end with a comma. If you add a new key and forget the comma on the preceding line, the parser will report an error on the line above the new key.
• Quoting boolean and numeric values. In JSON, true and false are unquoted boolean literals. "true" is a string, not a boolean. Similarly, 100 and 0.5 are unquoted numeric literals. "100" and "0.5" are strings. String values where the key expects a number or boolean will cause a type mismatch at runtime.
• Writing fractions or percentages instead of decimals. Float keys must use decimal notation. Write 0.5, not 1/2 or 50%. While some JSON parsers may accept 1 as a valid float for a key expecting a float, writing 1.0 avoids ambiguity about the intended data type.
• Creating nested sub-objects. Every key in the table above is a direct child of the "Players" object. Do not wrap groups of keys inside their own {} sub-objects. The Players section is flat: all 47 keys are siblings at the same nesting level inside the Players object.

Before restarting the server, paste your full Config.json into any online JSON validator or run the server once and check the console for parse errors. The server will report the exact line number of any syntax problem on startup, which makes debugging straightforward if you validate each edit as you go.

Server lifecycle and the Players section

The Players section is typically one of the first parts of Config.json that a new server owner edits, and it is also one of the sections most likely to be revisited as a server matures and its community develops preferences.

New server launch. When launching a server for the first time, start with a clear difficulty thesis. Decide what kind of experience you want to deliver -- hardcore survival, casual building, PvP arena, roleplay -- and set every key in the Players section to support that thesis. Resist the urge to mix-and-match settings from different archetypes. A server where food drains fast (hardcore) but death penalties are trivial (casual) sends mixed signals to players about what the server is asking of them.

Server maturity and community feedback. After the server has been live for a week or more, players will have feedback about the feel of the game. "Food drains too fast" is a comment about Food_Use_Ticks. "I lose everything when I die to a zombie" is a comment about Lose_Items_PvE. "Zombies spot me from a mile away" is a comment about Detect_Radius_Multiplier. When players report these issues, map their complaint to the specific key before making a change. Adjust one key at a time in response to feedback, announce the change, and give the community a session or two to experience the new value before soliciting further feedback.

Seasonal events and temporary rule changes. The Players section supports temporary configuration shifts for events. For a weekend PvP tournament, you might temporarily set Spawn_With_Max_Skills to true, raise Lose_Items_PvP to 1.0, and set Lose_Clothes_PvP and Lose_Weapons_PvP to true -- then revert these changes after the event ends. Keep a backup of your normal configuration before making event changes so you can restore it cleanly.

Server wipes. If you are planning a full server wipe (clearing all player save data and starting fresh), a wipe is the safest time to make large-scale changes to the Players section. Keys that apply on spawn (Health_Default, Food_Default, Water_Default, Virus_Default, Spawn_With_Max_Skills, Spawn_With_Stamina_Skills) will hit every player uniformly on their fresh spawn. Keys that change save behaviour (Allow_Per_Character_Saves) will not confuse players who had existing characters under the old configuration. If you are making significant difficulty increases, pairing them with a wipe ensures all players start on equal footing with the new rules.

Quick-start reference

For server owners who want to jump straight to common configurations without reading every key's explanation, the following are three starting-point templates. Replace the hyphen defaults with the suggested values for your chosen archetype, then tune from there.

Survival server starting point.

Key	Suggested value	Rationale
Health_Default	100	Full health at spawn; the world will reduce it quickly enough
Food_Default	50	Half full at spawn, creating immediate hunger pressure
Water_Default	50	Half full at spawn, matching the food pressure
Food_Use_Ticks	300	Moderate drain; adjust up or down after testing
Water_Use_Ticks	300	Matches food drain for symmetric survival pressure
Armor_Multiplier	1.0	Standard damage; combat is dangerous but fair
Lose_Items_PvE	0.75	Most items drop on PvE death; recovery is possible but costly
Lose_Clothes_PvE	true	Clothing drops; contained items drop with it
Can_Start_Bleeding	true	Bleeding is part of the survival challenge
Can_Stop_Bleeding	true	Bleeding heals naturally, but slowly
Spawn_With_Stamina_Skills	true	Players can move freely; combat skills still require progression

Creative or build server starting point.

Key	Suggested value	Rationale
Health_Default	100	Full health
Food_Default	100	Full food; hunger is not a mechanic on this server
Water_Default	100	Full water; thirst is not a mechanic
Food_Use_Ticks	9999	Effectively no food drain
Water_Use_Ticks	9999	Effectively no water drain
Armor_Multiplier	0.5	Halved damage from all sources
Lose_Items_PvE	0.0	Drop nothing on death
Can_Start_Bleeding	false	Bleeding never occurs
Can_Hurt_Legs	false	Fall damage disabled
Spawn_With_Max_Skills	true	All skills maxed; no progression grind

PvP-focused server starting point.

Key	Suggested value	Rationale
Health_Default	100	Full health
Armor_Multiplier	1.0	Standard damage
Lose_Items_PvP	1.0	Full loot on PvP death
Lose_Clothes_PvP	true	Clothing drops with contents
Lose_Weapons_PvP	true	Weapons always drop
Lose_Skills_PvP	1.0	No skill loss on PvP death
Lose_Experience_PvP	1.0	No XP loss on PvP death
Spawn_With_Max_Skills	true	All skills maxed at spawn
Allow_Instakill_Headshots	true	Snipers bypass armour on headshot
Lose_Items_PvE	0.5	Moderate item loss on PvE death (zombies still matter)

These starting values are not prescriptive; they are a foundation. Run the server with these values, observe how they feel, and tune one key at a time toward your exact desired experience.

Reference notes

Key name conventions

Every key in the Players section follows a consistent naming scheme that can help you locate related keys quickly:

• Keys with a _Default suffix set a starting value for a newly spawned player (e.g., Health_Default, Food_Default).
• Keys with a _Ticks suffix control the timing of a recurring event (e.g., Health_Regen_Ticks, Bleed_Damage_Ticks). Lower values mean the event fires more often.
• Keys ending in _PvP or _PvE are death-penalty keys that apply separately based on the cause of death.
• Keys starting with Can_ are boolean gates that enable or disable a mechanic entirely.
• Keys starting with Lose_ govern what is lost on death, across skills, items, clothing, and weapons.
• Keys ending in _Multiplier are float scalars applied globally (e.g., Armor_Multiplier, Experience_Multiplier).

Knowing these patterns lets you scan the table and quickly identify which keys control starting values, which control timing, and which are toggles.

What the Players section does not control

Several gameplay systems that might seem related to the Players section are configured elsewhere. Being aware of these boundaries prevents the frustration of searching for a key that does not exist.

• Movement speed. The base speed at which players walk, sprint, crouch, and swim is not in this section. These values are defined in the game's core data.
• Stamina consumption rates. While Spawn_With_Stamina_Skills affects starting stamina skill levels, the rate at which stamina drains during sprinting, swimming, or other activities is defined in the skill system, not in Config.json.
• Carry weight and inventory size. The maximum weight a player can carry and the number of inventory slots available are defined in the game's core data and modified by clothing items, not by keys in Config.json.
• Item-specific effects. How much food a specific item restores, how much health a bandage heals, how long a splint takes to apply -- all of these are item-data values, not Players section keys.
• Respawn timer. The delay between death and respawn is not in this section. It is configured elsewhere in Config.json or in the server's command-line settings.
• Zombie and animal stats. Creature health, damage, speed, and detection radius base values are in creature data assets. Detect_Radius_Multiplier scales detection globally but does not change the base values.

If you cannot find a key for a mechanic you want to tune, it is likely not in the Players section. Check the broader Config.json structure, the game's data assets, or workshop mod documentation for the correct location.