Skip to content

How to configure DayZ Expansion airdrops on a PC server

By

Updated

Add scheduled and player-called supply drops to your DayZ Steam PC server with Expansion Missions. Begin with one medical crate on a test instance. Check its location and contents before expanding the rotation or adding combat encounters.

Apply the examples as field edits to files generated by your installed release. The reviewed public code is older than the author’s July 2026 Missions update. We have not compared it with that package or run a live airdrop session. Read the source and test limits at the end before using the examples.

Select the original DayZ-Expansion-Missions item, Workshop ID 2792984177. It requires CF 1559212036, Dabs Framework 2545327648 and Expansion Core 2291785308. Expansion Bundle includes Missions. Resolve this package choice before building your load list so Bundle and an individual Missions package do not overlap.

If your manual installation uses the folder names shown, add this client-required argument to the launch command you use for the instance:

"-mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@DayZ-Expansion-Missions"

Follow Expansion installation for signing keys, mission preparation and the CF warning for saved worlds. In VXPanel, stop the test service and select Mods. Search by Workshop ID, install the client-required packages and compare Installed mods with the author’s requirements. Put frameworks before Core, followed by Missions. Consult the Mods reference for those controls and Files and SFTP for editing.

Add optional features when you need them. Licensed 2116157322 supports the animated plane; Navigation 2792984722 supplies Expansion markers. AI enemies need the AI module and patrol and workload checks. The first crate test can proceed without those additions unless your selected installation includes them.

Back up the mission, profiles and saved world while the service is stopped, following backup and recovery. Initialize the chosen packages on a test instance with separate world data and profiles. Save its startup log, then stop it to edit.

Read the service’s -profiles argument and mission selection. The source path constants distinguish profile settings from mission-side events:

File Where to find it and what it controls
ExpansionMod/Settings/MissionSettings.json Active profiles directory: automatic event scheduling.
ExpansionMod/Settings/AirdropSettings.json Active profiles directory: crate presets and shared flight, infected and marker behavior.
expansion/missions/Airdrop_*.json Active mpmissions/dayzOffline.<terrain>/ mission: scheduled locations and event definitions.
Scroll to see all columns →

Name copied events with the prefix Airdrop_, preserving case. The loader reads the event type from that prefix; MedicalDrop.json does not name the airdrop class.

The inspected versions are MissionSettings 2, AirdropSettings 8 and airdrop event 3. Retain the m_Version and fields generated for each file by your release. The JSON blocks below are partial edits to existing files or entries. Merge their fields into those records, preserving everything else.

Merge this scheduler patch into the test instance’s MissionSettings.json:

{
"Enabled": 1,
"InitialMissionStartDelay": 300000,
"TimeBetweenMissions": 3600000,
"MinMissions": 0,
"MaxMissions": 1,
"MinPlayersToStartMissions": 1
}

These fields let one automatic mission run at a time and require at least one player before it can start. The first delay is 300,000 milliseconds, or five minutes; the subsequent delay is 3,600,000 milliseconds, or one hour. Inside an airdrop event, MissionMaxTime instead uses seconds.

In the inspected scheduler code, the population check precedes the first delay. TimeBetweenMissions is queued when an event ends. Expect the initial scheduling delay after population qualifies, then the subsequent delay after the previous event finishes. Those delays do not define an hourly plane-arrival schedule.

Join from a test client to meet this example’s player requirement. Each server restart begins the initial sequence again. When a later drop seems delayed, inspect the event that is still running before changing its successor’s timer.

Copy a generated event to Airdrop_SupplyCache.json under the active mission’s expansion/missions/. For this test, set the other generated events to Enabled: 0; preserve their backup copies. One enabled event lets you inspect the chosen location and crate without another event entering the rotation.

Keep the copied flight fields and merge this patch at the event’s top level:

{
"Enabled": 1,
"Weight": 1.0,
"MissionMaxTime": 1200,
"MissionName": "SupplyCache",
"ShowNotification": 1,
"Container": "ExpansionAirdropContainer_Medical",
"FallSpeed": 4.5,
"ItemCount": 3,
"InfectedCount": 0,
"Infected": ["ZmbM_HermitSkinny_Beige"],
"Loot": [
{
"Name": "BandageDressing",
"Attachments": [],
"Chance": 1.0,
"QuantityPercent": 100,
"Min": 1,
"Max": 2,
"Variants": []
},
{
"Name": "WaterBottle",
"Attachments": [],
"Chance": 1.0,
"QuantityPercent": 100,
"Min": 1,
"Max": 1,
"Variants": []
}
]
}

Edit x and z inside the existing DropLocation object using coordinates measured on your terrain. An admin export in [X,Y,Z] order provides those in its first and third positions; the middle value is elevation. Give Name a recognisable location label. Choose a Radius and inspect the landing area from a player client, including water, buildings and map boundaries. Measure new coordinates on Banov or DeerIsle instead of assuming a Chernarus location is safe there.

Use the generated Height, DropZoneHeight, Speed and DropZoneSpeed for the first test. Crate FallSpeed controls descent, while the other speed fields control plane travel. Shared HeightIsRelativeToGroundLevel affects height interpretation. Wind drift can move the crate during descent, so confirm touchdown rather than treating the circle as an exact landing guarantee.

The event’s InfectedCount: 0 sets the encounter count to zero. Its classname array must remain nonempty to avoid the preset-lookup branch described below. ZmbM_HermitSkinny_Beige comes from the author’s defaults; this zero-count recipe does not spawn it.

The inspected airdrop event code looks for a preset when either Loot or Infected is empty. It needs a matching crate in AirdropSettings.json with Usage 0 or 1. Without one, it reports a compatible-container error and returns before creating the plane.

Scheduled configuration Result in the inspected implementation
Concrete crate with both arrays nonempty Uses the event’s loot and infected arrays. This example keeps its infected count at zero.
Concrete crate with custom loot and empty Infected Finds a scheduled-use preset and inherits its infected list, retaining InfectedCount: 0 when set.
Concrete crate with empty Loot and a populated infected list Finds a scheduled-use preset and inherits its loot.
Container: "Random" with empty arrays Chooses an eligible scheduled-use preset and fills both arrays.
An empty array without an eligible matching preset No plane is created. Giving the custom crate a name does not remove this requirement.
Scroll to see all columns →

To inherit a random preset, change a copied scheduled event to Container: "Random", clear its Loot and Infected arrays and set both ItemCount and InfectedCount to -1. Supply usable presets with positive weights and Usage 0 or 1 in the shared settings. For custom event arrays, name a concrete crate classname.

Preset Usage is 0 for both paths, 1 for scheduled events and 2 for player-called drops. Shared presets let several locations inherit the same loot definition. Check which presets qualify when restoring your full event rotation.

The medical recipe targets two bandages and one water bottle. Its minimum selections use two attempts; its remaining maximum allowance permits one more bandage. Check the spawned inventory to confirm that result. Bad classnames and cargo-placement failures can leave fewer objects than the selection counter suggests.

After minimum selections, the inspected loot spawner treats main-item Chance as a relative weight. A value of 1.0 alone does not guarantee an item in every crate. Check that remaining weights stay positive and Max allowances can supply the intended count.

In the reviewed loot schema, Attachments contains nested objects. For a bandage added inside a FirstAidKit entry, one element of its attachment array can be:

{
"Name": "BandageDressing",
"Chance": 1.0,
"Attachments": []
}

Place this object inside that entry’s Attachments array. Some older author-wiki examples use attachment strings or malformed variant JSON. Parse your edited file and compare it with your release’s generated schema. Then check the classname and attachment in game; valid JSON doesn’t mean the class exists or the attachment fits.

Player-called drops choose a shared AirdropSettings.json preset with Usage 0 or 2. An Airdrop_*.json location does not determine their destination. For the test, keep one qualifying medical preset and give it the earlier two-entry Loot array. Merge these fields into that preset:

{
"Container": "ExpansionAirdropContainer_Medical",
"Usage": 2,
"Weight": 1.0,
"ItemCount": 3,
"InfectedCount": 0,
"SpawnInfectedForPlayerCalledDrops": 0
}

Preserve the entry’s other fields, including FallSpeed. On this test copy, exclude other presets from player calls by giving them Usage: 1, which retains their scheduled use. Restore the desired weights and usage policy after recording the test result.

Call the drop with ExpansionSupplySignal or supply-flare ammunition Expansion_Ammo_FlareSupplyRed, Expansion_Ammo_FlareSupplyGreen or Expansion_Ammo_FlareSupplyBlue. The reviewed handler does not use ordinary smoke grenades or road flares as supply calls. Begin with admin-spawned items. For economy spawning, register definitions supplied by the installed package using the Expansion economy procedure.

The supply signal invokes a drop at its own position after the fuse delay. The inspected supply-flare handler records the flaregun’s firing position, rather than the projectile’s impact. Use an open calling area and retain the observed touchdown location.

For player calls, SpawnInfectedForPlayerCalledDrops decides whether to pass the preset’s infected list and count to the drop. The reviewed CallAirdrop method does not check the automatic scheduler’s Enabled flag. After turning off scheduled missions, check supply calls separately before treating them as disabled. Test both behaviors against the policy you intend to enforce.

Start the test service, read its logs and join with matching client-required mods. Record the map, package versions, edited files and elapsed times alongside these observations:

Test Record to retain
Loaded configuration Correct mission and profiles; no JSON, missing-class or compatible-container errors.
Scheduled plane and crate Intended event follows the population gate and initial delay; plane and crate reach the inspected area.
Medical contents Two intended bandages and one water bottle exist with usable quantities. Count objects in the crate.
Encounter population No encounter infected from this drop; account for infected already present on the map.
Supply-item call Each selected supply item starts a drop from its documented calling position using the eligible preset.
Event end and successor Previous event ends, the subsequent delay is measured and no unintended test crate remains.
Scroll to see all columns →

Here MissionMaxTime: 1200 means 1,200 seconds, or twenty minutes. The inspected event resets its elapsed counter when it obtains the spawned crate. At the limit, it sets that crate’s health and maximum lifetime to zero and disables its effects, even if a player is nearby. Do not treat proximity as extra looting time.

Event completion has a separate check: while the crate exists, it requires a landed crate, the elapsed limit and no player within 1,100 metres. Proximity can keep the event occupying the single slot until that condition clears or the crate is deleted. A failed plane or deleted crate has another end path. Include crate condition and the previous event’s end time when measuring the next start.

For markers, use Navigation or a Bundle installation that includes it. Review generated ServerMarkerOnDropLocation and Server3DMarkerOnDropLocation settings, then inspect both marker visibility and the physical crate from a client. If the marker is missing, look for the crate before assuming the drop failed.

Find why a plane or subsequent event is missing

Section titled “Find why a plane or subsequent event is missing”
Observed problem Check first
Event file is ignored Active mission path, Airdrop_ prefix, JSON syntax and event Enabled.
Automatic event does not start Scheduler enablement, population gate, first delay and active-event limit.
Loot is configured but no plane appears An empty infected array still needs a matching preset. Check its classname and Usage 0/1.
Supply item produces no drop Expansion supply classname, loaded client/server module, preset Usage 0/2 and open test area.
Medical cargo is short Valid classnames, Min / Max, remaining weights and available cargo space.
Twenty minutes passes with the crate present Crate health, landing state and players inside the reviewed 1,100-metre cleanup radius.
Another event arrives late Previous event’s end time and population gate; inspect them before shortening delays.
Plane animation or marker differs Licensed / Navigation selection and fields from the installed release.
Scroll to see all columns →

Stop a failed test and restore the scheduler, shared preset and event files you changed. Save the failed logs. If the test altered saved state, restore compatible world data and profiles from the same backup. Deleting storage_1 or every profile discards unrelated state and does not repair a scheduling calculation. Follow mod removal when removing Missions itself.

Related documentation: 3 July release notes, custom-airdrop procedure, scheduler settings, shared airdrop settings.

DayZ hosting for your community.

Review DayZ plans with VxShield DDoS protection and no added player-slot fee.