Config.json Events Section Reference

Intermediate40-60 minutesCross-platformUnturned ServerNotepad++

The Events section of the Unturned dedicated server Config.json controls the scheduling, duration, and behaviour of every timed world event that the server manages. This includes legacy rain and snow events, modern weather transitions, the airdrop plane and care package system, and the full arena-mode match lifecycle -- from the countdown that teleports players into the arena through every compactor shrink phase to the intermission timer that separates consecutive matches.

This article is the 57 Studios™ complete reference for the Events section of the server Config.json. It covers all thirty keys in the section, organized into four functional groups: legacy weather scheduling, modern weather scaling, airdrop control, and arena-mode timing. Each key is explained in terms a server owner can act on directly.

Documentation source: The key definitions in this article are drawn from the Unturned™ SDK source class EventsConfigData inside PlayConfigData.cs.

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 each key in the Events section does. It assumes you can open a JSON file and change a value. It does not assume prior knowledge of weather scheduling, airdrop physics, or arena game mode internals.

What you will learn

• What the thirty keys in the Events section govern at a high level
• How legacy rain and snow keys differ from the modern weather multiplier keys
• Which keys control how often an airdrop flies over the map and how fast the care package descends
• Which keys shape an arena match's full lifecycle, from player readiness through compactor damage to intermission
• How zeroing certain keys disables entire event systems without touching anything else

What this section governs

The Events section sits inside the "Events" block of the server Config.json. When the server starts, it deserializes this block into an EventsConfigData object that the dedicated server binary reads every time it needs to schedule or advance one of the managed event systems. The section is not optional -- the server always reads it, and every key in the section is always present in memory. The values you set determine whether a system runs at all, how often it fires, and how it behaves when it fires.

Understanding the Events section requires understanding that the server treats world events as scheduled occurrences on a timeline. The server does not poll for rain randomly. It does not decide on the fly whether an airdrop should appear. It schedules the next event when the current one ends, and it uses the values in this section to compute when that next event will be and how long it will last. You are not tuning probabilities. You are setting interval windows and duration windows, and the server picks random values within those windows to keep timing unpredictable within the boundaries you define.

Four distinct systems are controlled from this section:

1. Legacy weather. The rain and snow keys (Rain_Frequency_Min through Snow_Duration_Max) control event-based weather for maps built with the older weather pipeline. Maps that have been updated to the modern weather system ignore these keys. If your map uses the modern system, the rain and snow keys are present in memory but have no effect on gameplay. The server does not warn you about this. It silently ignores the legacy keys and reads the multiplier keys instead.
2. Modern weather. The two multiplier keys (Weather_Frequency_Multiplier and Weather_Duration_Multiplier) scale the timing of weather events on maps that use the current weather pipeline. Unlike the legacy keys, which are simple min/max intervals stated in absolute day counts, the multiplier keys act as global scaling factors applied to whatever base frequencies and durations the map author defined in the level asset. This means the same multiplier values produce different results on different maps, and there is no universal "good" setting that works across every level.
3. Airdrops. The frequency, speed, upward-force, and toggle keys (Airdrop_Frequency_Min, Airdrop_Frequency_Max, Airdrop_Speed, Airdrop_Force, Use_Airdrops) determine whether care packages fall at all, how frequently they arrive, and how the airdrop plane and care package move through the sky. The airdrop system ties into the map's airdrop asset configuration -- the Events section controls cadence and physics, but what the care package contains and what model it uses are properties of the airdrop asset, not of Config.json.
4. Arena mode. The Arena keys (Arena_Min_Players through Arena_Compactor_Shrink_Factor) control every phase of an arena match: how many teams must be present before a match starts, how long the readiness countdown lasts, when and how fast the compactor circle shrinks, how much damage players take outside the circle, how long the victory screen persists, and how long the intermission between matches lasts. The arena system is self-contained -- its keys do not interact with the weather or airdrop systems.

Sections in Config.json are not isolated. The Use_Airdrops key interacts with the map's airdrop asset configuration. The Arena compactor speeds are keyed to the level's size category (Tiny, Small, Medium, Large, Insane), which means changing the map changes which speed key the server reads -- your Arena_Compactor_Speed_Tiny value is irrelevant on a Large map. The legacy weather keys only activate when the loaded map uses the legacy weather pipeline. Understanding which keys are active on your map is as important as knowing what value to set for each.

The section also has a notable design characteristic: it contains keys for two entirely different weather systems side by side, with no flag or property in the section itself that tells the server which system to use. The server determines this by inspecting the loaded map. This means you can set legacy rain keys and modern weather multiplier keys in the same Config.json, and only one set will be active at any given time depending on the map. There is no conflict. The server reads both sets of keys into memory but only schedules based on one pipeline.

Complete key reference

This table lists every key in the Events section, in the order they appear in the source EventsConfigData class. The Key column shows the exact JSON property name. The Type column shows the C# type the server deserializes to. The Default column shows the engine default -- a dash means no preset default is hardcoded and the server will use a zero or zero-equivalent value when the key is absent from Config.json.

Key	Type	Default
Rain_Frequency_Min	float	-
Rain_Frequency_Max	float	-
Rain_Duration_Min	float	-
Rain_Duration_Max	float	-
Snow_Frequency_Min	float	-
Snow_Frequency_Max	float	-
Snow_Duration_Min	float	-
Snow_Duration_Max	float	-
Weather_Frequency_Multiplier	float	-
Weather_Duration_Multiplier	float	-
Airdrop_Frequency_Min	float	-
Airdrop_Frequency_Max	float	-
Airdrop_Speed	float	-
Airdrop_Force	float	-
Arena_Min_Players	uint	-
Arena_Compactor_Damage	uint	-
Arena_Compactor_Extra_Damage_Per_Second	float	-
Arena_Clear_Timer	uint	-
Arena_Finale_Timer	uint	-
Arena_Restart_Timer	uint	-
Arena_Compactor_Delay_Timer	uint	-
Arena_Compactor_Pause_Timer	uint	-
Use_Airdrops	bool	-
Arena_Use_Compactor_Pause	bool	-
Arena_Compactor_Speed_Tiny	float	-
Arena_Compactor_Speed_Small	float	-
Arena_Compactor_Speed_Medium	float	-
Arena_Compactor_Speed_Large	float	-
Arena_Compactor_Speed_Insane	float	-
Arena_Compactor_Shrink_Factor	float	-

About the key units

Most float keys in the Events section represent time in days of in-game time, not seconds of real time. One in-game day in Unturned is considerably shorter than a real day -- the server advances the game clock at an accelerated rate, which means a frequency of 2.0 represents two game-days, not forty-eight real hours. The exact real-time duration of an in-game day depends on the server's day/night cycle rate, which is configured elsewhere in Config.json, outside the Events section.

The keys that do not use in-game days as their unit are:

• Airdrop_Speed: meters per second of plane flight speed.
• Airdrop_Force: a physics force magnitude applied upward to the care package.
• Arena_Compactor_Damage and Arena_Compactor_Extra_Damage_Per_Second: damage values and damage accumulation rates.
• Arena_Clear_Timer, Arena_Finale_Timer, Arena_Restart_Timer, Arena_Compactor_Delay_Timer, and Arena_Compactor_Pause_Timer: seconds of real time.
• Arena_Compactor_Speed_Tiny through Arena_Compactor_Speed_Insane: meters per second of radius reduction.
• Arena_Compactor_Shrink_Factor: a decimal proportion between zero and one.
• Arena_Min_Players: a count of teams (not players).
• Use_Airdrops and Arena_Use_Compactor_Pause: booleans with no unit.

The distinction between in-game days and real seconds is the most common source of confusion when tuning event keys. If you want an arena match countdown to last thirty real seconds, set the timer key to 30. If you want an airdrop every two in-game days, set the frequency keys accordingly. Mixing up the unit types produces either glacial pacing (if you interpret a timer key as days) or absurdly rapid scheduling (if you interpret a frequency key as seconds).

Legacy rain keys

The four legacy rain keys -- Rain_Frequency_Min, Rain_Frequency_Max, Rain_Duration_Min, and Rain_Duration_Max -- form a simple scheduling system for weather events on maps built with the older weather pipeline. The server reads these keys to decide how many in-game days to wait before starting the next rain event, and how many in-game days the rain event should last.

How the legacy rain scheduling works

When the server finishes processing a legacy rain event (either because the event ran for its full scheduled duration or because the duration was zero and the event ended instantly), it generates a random number of in-game days between Rain_Frequency_Min and Rain_Frequency_Max. It schedules the next rain event to begin when that number of in-game days has elapsed. Once the event begins, it generates a random number of in-game days between Rain_Duration_Min and Rain_Duration_Max and schedules the rain to stop when that many days have passed. The cycle then repeats.

The server uses a random value within the min/max range each time. It does not alternate, does not trend toward the midpoint, and does not remember what value it picked last time. Every rain cycle is an independent random draw. This means that if your frequency range is 2.0 to 5.0 and your duration range is 0.5 to 1.0, the following sequence of events is entirely possible:

• Event 1: 3.2 days of clear weather, then 0.7 days of rain.
• Event 2: 4.8 days of clear weather, then 0.9 days of rain.
• Event 3: 2.1 days of clear weather, then 0.5 days of rain.
• Event 4: 4.3 days of clear weather, then 1.0 days of rain.

There is no predictability beyond the boundaries set by the min and max values. If you want rain on a fixed schedule -- exactly every three days, lasting exactly one day -- set both the frequency min and max to 3.0 and both the duration min and max to 1.0. The random range collapses to a single value, and the schedule becomes deterministic.

Setting the frequency range

The frequency range controls the pace of rain events relative to each other. A short minimum (e.g., 0.5) means rain can return very quickly after a prior event ends. A long maximum (e.g., 10.0) means the server might wait a very long time between rain events on some cycles. The spread between min and max determines how much the timing varies from one cycle to the next.

A server operator who wants rain as a frequent atmospheric feature picks a narrow range near the lower end (e.g., 1.0 to 2.0). A server operator who wants rain as a rare occurrence that feels notable picks a wider range shifted upward (e.g., 7.0 to 14.0). There is no correct range -- the choice is entirely about the experience you want for your players.

Note that if the frequency minimum is set very low (e.g., 0.1), the server may schedule the next rain event to begin almost immediately after the current one ends. With a duration range that is also short, this creates a pattern of rapid, brief rain showers that cycle on and off frequently. With a duration range that is long, a low frequency minimum can place rain events so close together that they overlap or chain into each other, creating the impression of continuous rain.

Setting the duration range

The duration range controls how long each rain event persists. Both the min and max are in in-game days. A short duration produces a quick shower that passes through. A long duration produces an extended period of rain that dominates the weather for a significant portion of the game session.

The practical effect of a rain event depends on the map. On a map where rain reduces visibility, a long-duration rain event can make navigation and combat more difficult for an extended period. On a map where rain has only a cosmetic effect, a long duration is atmospheric rather than mechanically significant. Consider the loaded map's rain implementation before setting long durations.

When choosing a duration range, consider the relationship between duration and frequency. If you set a narrow frequency range of 1.0 to 1.5 (rain almost every day) and a wide duration range of 1.0 to 8.0 (rain lasts up to eight days), the map will be raining a large fraction of the total uptime. If your map's rain implementation imposes gameplay penalties, this can make the server feel punishing even though you set "normal" frequency values. The effective rain coverage rate is the ratio of average duration to average interval. Before finalizing values, estimate whether that ratio produces the weather balance you want.

Disabling legacy rain

The duration keys double as the master off switch for legacy rain. Setting both Rain_Duration_Min and Rain_Duration_Max to zero disables legacy rain entirely. The server still reads the frequency keys, and it still runs the scheduling loop, but every scheduled rain event has a duration of zero in-game days, which means the event starts and ends in the same tick. No rain appears on the map. No weather effect triggers. The system runs silently in the background and produces no observable result.

Setting only one of the two duration keys to zero while leaving the other non-zero is not described as a supported configuration in the source notes. The scheduling model picks a random value in the range defined by min and max. If the range is zero to one, rain sometimes lasts zero days (instant end) and sometimes lasts one day (full event). This produces a form of intermittent rain that may or may not be the intended behaviour. If your goal is to disable legacy rain, zero both keys.

When these keys are read

The legacy rain keys are only read when the loaded map uses the legacy weather features. A map upgraded to the modern weather pipeline does not use these keys. The server checks the map's weather system type at load time. There is no flag in the Events section itself that controls this switch -- you cannot force a modern-weather map to use the legacy rain keys by changing a Config.json value. The decision is made by the map.

If you are uncertain which weather system your map uses, there is a practical test. Set Rain_Duration_Min and Rain_Duration_Max to a high value (such as 10.0) and restart the server. Observe the map over several in-game day cycles. If rain appears and persists for a noticeably long time, your map uses the legacy system and reads these keys. If no rain appears, your map uses the modern system and reads the multiplier keys instead.

Legacy snow keys

The four legacy snow keys mirror the rain key structure exactly, substituting snow for rain: Snow_Frequency_Min, Snow_Frequency_Max, Snow_Duration_Min, and Snow_Duration_Max. They follow the same scheduling model -- the server picks a random number of in-game days between the frequency min and max to wait before the next snow event, and a random number of in-game days between the duration min and max for the event to last.

Snow-specific behaviour

A legacy snow event applies a snow visual effect across the map. Depending on the map's implementation, snow may also alter surface properties, player visibility, or other environmental factors. The source notes do not detail the specific visual or gameplay effects of snow beyond its scheduling. What snow looks like and how it affects gameplay are properties of the map's weather implementation, not of these Config.json keys.

Independence from rain scheduling

The server manages legacy rain and legacy snow as entirely separate event tracks. The rain scheduler and the snow scheduler do not coordinate with each other. Each runs its own frequency-duration loop independently, using its own set of four keys.

This separation has a practical consequence: a map set up for both legacy rain and legacy snow can experience both events at the same time. If the rain frequency and snow frequency ranges happen to align, a rain event can start and end while a snow event is ongoing, or vice versa, or both can begin simultaneously. The server does not prevent overlapping legacy weather events.

It is also possible for neither event to be active. If the random draws for both rain frequency and snow frequency happen to produce long waits, the map can go an extended period with clear weather despite both systems being enabled. This is not a bug -- it is the expected behaviour of two independent schedulers operating on random intervals.

Disabling legacy snow independently

Because the rain and snow schedulers are independent, disabling one does not affect the other. Setting both Snow_Duration_Min and Snow_Duration_Max to zero disables legacy snow while leaving legacy rain running at whatever values its keys specify. Setting both rain duration keys and both snow duration keys to zero disables both. A server running a legacy-weather map where you want rain but not snow needs only the snow duration keys zeroed. A server where you want snow but not rain needs only the rain duration keys zeroed.

The same caution applies here as with rain: zero both min and max duration keys. Zeroing only one produces an unpredictable mix of zero-length and non-zero-length snow events.

Legacy snow on maps that do not support it

A legacy-weather map may have rain support but not snow support, or snow support but not rain support, depending on how the map author built the weather pipeline. If the map does not implement legacy snow visuals, enabling snow through these keys produces no visible effect even with non-zero duration values. The scheduler runs, but no snow appears. The source notes do not describe a method for determining from Config.json alone whether a legacy map supports snow.

Overlap between rain and snow scheduling

Since the rain and snow schedulers are fully independent, it is possible -- and on some configurations, likely -- that a rain event and a snow event will overlap. The server does not prevent this. What happens visually and mechanically when both legacy events are active simultaneously is determined by the map's weather implementation, not by Config.json. Some maps may layer the effects. Others may give one event visual priority. You cannot control overlap behaviour from the Events section. You can only control whether it can happen at all by enabling or disabling each weather type.

If overlapping rain and snow produces undesirable visual or gameplay results on your map, disable one of the two weather types entirely by zeroing its duration keys. You cannot enforce mutual exclusivity between legacy rain and legacy snow through the Events section alone.

Modern weather multiplier keys

Two keys govern the modern weather system: Weather_Frequency_Multiplier and Weather_Duration_Multiplier. They operate on a fundamentally different model from the legacy keys. Instead of specifying absolute day counts, they act as global scaling factors applied to whatever base values the map author defined in the level asset's weather definitions.

How the modern weather system works

In the modern weather pipeline, the level asset defines one or more weather types. A map might define sunny, overcast, rainy, foggy, and stormy weather, each with its own base frequency (how often it occurs relative to other types) and its own base duration (how long each occurrence lasts when it triggers). The server reads these base values from the level asset, multiplies each by the corresponding multiplier from Config.json, and uses the scaled result to schedule and run weather transitions.

This means a single Weather_Frequency_Multiplier value affects every weather type on the map uniformly. If rain has a base frequency that makes it twice as common as fog, rain remains twice as common after the multiplier is applied. The multiplier does not change the relative probabilities of different weather types -- it compresses or stretches the entire weather timeline by the same factor.

The frequency multiplier misnomer

Weather_Frequency_Multiplier scales the number of in-game days between weather events. A higher number means more days between events, which means less frequent weather changes. A lower number means fewer days between events, which means more frequent weather changes. This is the opposite of what "frequency multiplier" suggests to most people, and the internal game description acknowledges it as a misnomer.

To make weather change twice as often on a modern-weather map, set Weather_Frequency_Multiplier to 0.5. To make weather change half as often, set it to 2.0. A value of 1.0 leaves the map author's base timing unchanged. A value of 0.0 would produce weather that changes infinitely often (every zero days), which is not a useful configuration -- the server would cycle through weather types as fast as it can process the scheduler.

The internal game description also notes that if you set this key accidentally high and weather becomes stuck or unresponsive, the /weather 0 console command can immediately reschedule the next weather event. This is a recovery command, not a permanent fix. To correct the cadence permanently, change the multiplier and restart the server.

The duration multiplier

Weather_Duration_Multiplier scales the number of in-game days each weather event lasts. This one is straightforward: a multiplier of 2.0 doubles how long each weather type persists. A multiplier of 0.5 halves the duration. A multiplier of 1.0 passes the map author's base durations through unchanged.

The practical effect of adjusting the duration multiplier depends on what weather types the map defines. If the map defines a foggy weather type that substantially reduces player visibility and the duration multiplier is set high, your server will experience long stretches where players are effectively blinded. This is neither good nor bad -- it is a design choice. If your players find long fog periods frustrating, reduce the duration multiplier. If they enjoy the challenge, raise it.

Disabling weather on a modern-weather map

Setting Weather_Duration_Multiplier to 0 disables all modern weather events. When the multiplier scales every weather type's duration to zero, the server schedules weather transitions but every transition starts and ends instantly with no observable effect. The frequency multiplier is still read, and the scheduler still runs, but weather never has a non-zero duration in which to manifest.

This is the cleanest way to disable weather on a modern-weather map. You do not need to remove or comment out the multiplier keys. You set one key to zero, and the entire weather pipeline produces no observable weather. Setting Weather_Frequency_Multiplier to zero as well does not add anything functionally -- once durations are zero, the frequency at which zero-duration events occur is irrelevant.

Tuning multiplier values across different maps

Because the multipliers are scaling factors applied to map-specific base values, the same multiplier settings produce different observable results on different maps. A map with very long base durations will feel sluggish if you set Weather_Duration_Multiplier to 0.25 -- each weather type lasts a quarter of its base duration, but if the base durations are long, a quarter is still substantial. A map with very short base durations will cycle through weather rapidly even at a multiplier of 2.0.

There is no universal recommended value. The tuning process for a specific map is:

1. Set both multipliers to 1.0.
2. Observe the default weather pace over several in-game day cycles.
3. Adjust one multiplier at a time. Observe again. Do not change both at once, or you cannot attribute which change produced which result.
4. When the pace feels right for your server, leave the values as they are.

Airdrop keys

The airdrop keys control the cadence, physics, and existence of the care package dropship system. Five keys belong to this group: Airdrop_Frequency_Min, Airdrop_Frequency_Max, Airdrop_Speed, Airdrop_Force, and Use_Airdrops. Together they answer three questions: do care packages fall at all, how frequently do they fall, and how does the falling care package behave in flight.

Airdrop frequency

The two frequency keys (Airdrop_Frequency_Min and Airdrop_Frequency_Max) operate on the same min/max interval model as the legacy weather keys. After the server spawns an airdrop, it picks a random number of in-game days between the minimum and maximum values and schedules the next airdrop for that many days later. The cycle repeats each time an airdrop completes.

The frequency scheduler does nothing unless Use_Airdrops is set to true. Even with valid frequency ranges entered, an Use_Airdrops of false prevents the airdrop plane from ever spawning. The frequency keys define the cadence, but the toggle key is the master switch. If drops are not appearing on your server, check the toggle before checking the frequency keys.

The min/max spread works exactly as it does for legacy weather. A narrow spread (e.g., 1.0 to 1.5) produces drops on a roughly predictable schedule. A wide spread (e.g., 1.0 to 8.0) produces drops that sometimes come in rapid succession and sometimes have long gaps. Setting both min and max to the same value produces a fixed schedule with no randomness.

Airdrop speed

Airdrop_Speed is the flight speed, in meters per second, at which the airdrop plane traverses its flight path across the level. The plane spawns at a point far enough from the play area to give the approach visual drama, flies over the designated drop zone, releases the care package, and continues out of the play area on the far side.

A lower speed value keeps the plane in the sky longer. Players on the ground have more time to hear or see the plane, assess its trajectory, estimate where the care package will land, and move toward the landing zone. A higher speed value gives players less reaction time. On a large map, a very fast plane may cross the entire sky before a player on foot can cover the distance to the drop zone.

The speed also affects how long the care package stays attached to the plane before release. The plane flies a predetermined route. A slower plane traverses that route in more real seconds, which delays the package release. This changes the total time available to react, from plane appearance to package touchdown, across two separate mechanisms: plane speed and care package fall time (controlled by Airdrop_Force).

Airdrop force

Airdrop_Force controls the upward force applied to the care package after the plane releases it. This upward force counteracts gravity and determines how long the care package stays airborne before touching down. A higher force value means stronger upward push, which means the package descends more slowly. A lower force value means weaker upward push, which means gravity dominates and the package hits the ground sooner.

The internal game description states that this value is not intuitive, and it is worth emphasizing: higher force equals slower descent. If players on your server cannot reach airdrops before they land, increase the force. If packages hang in the air too long and players lose interest waiting, decrease the force. The plane speed and the care package descent force together determine the total reaction window from plane spawn to package landfall.

The force is a physics value, not a timer. The exact time the care package stays airborne depends on the force value, the gravity setting for the map, and the altitude from which the plane drops the package. On maps with different gravity or different drop altitudes, the same force value may produce different real-time descent durations.

The Use_Airdrops toggle

Use_Airdrops is a boolean with two states: true means the airdrop scheduler runs and planes spawn at the computed intervals. false means the scheduler does not run, and no airdrop planes ever spawn, regardless of what the frequency keys say.

Setting this key to false is the correct way to disable airdrops on your server. It does not remove, alter, or corrupt any airdrop asset data. The airdrop assets still exist on the map and in the game files. The server simply never activates the scheduler that reads them. If you later set the key back to true, airdrops resume at the configured frequency with no additional steps required.

A server owner running a map with a very small play area, or a map where care package loot would disrupt the intended balance of the server's economy, should set Use_Airdrops to false. A server owner who wants more airdrops should adjust the frequency keys, not look for a "frequency multiplier" key -- the only way to increase airdrop rate is to lower the frequency min and max values.

No airdrop frequency multiplier

Unlike the modern weather system, the airdrop system has no multiplier key. There is no Airdrop_Frequency_Multiplier or Airdrop_Duration_Multiplier. The only way to make airdrops more frequent is to set lower values for Airdrop_Frequency_Min and Airdrop_Frequency_Max. The only way to make them less frequent is to set higher values. The only way to disable them is to set Use_Airdrops to false.

How the airdrop physical sequence works

When an airdrop triggers, the server executes the following sequence:

1. The airdrop plane spawns at a position far enough from the play area to give the approach visual drama. The plane model is determined by the level asset's dropship pointer, not by Config.json. No Events section key selects the plane model.
2. The plane flies along a predetermined route across the level at the speed defined by Airdrop_Speed. The route is determined by the map, not by Config.json. The route typically passes over or near the designated drop zone.
3. At the drop point, the plane releases the care package. The care package model is determined by the airdrop asset referenced in the level asset. No Events section key selects the care package model.
4. After release, the care package falls under the influence of gravity and the upward force defined by Airdrop_Force. During descent, a parachute animation plays. The falling model and parachute are properties of the airdrop asset, not of Config.json.
5. When the care package contacts the ground, the falling model is replaced by a landed barricade -- a storage container players can access to collect the supplies. The barricade type is defined by the airdrop asset. The supplies the barricade contains are defined by the airdrop asset's linked loot tables.

The Events section controls only the cadence (when the plane appears), the plane's speed, and the care package's descent resistance. Everything about what the plane looks like, what the care package looks like, and what supplies it contains is configured in the airdrop asset and the level asset, which are separate configuration surfaces.

Arena-mode keys

The Arena keys are the largest group in the Events section, with seventeen keys. They control the full lifecycle of an arena match: the minimum player count, the readiness countdown, every phase of the compactor circle's shrink cycle, the damage players take outside the safe zone, the post-match victory screen, and the intermission between matches.

Arena mode overview

An arena match is a last-team-standing game mode. Teams of players register for the match. When enough teams have registered, a countdown begins. At the end of the countdown, all registered players are teleported into a bounded arena area. A shrinking safe zone -- the compactor circle -- closes in over the course of the match. Players who stand outside the safe zone take damage. The damage increases the longer they remain outside. The last surviving team wins.

The seventeen Arena keys configure every timing variable in that sequence. Nothing about an arena match's pacing is hardcoded. The delay before the circle shrinks, the speed of the shrink, whether the shrink pauses between stages, how much damage the boundary deals, how long the victory screen displays, and how long players wait between matches are all values you set in this section.

Match start: Arena_Min_Players and Arena_Clear_Timer

Arena_Min_Players sets the number of teams that must be registered before the arena match readiness countdown can begin. The key counts teams, not individual players. A value of 2 means two teams of any size (including solo teams) satisfy the requirement. A value of 4 means four teams must register before the countdown starts. The key is named Min_Players but operates on team count -- this is a naming artifact from the game's internal representation and is worth noting to avoid confusion with player count.

A value of 1 allows a match to start with a single team registered. This is useful for testing arena configuration on a private or local server where only one team is present. On a public server, a minimum of 1 means the match starts as soon as any team registers, which effectively eliminates the waiting phase entirely.

Arena_Clear_Timer is the countdown, in seconds of real time, between the moment the minimum team count is reached and the moment the server teleports all registered players into the arena. This is the "match ready" period. Players see a timer counting down. They can use these seconds to confirm their loadout, communicate strategy with teammates, or decide to leave the queue before the teleport fires.

A short clear timer (e.g., 5 seconds) starts the match almost immediately once enough teams register. This keeps lobby waiting time minimal but gives players little opportunity to adjust once the threshold is met. A long clear timer (e.g., 60 seconds) gives players a full minute of preparation but extends the time everyone waits for the match to actually begin. The correct value depends on how much preparation your arena mode requires and how much waiting your players tolerate.

Compactor damage system

Two keys control the damage players take while their position is outside the compactor circle:

Arena_Compactor_Damage is the base damage per second. Every second that a player remains outside the safe zone, the server applies this much damage. The damage is the same whether the player is one meter outside the boundary or one hundred meters outside. Distance from the circle does not affect the base damage rate.

Arena_Compactor_Extra_Damage_Per_Second is an accumulating additional damage value. Each second a player stays outside the circle, the server adds this value to the damage dealt that second. The first second outside applies the base damage alone. The second second applies base damage plus the extra damage. The third second applies base damage plus twice the extra damage. This accumulation continues until the player steps back inside the safe zone, at which point the extra-damage counter resets.

This two-key system creates a distinction between briefly stepping outside (punishing but survivable) and staying outside for more than a few seconds (rapidly lethal). A server owner who wants the compactor boundary to be a strict hard wall -- instant death for stepping out -- sets the base damage high and the extra damage high. A server owner who wants the boundary to be a soft warning that gives players time to correct their position sets the base damage moderate and the extra damage low.

The extra damage is a float, meaning it can be set to fractional values. A value of 0.5 adds half a point of damage per second of accumulation, which produces a slow ramp. A value of 5.0 adds five points per second of accumulation, which produces a steep ramp that kills quickly even if the base damage is low.

The five arena timer phases

The arena match lifecycle has five distinct timing phases, each with its own key. Understanding what happens in each phase and how they chain together is essential to configuring arena matches that feel well-paced.

Phase 1: Compactor Delay (Arena_Compactor_Delay_Timer)

This is the initial grace period after players are teleported into the arena. The timer counts down in seconds of real time. During this phase, the full arena area is safe. No compactor circle is visible or active. Players can move freely, find weapons or equipment placed on the arena floor, take positions, and orient themselves relative to their teammates and the map geometry.

A short delay (e.g., 15 seconds) rushes players into combat-focus immediately. A long delay (e.g., 120 seconds) gives players time to loot and plan. The compactor delay is separate from the clear timer -- the clear timer counts down in the lobby, the compactor delay counts down inside the arena after teleport.

When Arena_Compactor_Delay_Timer reaches zero, the compactor circle appears and begins its first shrink phase.

Phase 2: Compactor Shrink and Pause Cycle

After the delay timer expires, the compactor circle starts shrinking. The behaviour during this phase depends on the Arena_Use_Compactor_Pause boolean.

If Arena_Use_Compactor_Pause is false, the circle shrinks continuously toward the initial center at the speed defined by the appropriate Arena_Compactor_Speed_* key. There are no pauses. The safe zone steadily contracts from its starting radius down to zero. This is a single continuous phase.

If Arena_Use_Compactor_Pause is true, the server enters a cycle of shrink steps and pause periods. Each shrink step reduces the circle's radius at the compactor speed. When the step completes, the server starts the Arena_Compactor_Pause_Timer. During the pause, the circle does not shrink. When the pause timer expires, the server selects a new smaller circle within the current one (using Arena_Compactor_Shrink_Factor to determine the new radius), starts the next shrink step, and then pauses again. This cycle repeats until the circle reaches its minimum size or only one team remains.

Arena_Compactor_Pause_Timer controls how long each pause lasts in seconds of real time. A short pause (e.g., 5 seconds) gives players only moments to reposition. A long pause (e.g., 30 seconds) creates extended periods of relative safety between shrink steps, allowing for deliberate movement and tactical repositioning.

Phase 3: Match Resolution

The match ends when only one team has surviving players. At that moment, the server declares a winner and starts the Arena_Finale_Timer.

Phase 4: Finale (Arena_Finale_Timer)

Arena_Finale_Timer controls how many seconds the server waits after declaring a winner before proceeding to the intermission phase. During the finale, the victory screen is displayed, the winning team's name is announced, and players can review the match outcome. The server does not accept new match registrations during the finale.

A very short finale (e.g., 3 seconds) shows the result briefly and moves on. A long finale (e.g., 30 seconds) gives players time to discuss the match, view stats if the server provides them, and mentally transition from the completed match to the expectation of the next one.

Phase 5: Intermission (Arena_Restart_Timer)

Arena_Restart_Timer controls how many seconds of intermission the server waits between the end of one match cycle (after the finale timer expires) and the beginning of the next match cycle. During intermission, the server resets the arena state. Players can re-register for the next match, adjust loadouts, or leave the arena queue.

When the restart timer expires, the server checks Arena_Min_Players again. If enough teams are registered, the clear timer begins. If not, the server waits until the minimum team count is reached. The restart timer is the minimum intermission duration -- if teams register before it expires, the match does not start early. If no teams register by the time it expires, the server waits indefinitely until the minimum is met.

Short restart timers (e.g., 10 seconds) produce rapid match cycling with little downtime. Long restart timers (e.g., 120 seconds) give players meaningful breaks between matches but reduce the pace of the arena experience. The correct value balances match frequency against player fatigue.

Compactor pause mode: Arena_Use_Compactor_Pause

Arena_Use_Compactor_Pause is a boolean that changes the fundamental behaviour of the compactor circle during the shrink phase.

When set to true, the server uses a multi-step shrink model. Rather than shrinking the circle continuously toward the initial center, the server shrinks the circle to a new smaller size, then pauses (using the Arena_Compactor_Pause_Timer), then selects a new smaller circle within the previous one's boundaries, then shrinks to that size, then pauses again. Each new circle is placed algorithmically somewhere within the bounds of the previous circle, not necessarily centered on the original arena center. This means the safe zone can drift across the arena map over successive shrink steps.

When set to false, the compactor circle shrinks continuously toward the initial center of the arena, with no pauses and no sub-circle selection. The circle simply contracts from its starting radius down to zero at the speed defined by the compactor speed key. The Arena_Compactor_Pause_Timer and Arena_Compactor_Shrink_Factor keys are ignored.

The choice between these two modes changes the arena experience substantially. Pause mode introduces moments of relative safety between shrink steps, where the circle stops closing and players can move and reposition. It also introduces positional unpredictability because the next safe zone center is not known until the server selects it. Continuous mode keeps constant pressure on players -- the safe zone is always shrinking, and standing still means the boundary will reach you eventually.

Compactor shrink speeds

Five keys set the speed at which the compactor circle's radius shrinks, one for each level size category:

Key	Level size it applies to
Arena_Compactor_Speed_Tiny	Tiny maps
Arena_Compactor_Speed_Small	Small maps
Arena_Compactor_Speed_Medium	Medium maps
Arena_Compactor_Speed_Large	Large maps
Arena_Compactor_Speed_Insane	Insane maps

Each value is in meters per second of radius reduction. When the compactor circle is shrinking, the server reads one of these five keys -- the one that matches the loaded map's size category -- and reduces the safe zone radius by that many meters each second of real time.

At any given moment, exactly one shrink speed key is active. The other four exist in Config.json and in memory but are not consulted. Changing maps changes which key is the active one. A server that primarily runs a Small map needs its Arena_Compactor_Speed_Small value tuned carefully; the Tiny, Medium, Large, and Insane values are irrelevant until the server loads a map of that size.

The practical tuning challenge is that the same shrink speed value produces different experiences on different map sizes. A shrink speed of 1.0 meters per second on a Tiny map (which may have a starting arena radius of perhaps a few tens of meters) closes the safe zone much faster relative to the playable area than 1.0 meters per second on an Insane map (which has a much larger starting arena). The separate keys exist so server owners can tune each map size independently.

There is no universal recommended shrink speed. A starting point is to set speeds that feel proportionally faster on smaller maps and slower on larger maps, reflecting the distance players must travel to reach the safe zone. A server owner who wants fast, aggressive matches on every map size sets high speeds across the board. A server owner who wants methodical, strategic matches sets lower speeds.

Arena_Compactor_Shrink_Factor

Arena_Compactor_Shrink_Factor is a decimal proportion between 0 and 1 that controls how much of the current circle's radius is retained when the server selects the next smaller circle during pause-mode shrink. This key only applies when Arena_Use_Compactor_Pause is true.

When the pause timer expires and the server needs to pick a new safe zone, it takes the current circle's radius and multiplies it by Arena_Compactor_Shrink_Factor. The result is the radius of the new circle. The server then places that new circle somewhere inside the current circle's boundaries.

If the current circle has a radius of 100 meters and Arena_Compactor_Shrink_Factor is set to 0.5, the new circle has a radius of 50 meters -- half the current safe zone area is lost in one step. If the factor is 0.75, the new circle has a radius of 75 meters, and only a quarter of the radius is lost per step.

A high factor (close to 1.0) makes each shrink step a small incremental reduction. This produces many shrink steps, each removing a small slice of the arena, and extends the total match duration. A low factor (close to 0) aggressively shrinks the safe zone with each step, producing few but dramatic shrink events that force players into tight quarters quickly.

Values outside the range of 0 to 1 are not valid. The internal game description specifies the valid range as [0, 1], inclusive. A value of 0 reduces the next circle's radius to zero instantly, which is functionally equivalent to ending the match at the first shrink step. A value of 1 keeps the circle at its current radius and, if the server interprets this as "select the same circle again," may produce behaviour that does not advance the match.

Canned Beans

The Config.json Events section has no direct relationship with canned beans. Neither the legacy weather system, the modern weather multipliers, the airdrop scheduler, nor the arena compactor framework references or interacts with the canned beans item (base-game ID 13) in any way. No key in this section references any food item ID, inventory slot, consumeable type, or hunger system.

The absence is honest and unremarkable. The Events section governs scheduled world-level occurrences -- rain, snow, weather transitions, care package flyovers, arena match phases. Canned beans are a food item that restores 37 food units and 12 water units on consumption per the official Unturned asset definition. The two systems operate in entirely separate domains of the engine: events at the world-scheduler level, items at the inventory-consumable level. No arena player has ever been eliminated by bean damage, no airdrop has ever been triggered by eating a can of beans, and no weather event has ever been tied to the sodium content of navy beans packed in a liquid medium.

For the full documented history of the canned beans -- including can geometry, the pull-tab lid variant analysis, nutritional profile, distribution across every Unturned map, survivor culture and rationing practices, the spiritual significance of the first found can, the unnamed cannery's role in the pre-collapse supply chain, and the 57 Studios canonical framework's treatment of the item as a survival staple, trade currency, and narrative device -- see the Canned Beans Lore article, which is the definitive wiki reference for the item's in-universe and canonical documentation.

Practical use for server owners

This section is written for the server owner who has pulled up Config.json in a text editor and wants to know what to change and what to leave alone. It covers common starting points, step-by-step enable sequences for each event system, and the key interactions that produce unexpected behaviour if you are not aware of them.

Starting with a safe baseline

If your Events section is entirely empty or missing from Config.json, every key initializes to its zero or zero-equivalent value at server start. A Use_Airdrops of false means no airdrops. A Weather_Duration_Multiplier of zero means no modern weather. Zero legacy duration keys mean no legacy rain or snow. Zero arena timers and a zero Arena_Min_Players mean no arena matches will start.

This safe-baseline behaviour is useful. It means you can add a minimal Events section to an existing Config.json file that has never defined events before, and the server will start with all event systems disabled by default. Nothing will change for your players until you deliberately set values that enable systems.

The recommended sequence for building out an Events section from scratch is:

1. Add every key listed in the key reference table above, even if you set most of them to zero or false. An explicit key with a zero value is easier to find and adjust later than an absent key that the server silently defaults.
2. Enable and tune one system at a time. Start with weather (if your map supports it), then airdrops, then arena. Test each system in isolation before enabling the next one.
3. Observe the system in-game for at least a full cycle (several weather transitions, several airdrop passes, one full arena match) before adjusting values.

Enabling airdrops

To enable periodic airdrops on your server, three changes are necessary and sufficient:

1. Set Use_Airdrops to true.
2. Set Airdrop_Frequency_Min and Airdrop_Frequency_Max to positive float values. A common starting point is 1.0 for the minimum and 3.0 for the maximum, which produces an airdrop roughly every game-day or two with some natural variation.
3. Optionally adjust Airdrop_Speed and Airdrop_Force to suit your map's size and your players' reaction-time expectations.

If airdrops are enabled but no custom airdrop assets are configured on the loaded map, the server falls back to the default care package model and the default landed barricade. The airdrop system does not error out. It simply uses the built-in defaults.

Enabling arena matches

Arena matches require more keys to be set meaningfully than airdrops do. The minimum viable configuration is:

• Arena_Min_Players: set to 2 (or 1 for testing).
• Arena_Clear_Timer: set to 30 (thirty seconds of lobby readiness countdown).
• Arena_Compactor_Delay_Timer: set to 60 (one minute of safe movement inside the arena before the circle appears).
• Arena_Compactor_Damage: set to a non-zero value. A starting point of 10 damage per second makes the boundary meaningful without being instantly lethal.
• Arena_Compactor_Extra_Damage_Per_Second: set to a moderate value. A starting point of 2.0 means the second second outside deals 12 damage, the third deals 14, and so on.
• Arena_Finale_Timer: set to 10 (ten seconds of victory screen).
• Arena_Restart_Timer: set to 20 (twenty seconds between matches).
• Arena_Compactor_Pause_Timer: set to 15 if using pause mode.
• Arena_Use_Compactor_Pause: true for multi-step shrinks with safe pauses, or false for continuous shrinking.
• Arena_Compactor_Shrink_Factor: set to something moderate like 0.6 if using pause mode.
• The appropriate Arena_Compactor_Speed_* key for your map's size, set to a non-zero value. Starting points might be 0.5 for Tiny, 1.0 for Small, 1.5 for Medium, 2.0 for Large, and 2.5 for Insane, though the correct value depends heavily on arena dimensions.

Test the full match cycle at least once with these starting values before tuning. Watch how long each phase feels in real time. Adjust one timer at a time and retest.

Tuning weather

For legacy-weather maps, the process is:

1. Decide whether you want rain, snow, both, or neither.
2. For each weather type you want, set positive frequency and duration ranges. A reasonable rain starter is Rain_Frequency_Min: 2.0, Rain_Frequency_Max: 5.0, Rain_Duration_Min: 0.5, Rain_Duration_Max: 1.5. A reasonable snow starter mirrors the same ranges with the snow key names.
3. For each weather type you do not want, zero both of its duration keys.
4. Run the server and observe several cycles of weather. Widen or narrow the frequency spread and duration spread based on how much variation you want.

For modern-weather maps, the process is simpler:

1. Start with both multiplier keys at 1.0. This passes the map author's base timing through unchanged.
2. Play through several weather transitions at default pace.
3. Adjust one multiplier at a time. Remember that lower Weather_Frequency_Multiplier means faster weather changes (more frequent), and higher means slower changes (less frequent). The duration multiplier is intuitive: lower means shorter weather events, higher means longer.
4. To disable weather entirely, set Weather_Duration_Multiplier to 0.

Testing changes without restarting

Config.json changes are read at server start. There is no hot-reload mechanism for the Events section. To test a new configuration, you must stop the server, edit the file, and start the server again.

The one partial exception is weather tuning on modern-weather maps. The /weather 0 console command can immediately reschedule the next weather event, which allows you to see the result of a frequency or duration multiplier change without waiting for a full natural weather cycle to complete. This is a diagnostic command, not a substitute for a restart -- the multiplier values in Config.json are only re-read on startup. The command triggers the scheduler but does not reload the multipliers.

Key interactions to watch for

Several keys have dependencies that are not obvious from the flat alphabetical ordering of the key reference table:

• Master switches disguise cadence keys. Airdrop_Frequency_Min and Airdrop_Frequency_Max have no effect when Use_Airdrops is false. If airdrops are not appearing, check the toggle before the frequency values.
• Pause-mode keys are conditional. Arena_Compactor_Pause_Timer and Arena_Compactor_Shrink_Factor are only read by the server when Arena_Use_Compactor_Pause is true. If you set pause mode to false, these keys still exist in Config.json and in memory, but the server ignores them during match execution.
• One shrink speed is active at a time. Only the Arena_Compactor_Speed_* key matching the loaded map's size category is read during a match. The other four are present but ignored. Changing the Tiny speed does nothing on a Medium map.
• Legacy and modern weather are mutually exclusive at the map level. A given map uses one weather pipeline. The server reads one set of weather keys and ignores the other. Both sets can exist in Config.json simultaneously without conflict.
• Duration zero disables a weather type. Setting Rain_Duration_Min and Rain_Duration_Max both to zero disables legacy rain. Setting one to zero and the other to a positive value may produce intermittent rain behaviour. Zero both or neither for predictable results.
• Team count, not player count. Arena_Min_Players counts teams. A solo player on each of two teams satisfies a value of 2. Nine players on a single team do not.
• Arena timers are in real seconds. The five arena timer keys (Clear, Finale, Restart, Compactor_Delay, Compactor_Pause) use seconds of real time as their unit. Do not confuse these with the in-game-day units used by the weather frequency and duration keys.

JSON syntax notes

The Events section is a JSON object within the larger Config.json object. Every key name must be double-quoted. Every string value must be double-quoted. Numbers are unquoted. Booleans (true, false) are lowercase and unquoted.

The section ends with a closing brace. If the Events section is not the last top-level section in Config.json, that closing brace must be followed by a comma before the next section. If it is the last section, the closing brace must not have a trailing comma. The server's JSON parser will not warn you about a trailing comma -- it will fail to parse the file and the server will not start. The error message may not identify the trailing comma as the cause.

A minimal valid Events section that disables every event system is provided below. Every key is present and set to a value that produces no events. This is a safe starting template. To activate a system, change the relevant values away from zero and set the relevant boolean toggles to true.

"Events": {
  "Rain_Frequency_Min": 0.0,
  "Rain_Frequency_Max": 0.0,
  "Rain_Duration_Min": 0.0,
  "Rain_Duration_Max": 0.0,
  "Snow_Frequency_Min": 0.0,
  "Snow_Frequency_Max": 0.0,
  "Snow_Duration_Min": 0.0,
  "Snow_Duration_Max": 0.0,
  "Weather_Frequency_Multiplier": 0.0,
  "Weather_Duration_Multiplier": 0.0,
  "Airdrop_Frequency_Min": 0.0,
  "Airdrop_Frequency_Max": 0.0,
  "Airdrop_Speed": 0.0,
  "Airdrop_Force": 0.0,
  "Arena_Min_Players": 0,
  "Arena_Compactor_Damage": 0,
  "Arena_Compactor_Extra_Damage_Per_Second": 0.0,
  "Arena_Clear_Timer": 0,
  "Arena_Finale_Timer": 0,
  "Arena_Restart_Timer": 0,
  "Arena_Compactor_Delay_Timer": 0,
  "Arena_Compactor_Pause_Timer": 0,
  "Use_Airdrops": false,
  "Arena_Use_Compactor_Pause": false,
  "Arena_Compactor_Speed_Tiny": 0.0,
  "Arena_Compactor_Speed_Small": 0.0,
  "Arena_Compactor_Speed_Medium": 0.0,
  "Arena_Compactor_Speed_Large": 0.0,
  "Arena_Compactor_Speed_Insane": 0.0,
  "Arena_Compactor_Shrink_Factor": 0.0
}

Common misconfigurations

The following are the most frequently observed configuration mistakes in the Events section. Each is described with its symptom, cause, and fix.

Weather never changes on a modern-weather map

Symptom: The weather stays on one weather type indefinitely and never transitions. Players report the same weather condition for the entire session.

Most likely cause: Weather_Duration_Multiplier is set to zero. A zero duration means every weather event ends instantly, but the scheduler may not advance to the next type correctly.

Fix: Set Weather_Duration_Multiplier to 1.0 (the map's base durations unchanged) and test. If weather still does not change, use the /weather 0 command to manually reschedule the next transition, then tune the frequency multiplier upward or downward from 1.0 as needed.

Airdrops never appear despite Use_Airdrops being true

Symptom: Players report never seeing an airdrop plane or care package. Use_Airdrops is set to true in Config.json.

Most likely cause: One or both of Airdrop_Frequency_Min and Airdrop_Frequency_Max are set to zero or to very high values. If both frequency keys are zero, the server may never schedule the first airdrop. If they are set to extremely high values (e.g., 100.0), the airdrop is scheduled so far into the future that it never arrives during a normal play session.

Fix: Set both frequency keys to positive, reasonable values (e.g., Airdrop_Frequency_Min: 1.0 and Airdrop_Frequency_Max: 3.0), restart the server, and wait for at least one full in-game day cycle.

Arena match never starts despite players being registered

Symptom: Players join the arena queue, but the match never begins. All arena keys appear to have values.

Most likely cause: Arena_Min_Players is set higher than the number of teams currently registered. Remember that this key counts teams, not players. If three players are all on one team and Arena_Min_Players is set to 2, the requirement is not met. The server counts only one team.

Fix: Lower Arena_Min_Players to match the typical team count on your server. For a small server where only two teams can be expected, set Arena_Min_Players to 2. For testing with only yourself present, set it to 1.

Compactor circle does not shrink

Symptom: The arena match starts, the delay timer counts down, but the compactor circle never moves. Players stand in the arena indefinitely with no shrinking safe zone.

Most likely cause: The Arena_Compactor_Speed_* key for the loaded map's size category is set to zero. If the shrink speed is zero, the circle radius never decreases, and the match cannot conclude naturally.

Fix: Set all five Arena_Compactor_Speed_* keys to positive values. Even if you only plan to run one map size, setting all five guards against accidental zero-speed conditions when a different map is loaded.

No damage taken while outside the compactor circle

Symptom: Players stand outside the compactor boundary and take no damage. The circle is visible and shrinking, but the boundary has no mechanical effect.

Most likely cause: Both Arena_Compactor_Damage and Arena_Compactor_Extra_Damage_Per_Second are set to zero. The compactor circle is a visual element, but the damage system is not active.

Fix: Set Arena_Compactor_Damage to a non-zero value. A starting point of 10 damage per second is enough to be noticeable without being instantly lethal. Set Arena_Compactor_Extra_Damage_Per_Second to a moderate value such as 2.0 to create a damage ramp for players who stay outside.

Legacy rain keys set but no rain appears

Symptom: Legacy rain frequency and duration keys are set to non-zero values, but no rain ever falls on the map.

Most likely cause: The loaded map uses the modern weather pipeline. Legacy rain and snow keys are ignored on modern-weather maps. The server reads the frequency and duration values but does nothing with them.

Fix: If your map uses modern weather, adjust Weather_Frequency_Multiplier and Weather_Duration_Multiplier instead of the legacy rain keys. If your map uses legacy weather and rain is not appearing despite non-zero duration values, check that both frequency keys and both duration keys are set to non-zero values. If only frequency keys are set but duration keys are zero, rain events have zero duration and end instantly.

Pause-mode compactor circle does not pause

Symptom: Arena_Use_Compactor_Pause is set to true, Arena_Compactor_Pause_Timer is set to a positive value, but the compactor circle shrinks continuously with no pauses.

Most likely cause: Arena_Compactor_Shrink_Factor is set to 0. When the shrink factor is zero, the server may select a new circle with a radius of zero, which ends the shrink cycle immediately and may skip the pause phase.

Fix: Set Arena_Compactor_Shrink_Factor to a value between 0.1 and 0.9. A value of 0 is technically in range but functionally equivalent to ending the match at the first shrink step.

Frequently asked questions

Which weather system does my map use?

The source notes do not provide a Config.json key or flag that identifies the map's weather pipeline. The pipeline is a property of the level asset. A practical diagnostic is to set the legacy rain duration keys to a high value (such as 10.0) and restart the server. If rain appears in-game for an extended period, the map uses the legacy system. If no rain appears, the map uses the modern system.

Can I use both legacy and modern weather on the same map?

The source notes describe two separate weather pipelines: legacy features for backwards compatibility with older maps, and modern features for maps that have been updated. A map uses one pipeline. The Config.json contains keys for both so that a single configuration file works regardless of which map is loaded, but the server reads only the keys relevant to the loaded map's pipeline. There is no configuration that makes both pipelines active simultaneously on the same map.

What happens if I set Airdrop_Frequency_Min higher than Airdrop_Frequency_Max?

The min/max model implies the server picks a random value between the two boundaries. This requires the minimum to be less than or equal to the maximum. Setting the minimum higher than the maximum is a misconfiguration. The source notes do not describe the server's behaviour when this occurs. Set the minimum to your shortest acceptable interval and the maximum to your longest.

How do the arena compactor speeds interact with pause mode?

The shrink speed is the same value in both modes. When Arena_Use_Compactor_Pause is true, the circle shrinks in steps at the defined speed, pauses, and then shrinks again. When false, the circle shrinks continuously at the defined speed without pauses. The Arena_Compactor_Pause_Timer controls how long each pause lasts between steps, but it does not change how fast the circle shrinks during a step. The pause mode adds breaks between shrinkage -- it does not alter the shrinkage rate itself.

Can I set Arena_Min_Players to 1?

Yes. A value of 1 means a single registered team satisfies the minimum player count, and the match readiness countdown begins immediately. This is useful for testing arena configuration on a private server where you are the only connected player. On a public server, a minimum of 1 eliminates the waiting phase and is generally not the intended multiplayer arena experience.

What happens if I set Airdrop_Speed to zero?

A speed value of zero would mean the airdrop plane does not move along its flight path, which would prevent the airdrop sequence from completing normally. The source notes do not describe the behaviour of a zero-speed airdrop plane. A practical minimum should be a positive value high enough for the plane to visibly traverse the level.

Do the events keys affect single-player or LAN games?

The Events section is part of the dedicated server Config.json. The source notes draw from EventsConfigData within PlayConfigData.cs, which the dedicated server binary reads. Single-player and LAN sessions may use different configuration paths or internal defaults. This article covers the dedicated server Config.json specifically.

Can I change events while the server is running?

Config.json is read at server start. Changes to the Events section do not take effect until the server is stopped and started again. There is no in-game command or admin panel that reloads the Events section from disk while the server process is running. The /weather 0 command can trigger the weather scheduler on a modern-weather map, but it does not reload multiplier values from Config.json.

Why does my modern-weather map ignore the rain frequency keys?

A modern-weather map uses the Weather_Frequency_Multiplier and Weather_Duration_Multiplier keys, not the legacy rain and snow keys. The legacy keys are present in Config.json and are read into memory, but the server does not consult them when scheduling weather on a modern-weather map. This is normal and expected. To control weather on a modern-weather map, adjust the multiplier keys.

Do I need to set all five arena compactor speed keys?

You should set all five to reasonable values, even though only one is active at any given time. If your server ever loads a map of a different size category, the corresponding speed key will become the active one. If you leave it at zero, the compactor circle will not shrink on that map, which effectively breaks arena matches. Setting all five to sensible values ensures arena mode works correctly regardless of which map is loaded.

How do I know which arena compactor speed key is active?

Look up the loaded map's size category in the level asset or the map's documentation. The Unturned level editor categorizes maps as Tiny, Small, Medium, Large, or Insane. The server reads the speed key whose suffix matches that category. If you do not know your map's size category, set all five speed keys to the same value as a safe fallback -- the correct one will be used, and the incorrect ones are harmless.

Why does my arena match never start?

Check Arena_Min_Players first. If it is set to a value higher than the number of registered teams, the readiness countdown will never begin. Remember that the key counts teams, not individual players. If eight players are all on one team, Arena_Min_Players set to 2 is not satisfied. Check also that Arena_Clear_Timer is non-zero -- a zero clear timer may not offer a visible countdown in the lobby, which can make the match appear unresponsive even though it begins instantly.

What is the difference between Arena_Clear_Timer and Arena_Compactor_Delay_Timer?

The clear timer runs in the lobby, before players are teleported. It counts down the preparation period once enough teams have registered. The compactor delay timer runs inside the arena, after players have been teleported. It counts down the grace period before the compactor circle appears and begins shrinking. Both are in seconds of real time. Both serve to give players preparation time, but the clear timer is lobby preparation and the compactor delay timer is arena preparation. A long clear timer with a short compactor delay means players wait in the lobby and get little time inside the arena before the circle closes. A short clear timer with a long compactor delay means players enter quickly and have an extended safe period to move and loot inside the arena.