How to set up DayZ Expansion vehicles, spawning and car keys

By Niko Catarino

Updated 5 October 2026

To add DayZ Expansion Vehicles on a Steam PC server, load its required packages, prepare the terrain economy and check a paired key. Keys and covers use vehicle settings. Natural helicopter spawns also depend on vehicle events and their terrain positions.

Use the original Workshop item and author mission templates for your installed release. Check player joins, natural spawns, movement and recovery on your test instance.

Install the original module and dependencies

Install the original DayZ-Expansion-Vehicles, Workshop ID 2291785437, with the dependencies declared on its listing:

Required package	Workshop ID
CF	1559212036
Dabs Framework	2545327648
DayZ-Expansion-Core	2291785308
DayZ-Expansion-Licensed	2116157322

Scroll to see all columns →

Stop and back up a test copy before installation. Expansion installation covers the first CF installation on a saved world, keys, matching client packages and mission selection. Bundle includes the vehicle module, so inspect your existing package choice before loading overlapping contents.

For VXPanel, find the packages by Workshop ID under Mods and check client scope in Installed mods. Follow Mods controls for installation and Files and SFTP for edits. Use the service’s managed mod bindings to load those packages.

A manual service with the folders shown can add this argument to its working launch command:

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

Keep the config, port, mission and profiles arguments that your service uses. Players need matching packages. Confirm that the selected items belong to the stable branch; Vehicles-Experimental uses another ID.

Connect vehicle classes, events and positions

Download the author mission templates and follow their README for the selected terrain. The revision reviewed here includes Template/Chernarus/. Templates under 0_INCOMPLETE require more preparation.

Select the economy classes your loaded modules provide. The suite template includes content from other modules and changes to vanilla events. Review those entries before copying them into the working mission, and retain its existing economy registrations and events.

File in the active mission	Vehicle job
cfgeconomycore.xml	Adds registrations for types, spawnabletypes and events.
expansion_ce/expansion_types.xml	Holds economy properties for each supplied vehicle class.
expansion_ce/expansion_spawnabletypes.xml	Assigns spawn attachments and cargo to vehicle classes.
expansion_ce/expansion_events.xml	Sets event activation, population targets and child vehicle classes.
cfgeventspawns.xml	Matches each event name to positions on the terrain.

Scroll to see all columns →

Apply the registration merge from Expansion installation. Put the chosen vehicle positions before the existing </eventposdef> closing tag while keeping other events. Parse the complete XML after the merge and measure usable positions on your own terrain.

Check the MH-6 event before raising loot counts

In the reviewed Chernarus files, VehicleMH6Helicopter is both the event name and its position-group name. The event uses ExpansionMh6 and variants as child classes. Match the event names across files without substituting the vehicle classname for them.

The template sets nominal and min to 0 for ExpansionMh6 in its types file. Its vehicle event supplies the natural-spawn population. A higher types nominal cannot supply missing event activation, children or positions.

Retain the author event baseline for the first natural-spawn check. Review its nominal, min, max, children and safety distances together, then check the saved population that could occupy that target. Observe a new CE vehicle as a separate result from an admin spawn.

Resolve duplicate attachment entries before deployment

The reviewed Chernarus expansion_spawnabletypes.xml contains two ExpansionMh6 type blocks with matching attachment contents. Consolidate them into one intended definition in the working merge and inspect other registered spawnabletypes files for the class. We have not tested the duplicate blocks’ in-game effect.

From the working mission directory, run this PowerShell check, which reads files without changing them:

$ErrorActionPreference = 'Stop'
$vehicleFiles = @(
  '.\cfgeconomycore.xml',
  '.\expansion_ce\expansion_types.xml',
  '.\expansion_ce\expansion_spawnabletypes.xml',
  '.\expansion_ce\expansion_events.xml',
  '.\cfgeventspawns.xml'
)
foreach ($vehicleFile in $vehicleFiles) {
  [xml](Get-Content -LiteralPath $vehicleFile -Raw) | Out-Null
}
[xml]$vehicleAttachments = Get-Content -LiteralPath '.\expansion_ce\expansion_spawnabletypes.xml' -Raw
$vehicleMh6Definitions = @($vehicleAttachments.SelectNodes('/spawnabletypes/type[@name="ExpansionMh6"]'))
if ($vehicleMh6Definitions.Count -ne 1) {
  throw "Expected one ExpansionMh6 attachment definition; found $($vehicleMh6Definitions.Count). Review the merge."
}

Parsing establishes XML syntax; the last condition checks one class for duplication. Inspect the mission’s other registered files too. The helicopter template gives components and doors partial spawn chances. Before starting a new natural vehicle, check its fitted parts, condition and fluids. Complete trucks explains how attachment rules differ from persisted vehicles.

Locate the vehicle settings for this service

Initialize the test service, stop it and find ExpansionMod/Settings/VehicleSettings.json beneath the profiles path used by that run. The inspected Core constants assign this file to profiles. The mission’s expansion/settings/ folder serves other settings.

The installed Vehicles package declares schema 23 and converts older settings. Keep the generated m_Version and remaining fields when applying a patch. The inspected file differs from the March public file even though both declare schema 23. Compare the files themselves; a matching schema number doesn’t mean the releases are identical.

Compare your generated file with the vehicle settings reference. Merge this test baseline for inventory keys, renewable master copies, a door requirement and blocked locked cargo:

{
  "VehicleRequireKeyToStart": 1,
  "VehicleRequireAllDoors": 1,
  "VehicleLockedAllowInventoryAccess": 0,
  "VehicleLockedAllowInventoryAccessWithoutDoors": 0,
  "MasterKeyPairingMode": 2,
  "MasterKeyUses": 2,
  "CanPickLock": 0,
  "CanChangeLock": 0
}

Installed scripts include VehicleLockedAllowInventoryAccessWithoutDoors, whose default is enabled. The cargo-access branch uses AllDoorsClosedEx(). For this baseline, 0 disables that door exception. Check the resulting permissions on the vehicle class you intend to offer.

Setting	Meaning in reviewed settings and author reference
VehicleRequireKeyToStart	Use 0 for no engine-key requirement, 1 for inventory/hands/vehicle cargo, or 2 for hands.
VehicleRequireAllDoors	Enable to require the vehicle’s doors for locking.
MasterKeyPairingMode	Choose -1 unlimited, 0 without master behavior, 1 limited, 2 repair-kit/grinder renewal, or 3 grinder renewal.
MasterKeyUses	Sets copy uses when the selected mode consumes them.
CanPickLock, CanChangeLock	Controls picking and lock replacement. Leave both disabled during the baseline check.

Scroll to see all columns →

Check engine access, pairing and cargo as separate actions. An engine-key setting does not create a pairing or grant a cargo permission. Retain existing damage, flight and towing settings until the key test passes.

Pair an ordinary key and test both identities

Hold an ordinary ExpansionCarKey, stand outside the unpaired vehicle and target it for the pairing action described in the author vehicle guide. The inspected action excludes admin keys and normal keys paired to a different vehicle.

1. Install and close the required doors, then hold the paired key to lock and unlock.
2. Try the engine with the key in the permitted location. Move the key outside the permitted locations and repeat.
3. Have a second player test lock, engine and cargo access without the paired key. Use an ordinary identity without admin privileges or an admin key.
4. Copy the master pairing onto a spare key through the recipe. Note remaining uses and try both keys on that vehicle.

With mode 2, the reviewed renewal recipes accept an electrical repair kit or a grinder once the paired master’s copy uses are exhausted. Copying requires a paired master with remaining uses and consumes one use in this mode. Verify the recipe and consumed resources on your installed release before offering replacement keys to players.

Record the key and vehicle classes alongside observations in the vehicle acceptance record. Pairing follows persistent IDs; spawning another key of that class does not recreate the saved pairing.

Keep covers out of the first recovery test

For the first restart test, merge this cover policy into VehicleSettings.json:

{
  "EnableVehicleCovers": 0,
  "AllowCoveringDEVehicles": 0,
  "EnableAutoCoveringDEVehicles": 0,
  "VehicleAutoCoverTimeSeconds": 0
}

Note the vehicle’s location, cargo and paired keys, then stop and start the service through its normal workflow. Check that saved vehicle and both keys. The installed CF paths save key IDs and vehicle lock state as well as key pairing data. Preserve compatible world, player, profiles and mod storage in the recovery set described by backup and restore.

Test covers after the ordinary restart passes. A cover swaps the vehicle for a storage placeholder. UseVirtualStorageForCoverCargo controls cargo storage, which must be included in recovery. Check CanCoverWithCargo and the vehicle’s cover action before using cargo in that test.

Before covering economy vehicles, read the author’s respawn precaution for AllowCoveringDEVehicles and EnableAutoCoveringDEVehicles. The installed auto-cover path checks the engine and nearby players as well as its timer. Observe population, cargo, key access and uncovering across a further restart.

The latest visible stable change notes name 1.9.72 and retain winching and uncovering issues. Test uncovering with players clear of the vehicle because restoring while standing on it can cause a fall-through. Helicopter winching has no verified recovery result here.

Diagnose the first failed check

Symptom	Check before another edit
Expansion vehicles not spawning	Check the loaded class and CE file registrations, then event activation, children, terrain positions and saved population.
MH-6 appears without required components	Compare the variant’s attachment chances, duplicate records and saved state.
Car keys not working	Identify the key type and pairing, then inspect its engine-policy location, required doors and master uses.
Locked cargo remains accessible	Review both inventory permissions, doors and vehicle class, including other inventory mods.
Vehicle or key changes after restart	Inspect saves and CF compatibility, the stop workflow, lifetime and any cover/garage operation in the current logs.
Trader vehicle purchase fails	Check Market zone and spawn positions, physical clearance, the supplied class and the transaction result.

Scroll to see all columns →

Retain the failed action and that run’s logs before changing another setting. Expansion Market covers trader delivery; check that transaction even if natural spawning passes.

Retain failed logs, stop the instance and restore its changed files with compatible stopped saves. Use mod removal when withdrawing packages that provide persisted classes. Correct a mistyped event without wiping the live world.

Record the natural-spawn, key-access and restart results before continuing through the DayZ guide directory.

Rehearse the MuchCarKey system in a separate world after reviewing its vehicle-migration warning. Verify the selected ownership workflow against the installed Expansion releases; the original MuchCarKey listing leaves that combination unproven.