Config.json -- Animals, Objects, Mode and UnityEvents

Intermediate25-35 minutesCross-platformConfig.jsonNotepad++

Configuring an Unturned dedicated server involves nine Config.json sections. While Items, Vehicles, Zombies and Players tend to get the most attention because they directly affect what players loot, drive, fight and feel every minute, there are four smaller sections -- Animals, Objects, Mode and UnityEvents -- that control foundational server behaviour and deserve their own reference.

Animals governs wildlife: how fast creatures respawn after being killed, how hard they hit when they attack a player, how much damage they absorb before dying, and how many can exist at once based on the map's size tier. Objects controls world regeneration: how fast interactable objects like fridge doors close, how quickly fuel and water sources partially refill, how long before harvested trees and rocks regrow, how many items they drop, and whether destructible objects like fences repair themselves. Mode is the difficulty-preset layer: the section where Easy, Normal and Hard diverge from each other through multiplicative scaling applied on top of the root configuration. UnityEvents is the chat-messenger permission system: four boolean switches that determine whether server-side and client-side scripts may broadcast messages or execute game commands through the chat pipeline.

Together these four sections contain thirty-one keys. Individually they are small enough to configure in a single editing session. Collectively they control wildlife danger, world persistence, difficulty scaling and chat security -- four concerns that affect every player on your server. This article covers every key in all four sections.

Documentation source: The key names, types and defaults in this article are drawn from the Unturned SDK source classes in PlayConfigData.cs. No value is estimated, extrapolated or derived from community testing.

---

Who this article is for

This article is written for Unturned dedicated server operators who own or edit the server's Config.json and want to understand what every key in the Animals, Objects, Mode and UnityEvents sections does. It assumes you can open a JSON file, read a key name, and change a value. It does not assume prior knowledge of how the game handles wildlife AI, resource timers, difficulty presets or chat messenger security.

If you are brand new to Config.json entirely, start with one of the larger section references -- Items, Vehicles or Zombies -- to get comfortable with the file's structure before tackling these four. If you already know your way around Config.json and need the exact contract for any of these thirty-one keys, this article is the reference.

What you will learn

• What each of the nine Animals keys does: respawn timing, damage scaling, armor scaling, population caps per map tier, and the weapon-damage-profile toggle
• What each of the eight Objects keys does: six reset-timer multipliers, the holiday-loot toggle, and the tree-obstruction boolean
• Why the Mode section is structured as ten nested sub-objects rather than flat keys, how it stacks multiplicatively on top of the root config, and what each of its ten sub-objects governs
• What each of the four UnityEvents keys does, how the server-side and client-side permissions differ, and why the client-side command key is the most important security control in the section
• How to configure all four sections together in a single coherent workflow

How to use this article

Each section opens with a paragraph describing what that portion of Config.json governs at a high level. The verbatim key table follows immediately after. Beneath the table, keys are explained one by one in logical groups. The explanations describe what each key does, how its value is interpreted by the server, what the practical effects of different values are, and -- where relevant -- how the key interacts with other keys in the same section or with the Mode difficulty-preset layer.

If you are looking up a specific key, scroll to its section heading and read the key's explanation. The article is written so that each key's entry is self-contained: you do not need to read earlier keys to understand a later one, except where an interaction is called out explicitly in the text. If you are reading through to understand the full section, the group introductions and transition paragraphs between groups explain how the keys relate to each other.

If you are here because you have an existing Config.json and want to verify that a particular value is correct, use the key tables to confirm the type (float, uint, or bool) and then read the key's explanation to understand what effect your current value is producing. Float keys accept decimal values -- 0.5, 1.25, 3.0 -- and the effect scales linearly with the value. Bool keys accept only true or false. The Mode section's sub-objects accept structured JSON objects matching the root section schemas.

The "Practical use for server owners" section at the end of the article ties all four sections together into a recommended configuration order and a testing checklist. If you are about to edit your Config.json for the first time, read that section before making changes.

How these sections relate

These four sections are independent in Config.json -- each sits in its own top-level block and none of them share keys. But at runtime they interact in important ways that are worth understanding before you start editing values.

The Mode section is the bridge. Every key in the root Animals section has a matching key inside Mode's Animals sub-object, and when the server applies a difficulty preset it multiplies the root value by the Mode value. The same is true for Objects: the root Objects section and the Mode Objects sub-object share keys, and the effective value at a given difficulty is the product of the two. This means that if you set Damage_Multiplier to 2.0 in root Animals and also set it to 1.5 in the Hard Mode Animals sub-object, animals on Hard difficulty deal 3.0 times base damage. The two layers are not alternatives -- they are factors in a multiplication that the server performs at launch.

Animals and Objects do not interact directly. Changing how fast animals respawn does not affect how fast trees regrow. Changing how much damage animals deal does not change how many items trees drop. The two sections are fully independent at the config level. But they interact at the experience level: a server where animals are lethal and resources are scarce feels very different from one where animals are harmless and resources are abundant, even though the two config sections operate independently. When tuning your server, consider the combined experience these sections produce together, not just each section in isolation.

UnityEvents is the most isolated of the four. It does not interact mechanically with Animals, Objects or Mode. Its four booleans control the chat messenger permission pipeline, which runs independently of wildlife, resources and difficulty scaling. The only cross-section consideration is that a server running many chat-active plugins (which typically requires Allow_Server_Messages and Allow_Server_Commands enabled) may want to ensure that the Animals and Objects sections are not so aggressive that plugin messages get lost in a flood of combat and harvest notifications. This is a user-experience concern, not a technical interaction.

---

Animals

The Animals section sits inside the "Animals" block of Config.json. It is a flat object containing nine keys that control every aspect of animal behaviour the server can tune globally. The section is not optional -- the server always reads it, and every key is always present in memory when the server is running. There is no "enable animals" master switch here; if you want to disable wildlife entirely, you set the relevant Max_Instances cap to zero.

All nine keys affect every animal on the server equally. You cannot set one respawn time for wolves and another for deer from Config.json. You cannot make a particular animal species hit harder than others through these multipliers. Per-species tuning lives in the game's individual animal asset data, not in this config file. What Config.json gives you is a set of global levers: raise or lower the threat level across the entire map with a single value change.

The nine keys are organized into three functional clusters. Respawn_Time, Damage_Multiplier and Armor_Multiplier control timing and combat difficulty. The five Max_Instances keys control population density per map size tier. Weapons_Use_Player_Damage switches which weapon damage profile applies to animal targets. The clusters are explained in that order below.

Key	Type	Default
Respawn_Time	float	-
Damage_Multiplier	float	-
Armor_Multiplier	float	-
Max_Instances_Tiny	uint	-
Max_Instances_Small	uint	-
Max_Instances_Medium	uint	-
Max_Instances_Large	uint	-
Max_Instances_Insane	uint	-
Weapons_Use_Player_Damage	bool	-

Respawn timing and the damage pair

The first three keys form a tight cluster. Respawn_Time is a timer that controls how quickly dead animals are replaced. Damage_Multiplier scales the damage animals deal. Armor_Multiplier scales the damage animals receive. Together they set the broad danger level of your server's wilderness. Changing one without considering the other two can produce unintended dynamics. A very short Respawn_Time combined with very low damage output creates a server where animals are constantly present but individually harmless -- a persistent annoyance rather than a threat. A very long Respawn_Time combined with very high damage creates a server where each animal encounter is a rare but potentially lethal event. The relationship between how often players face animals and how dangerous those encounters are is the fundamental tuning problem that these three keys solve together.

Respawn_Time

Respawn_Time is a float that sets the number of seconds the server waits after an animal dies before a replacement animal is permitted to spawn at or near that animal's spawn point. The default value is shown as a dash in the table because the game ships with different defaults for each difficulty preset. The value you set here is the minimum wait -- the server will never spawn a replacement sooner than this many seconds after death.

The server does not guarantee that a replacement appears the instant the timer expires. When the timer fires, the server performs two checks. First, it checks whether the total animal count is below the relevant Max_Instances cap for the current map. Second, it checks whether a valid spawn point exists near the original animal's position. If either check fails -- the population cap is already full or the spawn area is obstructed -- the respawn is deferred. The server will try again on a later tick.

This interaction between Respawn_Time and the Max_Instances caps is important to understand. A very short Respawn_Time combined with a very low population cap will cause the server to skip most respawn attempts because the ceiling is already hit. The effective respawn rate is the slower of the timer and the cap. If your animals do not seem to be respawning despite a low Respawn_Time, check your population cap -- you may have it set too low for the number of animals your map can support at once.

What different values produce in practice: a value of 30 means an animal slot opens for replacement every thirty seconds after the last death at that spawn point. This keeps wildlife pressure roughly constant for players who are actively moving through the map. A value of 300 (five minutes) gives players significant windows of safety after clearing an area. A value of 0 theoretically means animals respawn as fast as the server can process the attempt, which typically results in near-instant replacement -- useful for hunting-focused servers but can feel oppressive to players who are not expecting constant wildlife pressure.

Damage_Multiplier

Damage_Multiplier is a float that scales every point of damage dealt by every animal against every target. At 1.0, animals deal their base damage as defined in their individual data assets. At 2.0, every attack hits for double its base value. At 0.5, every attack hits for half. The multiplier applies globally -- every animal species, every attack type, every map. It is not a per-species tuning knob; it is a master volume control for animal damage output.

The multiplier is applied after the animal's base damage is determined and before any target-side modifiers are calculated. This means the multiplier interacts predictably with the rest of the damage system: doubling the multiplier doubles the post-mitigation damage, assuming all other factors stay the same.

Setting this to 0.0 causes animals to deal zero damage. They still exist, still move, still behave as AI actors -- but their attacks land harmlessly. This is useful on peaceful or building-focused servers where wildlife is meant to be ambient scenery rather than a gameplay threat. Setting it very high (4.0 and above) makes every animal encounter potentially lethal, even against players in full gear. The exact threshold for "lethal" depends on the animal's base damage and the player's equipment, which are not configurable from Config.json.

The Damage_Multiplier interacts with the Mode section's Animals sub-object. The root value here is multiplied by the Mode Animals Damage_Multiplier for the active difficulty. If you set the root to 1.5 and the Hard Mode Animals block also sets Damage_Multiplier to 1.5, animals on Hard difficulty deal 2.25 times base damage. See the Mode section below for a full explanation of how this stacking works.

Armor_Multiplier

Armor_Multiplier is a float that scales every point of damage an animal receives from any source. Despite the word "armor" in the name, this is not literal body armor and it does not interact with armor items, armor values, or any armor-related game mechanic. It is a global incoming-damage modifier applied to animal targets. At 1.0, animals take the full value of whatever damage source hits them. At 0.5, every hit deals half its normal damage -- animals are effectively twice as tough. At 2.0, every hit deals double -- animals go down in half the usual number of hits.

This key sets the "how long to kill" side of wildlife balance. A high Damage_Multiplier makes animals dangerous; a low Armor_Multiplier makes them durable. Together they define four quadrants:

• High damage, low armor: animals hit hard but die quickly. Encounters are brief and punishing. Players who react fast survive; those who hesitate do not.
• High damage, high armor: animals are both dangerous and durable. Every encounter is a significant commitment of ammunition, medical supplies and attention. Suited for hardcore survival servers.
• Low damage, low armor: animals hit weakly but also fold quickly. They are mostly an annoyance rather than a threat. Suited for peaceful or building-focused servers.
• Low damage, high armor: animals are not individually threatening but take a long time to kill. Dangerous primarily because fights drag out and multiple animals can accumulate during an extended engagement.

Setting Armor_Multiplier to 0.0 makes animals invulnerable -- they take no damage from any source. This is a niche setting useful for testing or for specific event scenarios where you want animals to be unkillable environmental hazards. Most servers keep this at or near 1.0 and tune the threat level through Damage_Multiplier instead, since "how hard they hit" tends to be the more immediately felt axis for player experience.

Like Damage_Multiplier, this value stacks multiplicatively with the Mode Animals Armor_Multiplier for the active difficulty preset.

Population caps by map size

The five Max_Instances keys set hard ceilings on the total number of animals that can exist simultaneously on the server. Each key corresponds to one of the five map size tiers that the game uses to classify maps: Tiny, Small, Medium, Large, and Insane.

Map size tiers are a property of the map itself, not something you set in Config.json. The game determines a map's tier based on its dimensions and total playable area. Most curated maps fall into the Medium or Large tier. Very small arena or tutorial maps may be Tiny or Small. The largest full-scale maps may be Insane. When the server loads a map, the game looks up which size tier the map belongs to and uses the matching Max_Instances key as the animal population limit for that session. The other four keys are completely ignored -- they exist in memory but have no effect on the current session.

These caps are total population limits across all animal species combined. If your server is running a Medium map and Max_Instances_Medium is set to 30, the server will never allow more than 30 animals to be alive at any single moment -- regardless of how many different animal species are configured, how many spawn points exist across the map, how many animals are attempting to respawn, or how recently any animal died. When the alive count reaches the cap, every spawn attempt, whether from a Respawn_Time timer expiring or from any other trigger, is blocked until an existing animal dies and frees a slot.

The caps do not distinguish between animal types. There is no guaranteed minimum for any particular species, no predator-to-prey ratio enforced, and no priority system for which animal gets to spawn when a slot opens. The population's species composition is an emergent property of which animals die, which survive, and which spawn points happen to be valid during each spawn attempt. If 30 of one animal type fill the cap on a Medium map, no animals of any other type will spawn until some of those 30 die. Over time, the population mix tends to reflect the relative abundance of different spawn points and the relative survival rates of different species -- but this is a natural outcome of the simulation, not something the cap system enforces.

Setting any cap to zero disables animal spawning entirely for maps of that size tier. Animals that are already alive when the cap change takes effect will remain until killed, but no replacements will spawn. Setting a cap extremely high is constrained by a practical limit: every animal on the server is an AI actor that consumes CPU time. Pathfinding, behaviour decision-making, physics collision and animation all cost cycles per animal per tick. On a server already running many players, zombies, vehicles and other active systems, setting animal caps into the hundreds can contribute to degraded server tick rate. The exact threshold depends on the server's CPU, the map's complexity, and the number of other active systems, all of which vary by deployment. Start conservative (20 to 50 for Medium maps, scaling proportionally for other tiers) and increase gradually while monitoring server performance.

Max_Instances_Tiny

The population cap for maps classified as Tiny. When the server loads a Tiny map, this key sets the maximum number of animals that can be alive at once. All other Max_Instances keys are ignored for that session.

Max_Instances_Small

The population cap for maps classified as Small.

Max_Instances_Medium

The population cap for maps classified as Medium.

Max_Instances_Large

The population cap for maps classified as Large.

Max_Instances_Insane

The population cap for maps classified as Insane.

Weapon damage profile selection

Weapons_Use_Player_Damage

Weapons_Use_Player_Damage is a boolean that switches which damage profile a weapon uses when it hits an animal. In the game's item data, some weapons define separate damage values for different target types -- one value for hitting players, another value for hitting animals. This key decides which profile applies.

When set to true, weapons use their PvP damage value against animals. The weapon behaves the same way whether the target is a player or an animal. This makes weapon performance consistent and predictable: a weapon that performs in a certain way against players will feel similar against animals, subject to the animal's current Armor_Multiplier scaling at the active difficulty.

When set to false, weapons use their animal-specific damage value if the item data defines one. This preserves whatever per-target balancing the item designers intended. A weapon might be tuned to be strong in PvP but deliberately weak for hunting, or vice versa, and this boolean determines which tuning the server respects.

On PvE servers where players never fight each other, there is no PvP balance to protect, so the setting has limited impact -- there is no "PvP damage value" that matters because PvP does not occur. On PvP servers, setting this to true means the weapon-balance decisions made for player-versus-player combat also govern animal combat. Setting it to false keeps the two damage models separate, which can be desirable if the PvP weapon balance was tuned without considering how those same numbers interact with the global Armor_Multiplier.

This key does not create or modify damage values. It only selects which of the existing damage profiles the weapon uses when the target is an animal. If an item data file does not define an animal-specific damage value, the behaviour when this is false is determined by how the game handles the missing value internally.

---

Objects

The Objects section sits inside the "Objects" block of Config.json. It contains eight keys -- six float multipliers that scale internal timers or drop quantities, and two booleans that toggle specific behaviours. Together they control how the server regenerates the world around the players over time.

The six float multipliers all work the same way mechanically. Each one scales a base timer or base quantity that is defined in the game's internal data (not in Config.json). At 1.0, the server uses the default value. At 0.5, the timer is halved or the quantity is halved -- the effect happens in half the time, or yields half the items. At 2.0, the timer is doubled or the quantity is doubled. At 0.0, the mechanic is disabled entirely for that category: the timer never fires, the resource never resets, or zero items drop.

All six multipliers are independent. You can have fast fuel refills alongside slow tree regrowth. You can have abundant resource drops alongside fast rubble repair. None of the multipliers affect anything outside their named category, and none of them interact with each other -- changing Fuel_Reset_Multiplier does not affect water, resources or anything else. Each multiplier is a self-contained dial for one specific category of world-object behaviour.

It is helpful to think of these six keys as three pairs, each controlling one dimension of world persistence:

• Resource economy: Resource_Reset_Multiplier (how fast resources regrow) and Resource_Drops_Multiplier (how many items they yield per harvest). Together these determine how much raw material enters the server economy over time.
• Survival sustain: Fuel_Reset_Multiplier (how fast fuel sources refill) and Water_Reset_Multiplier (how fast water sources refill). Together these determine how accessible the two critical vehicle-and-survival resources are.
• World tidiness: Binary_State_Reset_Multiplier (how fast doors close) and Rubble_Reset_Multiplier (how fast broken objects repair). Together these determine how quickly the world returns to its pristine state after players interact with or damage it.

Key	Type	Default
Binary_State_Reset_Multiplier	float	-
Fuel_Reset_Multiplier	float	-
Water_Reset_Multiplier	float	-
Resource_Reset_Multiplier	float	-
Resource_Drops_Multiplier	float	-
Rubble_Reset_Multiplier	float	-
Allow_Holiday_Drops	bool	-
Items_Obstruct_Tree_Respawns	bool	-

Reset-timer multipliers

The first six keys are timer or quantity multipliers. Each is a float that scales a specific category of world-object behaviour.

Binary_State_Reset_Multiplier

Scales how long before interactable objects that toggle between two states automatically return to their default position. Objects like fridge doors are the canonical example: a player opens a fridge, a timer begins, and when the timer expires the door closes on its own. This multiplier scales that timer for every binary-state object on the map.

At 1.0, each binary-state object follows its own built-in default closing delay, which may differ between object types -- some objects may be designed to close quickly, others to stay open longer. At 0.5, every binary-state object closes in half the time of its default. At 2.0, everything stays open twice as long. At 0.0, binary-state objects never reset automatically -- once opened, they stay open until the server restarts or something else forces them closed.

This multiplier is one of the least impactful settings in Config.json for most servers. It controls cosmetic door behaviour. On high-population servers where dozens of players open and close the same fridge, a slightly lower value (such as 0.5) prevents the world from looking permanently disturbed by keeping doors closed more aggressively. On immersive roleplay servers, a higher value (such as 2.0) makes the world feel lived-in: a door someone opened five minutes ago is still ajar when the next player walks past. Most servers leave this at 1.0 unless there is a specific aesthetic reason to change it.

Fuel_Reset_Multiplier

Scales how long before fuel sources in the world are automatically partially refilled. Fuel sources are objects placed in the map that the game considers fuel containers -- static fuel tanks at service stations and similar map-placed fuel points. When a player draws fuel from a source, the source's fuel level decreases. A refill timer starts, and when it expires the source regains some of its fuel. This multiplier scales how long that timer runs.

At 1.0, refill happens at the default rate built into the game. At 0.5, fuel returns in half the time. At 2.0, drained fuel sources stay depleted twice as long. At 0.0, fuel sources never refill automatically -- once fuel is taken from the world, it is gone until the server restarts or an admin manually restores it.

This key scales only the timer, not the amount of fuel restored per refill. The refill amount is determined by the fuel source object's own data and is not configurable from Config.json. Whether a fuel source refills by 10 percent or 50 percent of its capacity per cycle is a property of the object's asset data, not of this multiplier.

The practical impact of this key depends on how central vehicles are to your server. On a server where most players use vehicles for transport and logistics, fuel is a critical resource and the rate at which it returns shapes the entire economy. A low multiplier (fast refill) keeps fuel abundant and reduces conflict over fuel points. A high multiplier (slow refill) turns fuel stations into contested territory and forces players to plan routes around available fuel. On a server where vehicles are rare or discouraged, this key matters much less.

Water_Reset_Multiplier

Scales how long before water sources in the world are automatically partially refilled. The mechanism is identical to the fuel multiplier above, applied to objects the game classifies as water sources -- wells, water towers, and similar map-placed water points. When a player draws water, the source level drops, a refill timer starts, and this multiplier scales how long that timer runs.

At 1.0, water refills at default speed. At 0.5, water returns in half the time. At 2.0, water sources stay depleted twice as long. At 0.0, water never refills automatically.

On servers with large player groups starting in the same area, water consumption around spawn can be high. A lower multiplier prevents the starting area's water sources from being drained dry within the first hour, which would strand new players without drinkable water nearby. On hardcore survival servers, a higher multiplier forces groups to establish multiple water collection points, make deliberate water-supply runs, or compete for access to limited refilling sources.

Like the fuel multiplier, this key scales only the timer. The amount of water restored per refill is determined by the water source object's data and is not changeable from Config.json. A water source that refills to 20 percent versus 60 percent per cycle is a property of the object, and this multiplier only changes how long the server waits between refill cycles.

Resource_Reset_Multiplier

Scales how long before harvested natural resources -- trees, rocks, and bushes -- regrow. When a player harvests one of these resources, the resource node is removed from the world. After a base regrowth duration (multiplied by this value) elapses, the resource reappears at the same location. This multiplier scales that regrowth duration.

At 1.0, resources regrow at the game's default speed for each resource type. At 0.5, every harvested tree, rock or bush returns in half the time. At 2.0, the landscape stays barren twice as long. At 0.0, once a resource is harvested it never regrows -- the map becomes permanently depleted as players strip it over time.

This is one of the most visible settings for how a server feels over its lifetime. On launch day after a wipe, players race to harvest everything near the spawn area. With a low multiplier, the spawn zone recovers quickly and new players who join later in the day still find trees and rocks to harvest. With a high multiplier, the spawn area becomes visibly deforested within the first few hours, and late-joining players must travel progressively farther from spawn to find intact resources. Many populated servers set this below 1.0 specifically to prevent spawn-area deforestation from punishing players who join after the initial rush.

The multiplier applies uniformly to all natural resource types. There is no separate key for tree regrowth speed versus rock regrowth speed. If you want trees to return faster than rocks, that differentiation must be done in the individual resource asset data, not in Config.json.

Resource_Drops_Multiplier

Scales the number of items that drop when a natural resource is harvested. When a player chops a tree, the tree's item definition determines what items are produced (such as logs and sticks) and how many of each. This multiplier scales that drop count. At 1.0, the item definition is followed exactly. At 2.0, each harvest yields roughly double the defined quantity. At 0.5, yields are roughly halved.

This key is the "how much per harvest" lever, distinct from Resource_Reset_Multiplier which is the "how fast do they come back" lever. The two levers are fully independent, and tuning them together lets you design four distinct resource economies for your server:

• Low drops, fast regrowth: Players harvest frequently but get modest returns each time. The landscape always looks intact because trees come back quickly. Resource gathering is a constant background activity rather than a major driver of player movement. Suited for servers where building is not the primary activity and resources should not be a bottleneck.
• High drops, fast regrowth: Resources are abundant in every sense. Players get a lot per harvest and the world recovers quickly so subsequent harvests are always available. Suited for building-heavy servers where construction demands high material throughput and resource scarcity would frustrate the player base.
• High drops, slow regrowth: Each harvest yields a lot, but the harvested resource stays gone for a while. Players are strongly rewarded for exploring and finding untouched forests or rock formations, since a single harvest from a fresh node is more valuable. Suited for servers that want resource gathering to drive map traversal and reward exploration.
• Low drops, slow regrowth: Resources are scarce on both axes. Every log and stone matters, and the landscape visibly shows the scars of harvesting for an extended period. Suited for hardcore survival servers where material abundance would undercut the core survival challenge.

At 0.0, resources drop zero items when harvested. The resource is still destroyed (and will regrow if Resource_Reset_Multiplier is above zero), but the player receives nothing for the effort. This is rarely useful outside of specific event or challenge scenarios.

Rubble_Reset_Multiplier

Scales how long before destructible objects -- objects the game allows to be destroyed, such as certain fences and barriers -- automatically repair themselves and reappear intact. When a destructible object is broken, a repair timer begins. When it expires, the object reappears in its undestroyed state. This multiplier scales that timer.

At 1.0, repairs happen at the game's default speed for each destructible object type. At 0.5, broken objects reappear in half the time. At 2.0, destroyed objects stay destroyed twice as long. At 0.0, broken objects never repair automatically -- destruction is permanent until a server restart or manual admin restoration action.

For most servers, this is a cosmetic setting. Fast repair keeps the world looking clean and intact. Slow repair means the visual aftermath of events -- broken fences after a fight, smashed barriers after a vehicle crash -- persists visibly for the duration you set. On PvP servers where players break objects intentionally for tactical reasons (clearing sightlines through fence lines, removing cover, breaching barricaded areas), the repair timing has gameplay implications. A short repair timer undermines demolition as a tactic because obstacles return quickly, negating the tactical effort. A long repair timer means tactical destruction has lasting map consequences.

Holiday drops and tree obstruction

The remaining two keys are booleans, not multipliers. They control specific behavioural toggles rather than scaling timers or quantities.

Allow_Holiday_Drops

A boolean that determines whether the game includes holiday-themed items in its drop pools when the real-world calendar date aligns with a supported holiday. For example, during the winter holiday season the game may cause certain world objects to drop special presents that contain weapons or other items. When this key is true, these seasonal drops are active. When false, they are suppressed regardless of the date.

Server owners who want a consistent, predictable loot pool throughout the entire year should set this to false. The sudden appearance of special holiday items because the calendar changed can disrupt a carefully tuned loot economy, especially if the holiday items are significantly different in power or rarity from the normal drop pool. Server owners who enjoy seasonal variety, who run holiday-themed events, or who do not mind the occasional seasonal loot injection can leave this at true.

This key controls only whether holiday items enter the drop table. It does not enable or disable visual holiday decorations on the map, and it does not control any other seasonal mechanic. If your server runs custom maps or plugins that add their own seasonal content, this key does not affect that content -- it only governs the base game's built-in holiday loot system.

Items_Obstruct_Tree_Respawns

A boolean that determines whether barricades or structures placed by players on a tree stump prevent the tree from regrowing while the server is running. When a tree is chopped, a stump remains briefly before disappearing. If a player places any buildable item -- a barricade, a structure piece, a placed object -- on the exact world position of that stump, this key decides whether the tree can regrow through or around the obstruction.

When set to true, player-placed items on stump locations block tree regrowth. The tree stays absent as long as the item remains on that spot and the server remains online. When set to false, the tree ignores player-placed obstructions entirely and regrows regardless -- potentially clipping through floors, walls, or whatever the player built on top of the stump.

This key exists because tree stumps and player building occupy the same world space. Without an obstruction check, every tree cleared for a base would regrow through the base's floor within a few hours, creating constant clipping and visual disruption that undermines the building system. Setting this to true prevents that: clearing trees for a build site actually keeps them cleared for the duration of the server session. The tradeoff is that a malicious player who wants to permanently deforest an area can place small, cheap barricades on every stump to lock the trees out. This griefing vector is typically accepted as a manageable risk on servers where building is a primary activity, because the alternative -- trees growing through player structures -- is more disruptive to the core player experience.

---

Mode

The Mode section is structurally different from every other section in Config.json. Animals, Objects and UnityEvents are flat collections of primitive keys -- floats, unsigned integers and booleans. Mode is a collection of nested configuration objects. Each of its ten keys does not hold a number or a boolean; it holds a complete sub-object whose structure mirrors a root-level config section elsewhere in the file.

The Mode section is the difficulty-preset multiplier layer. The game ships with presets for different difficulty levels. Each preset defines its own Mode block containing ten sub-objects, each containing values tuned to that difficulty. When a server launches on a given difficulty, it reads the root-level config sections as the baseline, then reads the Mode block matching the active difficulty and applies its multipliers on top.

Key	Type	Default
Items	ItemsConfigData	-
Vehicles	VehiclesConfigData	-
Zombies	ZombiesConfigData	-
Animals	AnimalsConfigData	-
Barricades	BarricadesConfigData	-
Structures	StructuresConfigData	-
Players	PlayersConfigData	-
Objects	ObjectConfigData	-
Events	EventsConfigData	-
Gameplay	GameplayConfigData	-

What the Mode section is

The Mode section exists because a single set of config values cannot produce three distinct difficulty experiences. Easy, Normal and Hard need to feel different from each other. If the root config is the only config, then changing the difficulty does nothing -- the server reads the same file regardless. Mode solves this by providing a second layer of configuration that is specific to the active difficulty preset.

The root config is the foundation. It sets the baseline values for every configurable aspect of the server. The Mode blocks are the difficulty levers. Each one contains a copy of the same ten sub-objects -- ItemsConfigData, VehiclesConfigData, ZombiesConfigData, and so on -- but with different values inside. When the server applies a difficulty preset, it takes the root value for each key and multiplies it by the corresponding Mode value for the active difficulty.

This configuration pattern means you do not have to maintain three completely separate Config.json files for three difficulties. You maintain one root config for your Normal baseline, and two Mode blocks (Easy and Hard) that define how those difficulties differ from normal by scaling the baseline up or down.

The Mode block lives inside Config.json, typically appearing as the value of a key named Mode. In a full Config.json file there may be multiple Mode blocks -- one per supported difficulty level, each structured identically with its own ten sub-objects. A Mode block set entirely to 1.0 for every key in every sub-object produces a difficulty that is identical to the root config: no scaling, no divergence. If you only run one difficulty on your server, you can set your Mode block to all 1.0 and tune everything through the root config alone, or you can set root values to 1.0 and tune everything through the Mode block -- the effective result is the same because anything multiplied by 1.0 is unchanged.

The ten sub-objects

Each key in the Mode table is a JSON object, not a primitive value. The keys and types inside each sub-object match the root config section of the same name. The entries below describe what domain each sub-object governs and how it relates to the corresponding root section. For the detailed key-by-key reference of each sub-object's internal structure, consult the corresponding root section article on this knowledge base.

Items (ItemsConfigData)

Item-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to item mechanics -- spawning frequency, durability loss rates, quality distribution, and related item behaviour. The server reads the root Items section as the baseline and multiplies every key by the matching key in this sub-object for the active difficulty. Setting every value here to 1.0 means items behave identically to the root config at this difficulty. Values above 1.0 typically make items more available or more durable (easier); values below 1.0 typically make items scarcer or more fragile (harder).

Vehicles (VehiclesConfigData)

Vehicle-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to vehicle mechanics -- spawn rates, fuel consumption speed, battery drain rate, vehicle health values, and related behaviour. Layers multiplicatively on top of the root Vehicles section. Values above 1.0 typically make vehicles more available or more durable; values below 1.0 typically make vehicles scarcer or more fragile.

Zombies (ZombiesConfigData)

Zombie-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to zombie mechanics -- spawn frequency, damage output, health pools, detection range, and related behaviour. Layers multiplicatively on top of the root Zombies section. Values above 1.0 typically make zombies more numerous, more damaging, or tougher (harder); values below 1.0 typically make zombies fewer, weaker, or more fragile (easier).

Animals (AnimalsConfigData)

Animal-related multipliers for this difficulty preset. This sub-object layers on top of the root Animals section documented earlier in this article. Every key in the root Animals section -- Respawn_Time, Damage_Multiplier, Armor_Multiplier, all five Max_Instances caps, and Weapons_Use_Player_Damage -- has a matching key inside this Mode sub-object. The server reads the root Animals values as the baseline and multiplies them by the Mode Animals values for the active difficulty preset.

A concrete example: if the root Animals Damage_Multiplier is 1.0 and the Hard Mode Animals Damage_Multiplier is 1.5, animals on Hard deal 1.5 times their base damage. If the root Respawn_Time is 300 seconds and the Hard Mode Respawn_Time multiplier is 0.5, animals on Hard respawn after 150 seconds. Setting every Mode Animals value to 1.0 means animal behaviour is identical to the root config at this difficulty.

Barricades (BarricadesConfigData)

Barricade-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to barricade mechanics -- health values, decay rates, placement restrictions, and related behaviour. Layers multiplicatively on top of the root Barricades section. Values above 1.0 typically make barricades tougher or longer-lasting; values below 1.0 typically make them weaker or faster-decaying.

Structures (StructuresConfigData)

Structure-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to structure mechanics -- health values, decay rates, building restrictions, and related behaviour. Layers multiplicatively on top of the root Structures section. Values above 1.0 typically make structures tougher or longer-lasting; values below 1.0 typically make them weaker or faster-decaying.

Players (PlayersConfigData)

Player-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to character mechanics -- health, food and water drain rates, skill progression speed, respawn timers, and related behaviour. Layers multiplicatively on top of the root Players section. Values above 1.0 typically make survival harder (faster drain rates, longer respawns, slower skill gain); values below 1.0 typically make survival easier (slower drain, shorter respawns, faster skill gain).

Objects (ObjectConfigData)

World-object multipliers for this difficulty preset. This sub-object layers on top of the root Objects section documented earlier in this article. Every key in the root Objects section -- Binary_State_Reset_Multiplier, Fuel_Reset_Multiplier, Water_Reset_Multiplier, Resource_Reset_Multiplier, Resource_Drops_Multiplier, Rubble_Reset_Multiplier, Allow_Holiday_Drops, and Items_Obstruct_Tree_Respawns -- has a matching key inside this Mode sub-object. The server reads the root Objects values as the baseline and multiplies them by the Mode Objects values for the active difficulty preset.

A concrete example: if the root Resource_Reset_Multiplier is 1.0 (default regrowth speed) and the Hard Mode Objects Resource_Reset_Multiplier is 2.0, trees on Hard take twice as long to regrow as they do on the baseline. If the root Resource_Drops_Multiplier is 1.0 and the Easy Mode version is 1.5, players on Easy receive 1.5 times the normal resource yield per harvest. Setting every Mode Objects value to 1.0 means world-object regeneration is identical to the root config at this difficulty.

Events (EventsConfigData)

Event-related multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to event mechanics -- airdrop frequency, event scheduling intervals, arena-mode timing, and related behaviour. Layers multiplicatively on top of the root Events section. Values above 1.0 typically make events less frequent or longer-lasting; values below 1.0 typically make events more frequent or shorter.

Gameplay (GameplayConfigData)

General gameplay multipliers for this difficulty preset. This sub-object applies difficulty-level scaling to gameplay settings that do not fit cleanly into the other nine categories. Layers multiplicatively on top of the root Gameplay section. Covers settings such as combat rules, HUD element visibility, group mechanics, and other general server behaviours. Values above or below 1.0 shift these behaviours harder or easier depending on the specific key being scaled.

How Mode layering works

The Mode layer is multiplicative, not additive and not a replacement. When the server needs the effective value of any config key, it performs the following calculation:

Effective value = Root value * Mode value (for the active difficulty)

If the root config sets a timer to 300 seconds and the Mode multiplier for that timer is 0.5, the effective value is 150 seconds. If you change the root to 600 seconds and leave the Mode at 0.5, the effective value becomes 300 seconds. The root is the anchor; Mode is the lever that scales it.

This has two practical consequences for how you configure your server.

First, you cannot use Mode to set absolute values for a difficulty. Mode can only scale what the root defines. If you want a specific absolute number on a given difficulty, you must set the root value and the Mode multiplier such that their product equals your target. If the root has a timer of 200 and you want it to be 100 on Easy, you set the Easy Mode multiplier to 0.5. If you later change the root to 400, the Easy effective value becomes 200 -- you must adjust the Mode multiplier to 0.25 to restore your intended Easy value of 100. Mode tracks the root; it does not float independently.

Second, Mode values compound across categories. A Mode Animals sub-object and a Mode Gameplay sub-object might both contain multipliers that affect animal-related mechanics. The server applies both, and their effects stack multiplicatively. Consider this worked example:

Step	Source	Key	Value
1	Root Animals	Damage_Multiplier	1.0
2	Root Gameplay	(global damage multiplier)	1.2
3	Mode Animals (Hard)	Damage_Multiplier	1.5
4	Mode Gameplay (Hard)	(global damage multiplier)	1.3

Effective animal damage on Hard: 1.0 (step 1) * 1.5 (step 3) * 1.2 (step 2) * 1.3 (step 4) = 2.34 times base animal damage.

Because of this cross-category compounding, even modest-looking Mode values can produce significant divergence from the baseline when multiple Mode sub-objects multiply together. Each individual Mode multiplier might look reasonable on its own, but the product across several categories can be unexpectedly large.

A safe configuration approach is to keep all root values at 1.0 (meaning "use the game's built-in defaults") and vary only the Mode multipliers to define how difficulties diverge. This keeps the arithmetic simple: the effective value is approximately the Mode value (times any cross-category compounding from other Mode sub-objects), and you never have to track compounding root * Mode products across every category. If you later decide to adjust the global baseline, you change the root values and accept that all Mode presets will scale proportionally from the new baseline.

Setting any Mode multiplier to 0.0 typically disables that mechanic at that difficulty, regardless of the root value (since any value multiplied by zero equals zero). Setting it to 1.0 means no scaling -- the root value passes through unchanged. Setting it above 1.0 typically means the mechanic is intensified relative to the root (longer timers, more damage, higher costs -- generally harder). Setting it below 1.0 (but above zero) typically means the mechanic is reduced relative to the root (shorter timers, less damage, lower costs -- generally easier). The exact direction ("above 1.0 = harder" versus "above 1.0 = easier") depends on what the specific key being scaled represents: a timer multiplier above 1.0 makes the timer longer (usually harder), while a resource-drop multiplier above 1.0 gives more items (easier). Always check the root section's key explanation to understand which direction is which for each specific key.

Mode configuration example

Consider a server owner who wants the following difficulty profile:

• Normal difficulty (baseline): Animals deal standard damage and respawn at default speed. Resources regrow at default speed and drop standard quantities. This is the root config -- every root Animals and Objects key is set to 1.0.
• Easy difficulty: Animals deal less damage and are less durable. Everything respawns faster. Resources regrow faster and drop more items.
• Hard difficulty: Animals deal more damage and are tougher. Everything respawns slower. Resources regrow slower and drop fewer items.

Here is how the root config and the two Mode blocks would look, using only the Animals and Objects sections (the other eight Mode sub-objects are omitted for brevity but follow the same pattern):

Root config (Normal baseline):

{
  "Animals": {
    "Respawn_Time": 300.0,
    "Damage_Multiplier": 1.0,
    "Armor_Multiplier": 1.0
  },
  "Objects": {
    "Resource_Reset_Multiplier": 1.0,
    "Resource_Drops_Multiplier": 1.0,
    "Fuel_Reset_Multiplier": 1.0,
    "Water_Reset_Multiplier": 1.0
  }
}

Mode block for Easy difficulty:

{
  "Mode": {
    "Easy": {
      "Animals": {
        "Respawn_Time": 0.5,
        "Damage_Multiplier": 0.5,
        "Armor_Multiplier": 1.5
      },
      "Objects": {
        "Resource_Reset_Multiplier": 0.5,
        "Resource_Drops_Multiplier": 1.5,
        "Fuel_Reset_Multiplier": 0.5,
        "Water_Reset_Multiplier": 0.5
      }
    }
  }
}

In Easy mode, animal damage is halved (1.0 root * 0.5 Mode = 0.5 effective). Animals are easier to kill (1.0 root * 1.5 Mode = 1.5 Armor_Multiplier effective -- incoming damage is multiplied by 1.5, meaning animals take more damage). Resources regrow in half the time (1.0 * 0.5 = 0.5) and drop 1.5 times the items (1.0 * 1.5 = 1.5). Fuel and water refill in half the time.

Mode block for Hard difficulty:

{
  "Mode": {
    "Hard": {
      "Animals": {
        "Respawn_Time": 0.5,
        "Damage_Multiplier": 2.0,
        "Armor_Multiplier": 0.5
      },
      "Objects": {
        "Resource_Reset_Multiplier": 2.0,
        "Resource_Drops_Multiplier": 0.5,
        "Fuel_Reset_Multiplier": 2.0,
        "Water_Reset_Multiplier": 2.0
      }
    }
  }
}

In Hard mode, animals deal double damage (1.0 * 2.0 = 2.0) and take half the normal damage (1.0 * 0.5 = 0.5 Armor_Multiplier, meaning damage dealt to animals is halved -- they are twice as tough). Note that Respawn_Time is 0.5 in both Easy and Hard -- lower means faster respawn, which this server owner wants in both difficulty modes for different reasons: Easy gets fast respawns so players always have targets, Hard gets fast respawns to maintain constant wildlife pressure.

Resources regrow in double the time (1.0 * 2.0 = 2.0) and drop half the items (1.0 * 0.5 = 0.5). Fuel and water refill in double the time.

This example illustrates the multiplicative relationship: the root Animals Damage_Multiplier of 1.0 is the anchor, and the Mode values of 0.5 (Easy) and 2.0 (Hard) scale it in opposite directions to create two distinct difficulty experiences from a single root config.

---

UnityEvents

The UnityEvents section controls which scripted events the server-side and client-side text chat messenger interfaces are permitted to trigger. It is a four-key block of booleans that acts as a permission system for the chat messaging pipeline. Two keys govern the server-side messenger (ServerTextChatMessenger) and two govern the client-side messenger (ClientTextChatMessenger). Within each pair, one key controls message broadcast and the other controls command execution.

The distinction between server-side and client-side messengers is fundamental to understanding this section. The server-side messenger is the interface through which code running on the server -- plugins, scripts, the server binary itself -- interacts with the chat system. Because the server owner controls what runs on the server, server-side permissions are a matter of administrative convenience. The client-side messenger is the interface through which code running on a player's machine -- client-side mods, UI tools, or potentially malicious injected code -- interacts with the chat system. Because the server owner has no visibility into or control over what runs on a player's machine, client-side permissions are a matter of security.

Key	Type	Default
Allow_Server_Messages	bool	-
Allow_Server_Commands	bool	-
Allow_Client_Messages	bool	-
Allow_Client_Commands	bool	-

Server-side permissions

The server-side keys control what the server text chat messenger is permitted to do. This messenger is the interface through which server-side code -- plugins, scripts, and the server binary itself -- interacts with the chat system to send messages to players and execute game commands.

Allow_Server_Messages

When set to true, the server text chat messenger is permitted to broadcast messages. This is the pathway through which server plugins send announcements, warnings, restart countdowns, automated status notifications and any other text the server wants every connected player to see in their chat box. When set to false, the server messenger is blocked from broadcasting. Any message a server plugin or script attempts to push through the messenger is silently dropped -- the plugin's code thinks the broadcast succeeded, but no player sees the text.

Most servers keep this set to true because server-side message broadcast is the primary way plugins communicate with players. Disabling it is a blunt security measure: it silences every server broadcast, trusted and untrusted alike. If your concern is that a specific third-party plugin might spam or mislead players through chat, the better approach is to audit and remove that plugin rather than disabling the entire server broadcast channel. On a server running only first-party or personally-vetted plugins, there is normally no practical reason to disable server message broadcast.

Allow_Server_Commands

When set to true, the server text chat messenger is permitted to execute game commands. A server plugin or script with access to the messenger can programmatically issue commands -- the same commands an admin player could type into the chat box or console -- and the game processes them as authorized actions. When set to false, command execution through the messenger is blocked entirely. The messenger can still broadcast messages (if Allow_Server_Messages is true) but cannot execute commands.

This is a significant security boundary within the server-side code path. A plugin that can execute commands through the messenger has broad access to game-state modification. If that plugin is compromised, malicious, or simply buggy, the damage it can cause is much greater than if it were limited to message broadcast only. Server owners who run only plugins they have personally written, audited, and trust implicitly typically leave this enabled. Server owners running community-sourced or third-party plugins should evaluate whether each plugin genuinely needs command-execution access through the messenger, or whether an alternative, more restricted path exists for the actions that plugin needs to perform.

Client-side permissions

The client-side keys control what the client text chat messenger is permitted to do. This messenger is the interface through which code running on a player's machine -- client-side mods, UI enhancement tools, overlay scripts, or potentially malicious injected code -- interacts with the chat system. Because client-side code executes outside the server's visibility and control, these two keys carry substantially more security weight than their server-side counterparts. The server cannot inspect, approve or audit client-side code before it executes. The messenger permission gates are the only server-side control the server has over what client-side code can do with the chat pipeline.

Allow_Client_Messages

When set to true, the client text chat messenger on each player's machine is permitted to broadcast messages into the chat. This allows client-side mods and scripts to programmatically insert text into the visible chat stream. When set to false, any attempt by client-side code to push a message through the client messenger is blocked. The player can still type messages normally through the chat input -- manual chat entry does not use this programmatic pathway; only automated message injection from client-side code is gated.

Disabling client messages is a common step in server security hardening. A malicious client or a compromised client-side mod can use the messenger to spoof server announcements, impersonate administrators or other players, flood the chat with repetitive text, or inject misleading or deceptive messages into the chat log. Since the server cannot distinguish between a legitimate client-side mod adding a chat feature and a malicious script injecting spoofed text, the only reliable defense is to block the pathway entirely.

Legitimate client-side chat modifications -- tools that add message filtering, text formatting, timestamps, or other chat UI enhancements -- may require this key to be true to function. If your player base uses such tools and you have verified both the tools' source and distribution, you may need to leave this enabled. If your server does not rely on or formally support any client-side chat modifications, setting this to false removes the surface entirely.

Allow_Client_Commands

When set to true, the client text chat messenger is permitted to execute game commands. Client-side code running on a player's machine can programmatically issue commands that the game processes as if the player had typed them into the console or chat box. When set to false, command execution through the client messenger is blocked entirely.

This is the most security-sensitive key in the UnityEvents section, and arguably one of the most important security controls in all of Config.json. A malicious or compromised client-side mod that can execute commands operates with the player's own permission level. It can perform any action the player themselves could type -- and do so programmatically, silently, and at machine speed. The server has no way to distinguish between a command the player intentionally executed and a command injected by client-side code through this pathway. From the server's perspective, both arrive through the same chat pipeline with the same authorization and the same player identity.

There is no practical scenario in which a general-purpose public server benefits from enabling client-side command execution. The very small number of legitimate client-side mods that genuinely require programmatic command access are the exception, not the rule, and even those should be scrutinized carefully. If you believe your server needs this enabled for a specific mod, verify each of the following before doing so:

• The mod's source code is published and independently auditable
• The mod's distribution channel is trusted, uses integrity verification, and resists tampering
• The mod's command-execution pathway is limited to specific, enumerated actions rather than accepting arbitrary command strings
• You have a process for re-verifying these conditions every time the mod receives an update

Even with all these verifications, the risk that a future update to the mod introduces unintended or exploitable command behaviour should be weighed against the benefit the mod provides. For nearly every server, the correct value of this key is false.

Security posture for the UnityEvents section

These four keys are a permission system, not a feature system. They do not enable or disable the chat pipeline -- the chat pipeline always runs. They control what the messenger interfaces attached to that pipeline are authorized to do. The natural trust boundary between server and client suggests a clear default posture:

• Allow_Server_Messages: true -- the server owner controls what runs on the server, so server-side message broadcast is trusted. Disabling it cripples plugin communication for no security gain.
• Allow_Server_Commands: evaluate per-plugin -- the server owner controls what runs on the server, but command execution is a powerful capability. Enable only if your plugins genuinely need it and you trust every plugin that has access.
• Allow_Client_Messages: false -- the server owner does not control what runs on client machines. Disable unless you formally support specific, verified client-side chat mods.
• Allow_Client_Commands: false -- the server owner does not control what runs on client machines, and command execution is the most dangerous permission in this section. Disable unconditionally on any public server.

This posture reflects the principle that permissions should be denied by default and granted only when there is a specific, verified reason to grant them. It is a reasonable starting point for any server, public or private, that has not conducted a specific audit of every plugin and mod touching the chat messenger interfaces.

If a plugin breaks because you changed a UnityEvents key, the failure tells you something about that plugin: it uses a permission pathway you just locked down. Before re-enabling the key to fix the plugin, verify that the plugin's use of that pathway is appropriate and safe. A plugin that only needs to broadcast status messages should not require command execution. A plugin that only needs to read chat should not require message broadcast. Match the permission you grant to the minimum the plugin actually needs, not the maximum the messenger interface allows.

The UnityEvents keys apply at server startup and take effect for the duration of the server session. Changing them requires a server restart. If you are debugging a chat-related issue, toggle these keys one at a time so you can isolate which permission change is responsible for the behaviour change you observe.

---

Canned Beans

None of the four config sections covered in this article -- Animals, Objects, Mode, or UnityEvents -- govern whether or how canned beans appear in the game world. The Animals section controls wildlife behaviour. The Objects section controls world-object regeneration timers and drop multipliers for harvested natural resources (trees, rocks, bushes). The Mode section controls difficulty-preset multipliers that scale the root config values. The UnityEvents section controls chat messenger permissions. None of these sections touch food item spawns, loot tables, consumable drop rates, or any other mechanic that would affect the presence, frequency or scarcity of canned beans.

The Resource_Drops_Multiplier in the Objects section scales drops from natural resources (trees, rocks, bushes), not from containers or loot spawns where food items like canned beans typically appear. The Allow_Holiday_Drops boolean in Objects controls holiday-themed loot injection, but canned beans are not a holiday-specific item. The Mode section's Items sub-object may contain multipliers that affect food item spawn rates at different difficulties, but the specific bean data is not in any of the four sections documented here. Canned beans, as a specific item with specific spawn behaviour, are governed by the root Items section and by the individual item asset data where bean entries are defined as loot.

For the full story of why canned beans have become a running canon element across the 57 Studios knowledge base, see /lore/canned-beans-lore.

---

Practical use for server owners

These four sections, despite their modest individual sizes, collectively govern wildlife behaviour, world persistence, difficulty scaling and chat security -- four concerns that affect every player on your server every session. This section describes a practical workflow for configuring them together, the order to approach them in, how to test your changes, and the most common mistakes server owners make.

Order of operations

Start with Mode because it affects how every other section's values are interpreted at runtime. Decide which difficulty level you are targeting as your baseline. For most server owners, Normal is the natural baseline -- it is what players expect when they join a server that does not advertise a specific difficulty. Set the root config sections (Animals, Objects, and every other root section in Config.json) for how you want Normal difficulty to play. Then use the Mode blocks for Easy and Hard to define how those presets diverge. A Mode multiplier of 1.0 means no divergence from the baseline for that category at that difficulty. Only change Mode values where you want a specific category to feel different between difficulty levels.

Next, configure Animals. Determine your map's size tier (check with the map's author, documentation, or community resources -- most curated maps are Medium or Large). Set the matching Max_Instances key to a population cap that fits your server's target wildlife density. Start conservative -- around 30 to 50 for a Medium map is a common starting point -- and adjust after observing server performance and player feedback. Tune Damage_Multiplier and Armor_Multiplier together using the four-quadrant approach described in the Animals section: decide what kind of wildlife encounters you want (brief and lethal, prolonged and dangerous, or quick and harmless) and set both multipliers accordingly. Set Respawn_Time based on whether you want fast wildlife repopulation or long windows of safety after clearing an area. Decide on Weapons_Use_Player_Damage based on whether weapon consistency between PvP and animal combat matters for your server.

Then, configure Objects. Focus first on the resource economy: Resource_Reset_Multiplier and Resource_Drops_Multiplier. These two keys have the most visible impact on how your server's world feels over time. Pick one of the four economic modes described in the Objects section (low/fast, high/fast, high/slow, or low/slow) and set both multipliers to produce that outcome. Tune Fuel_Reset_Multiplier and Water_Reset_Multiplier if vehicle and survival sustain are important to your server's playstyle -- on a server where vehicles are central, fuel timing matters; on a hardcore survival server, water timing matters. Set Items_Obstruct_Tree_Respawns to true if your server allows player building. Leave Binary_State_Reset_Multiplier, Rubble_Reset_Multiplier and Allow_Holiday_Drops at their defaults (1.0, 1.0, and whatever your preference for seasonal loot is) unless you have a specific reason to change them.

Finally, lock down UnityEvents. Set Allow_Client_Commands to false -- there is almost no scenario where a general-purpose server benefits from enabling this. Set Allow_Client_Messages to false unless your server explicitly supports and requires client-side chat modifications. Leave Allow_Server_Messages at true unless you have a specific reason to silence all server-side broadcasts. Evaluate Allow_Server_Commands based on the plugins you run: if every plugin is first-party or thoroughly audited, true is reasonable; if you run plugins from community sources, consider whether false and stricter command-authoring paths are acceptable tradeoffs.

Testing your changes

After editing Config.json, restart the server. For each section, verify the following:

Animals section. Kill several animals and observe how long replacements take to appear. The timing should approximately match Respawn_Time (as a floor, not an exact interval -- the server may defer spawns if the population cap is hit). Kill animals until the population approaches the cap, then confirm that further spawns stop. Attack an animal and observe the damage dealt and received -- both should scale relative to default behaviour by the multipliers you set. If you changed Weapons_Use_Player_Damage, test with a weapon that has different PvP and animal damage values (if you know of one) and confirm the behaviour matches your intent.

Objects section. Harvest a tree and record how long it takes to regrow. The regrow time should be the base duration multiplied by Resource_Reset_Multiplier. Harvest several resources and compare the drop quantities to your pre-change baseline -- drops should scale by Resource_Drops_Multiplier. Draw fuel from a source and verify that the refill timing matches Fuel_Reset_Multiplier. Draw water from a source and verify Water_Reset_Multiplier. Destroy a destructible fence or barrier if your map has one and verify that Rubble_Reset_Multiplier scales the repair timer.

Mode section. If your server supports multiple difficulty presets, switch between them and verify that the game feel changes in proportion to the Mode multipliers you set. Pay particular attention to cross-category compounding: if you set multipliers in both Mode Animals and Mode Gameplay that affect the same underlying mechanic, verify that the compound effect is what you intended, not an accidental multiplicative spike. On servers that only run one difficulty, verify that the effective values (root times Mode for the active preset) produce the intended game feel.

UnityEvents section. Verify that server plugins can still broadcast messages (if you left Allow_Server_Messages true). If you have a test plugin that issues commands, verify that Allow_Server_Commands gates it correctly -- commands should execute when true and be silently blocked when false. If you set Allow_Client_Messages to false, confirm that client-side chat injection tools are blocked. The Allow_Client_Commands key is hardest to test without a client-side mod that uses it; the safest approach is to set it false and only enable it if a specific, named mod breaks and demonstrably requires it, at which point you can test with that specific mod.

Common mistakes

Setting an Objects multiplier to zero unintentionally. Zero disables that mechanic entirely -- fuel never refills, trees never regrow, rubble never repairs. If you meant to set the fastest possible rate, use a very small positive number (such as 0.01), not zero. The difference between "near-instant" and "permanently disabled" is the difference between a very small positive value and exactly zero. This mistake is common because zero looks like a lower-is-faster setting, and for timer multipliers lower is indeed faster -- but zero is not "infinitely fast," it is "off."

Forgetting that Mode multiplies the root. If you increase the root Animals Damage_Multiplier to 2.0 and your Hard Mode Animals sub-object also has Damage_Multiplier at 2.0, the effective Hard animal damage is 4.0 (2.0 times 2.0). This stacking is by design, but it routinely surprises server owners who assume Mode replaces the root rather than scaling it. Before changing any root value, check the same key's value in every Mode block to understand the compound effect at each difficulty.

Setting Max_Instances caps too high for the server's hardware. Each animal instance runs pathfinding, behaviour state machines and physics simulation every server tick. On a server already running many concurrent players, zombies, vehicles and other active systems, adding hundreds of animals can contribute to server tick-rate degradation. The exact safe ceiling depends on CPU power, map geometry complexity and concurrent player load -- all of which vary per deployment. Start conservative (20 to 50 for Medium maps, scaling proportionally for smaller or larger tiers) and increase only after confirming stable server tick rate under your normal peak player load.

Leaving Allow_Client_Commands at its default value. A fresh or unmodified Config.json may default this key to true. Check it explicitly. On any server accessible to players you do not personally know, client-side command execution is a security liability with no corresponding benefit. If your server runs any server-side anti-cheat or moderation plugins, client-side command execution undermines their effectiveness by providing an alternative path for unauthorized actions.

Confusing Mode sub-object contents with root section contents. Each Mode sub-object carries the same keys as its corresponding root section. When you set Mode > Objects > Resource_Reset_Multiplier to 0.5, you are scaling the root Resource_Reset_Multiplier by 0.5 at that difficulty. You are not setting an independent value. The Mode value is a multiplier applied to the root value, not a standalone configuration. If you later change the root Resource_Reset_Multiplier, the effective value at that difficulty changes proportionally.

Setting the wrong size tier's Max_Instances cap. Only the cap matching your map's size tier is active. Changing Max_Instances_Tiny while running a Large map has no effect. Before editing population caps, confirm your map's size tier. If you change all five caps to the same value, you guarantee consistent behaviour regardless of which map you load in the future, but you also lose the ability to tune per-map-size. Most server owners who run a single map set only the matching cap and leave the others at their defaults.

Configuring for three difficulty presets: a complete pass

Once you have been through the single-difficulty workflow above and confirmed that your server plays correctly at your Normal baseline, creating Easy and Hard presets is a matter of deciding which direction each category should move and by how much. The general pattern used by the game's own presets is:

• Easy mode: Damage taken by players is reduced, damage dealt by players is increased, timers are shorter (faster respawns, faster regrowth), resource yields are higher. Mode multipliers on damage-dealt keys are below 1.0 (enemies hit softer), on damage-taken keys are above 1.0 (enemies die faster), and on timer keys are below 1.0 (everything happens faster).
• Hard mode: Damage taken by players is increased, damage dealt by players is reduced, timers are longer, resource yields are lower. Mode multipliers are the inverse of Easy: damage-dealt above 1.0, damage-taken below 1.0, timers above 1.0.

This pattern is symmetrical around the 1.0 baseline: Easy moves values in one direction, Hard moves them in the opposite direction by roughly the same amount. If Easy sets Damage_Multiplier to 0.5, Hard sets it to somewhere around 2.0. The exact magnitudes are your choice, but the symmetry keeps difficulty progression intuitive for players who switch between presets.

After setting up three presets, test each one with a quick pass of the checklist in the Testing section above. Pay particular attention to the cross-category compounding described in the Mode layering section -- what looks like a modest 1.3 multiplier in Animals and a 1.2 multiplier in Gameplay compounds to a 1.56 effective multiplier, and across all ten Mode sub-objects the compound effects can be larger than any individual multiplier suggests.