How to install Bitterroot on a DayZ PC server

By Niko Catarino

Updated 3 October 2026

Bitterroot needs its original terrain package on your server and each joining client. Upload the author’s entire empty.Bitterroot mission into mpmissions, then select it in the configuration the service loads. Give the new terrain its own saved world and retain the previous one for recovery.

Begin with a vanilla installation you can join on a Steam PC server. This Workshop terrain is unavailable to Xbox and PlayStation servers.

Get the original map and its author mission

Install Mattty-Ice-’s original Bitterroot Workshop item 2906823750. Check its current required items. Treat GameLabs icon suggestions and asset credits as separate information when choosing dependencies.

Follow the Workshop mission link to Mattty-Ice/Bitterroot-DayZ. Extract empty.Bitterroot from the repository download; choose that mission rather than the other economy/editor material. Keep a copy of the download with a record of the terrain release you install.

We inspected mission revision 01f2c73. Its XML and JSON passed parsing checks. The item file still needs the duplicate-definition review below. Client joining, script compilation and compatibility with your DayZ build require a running-server test; those tests were not performed for this guide.

Preserve your previous world and load the package

Take a recoverable backup after stopping the service. Include its configuration, launch arguments, missions, saved world, profiles and packages. Write down -config and any -mission or -storage override. Prepare a separate Bitterroot instance with fresh storage for the first test.

Under VXPanel’s Mods, search 2906823750 and verify the original Steam item before installing it. Require the terrain’s client content and review mod scope and dependencies. Transfer the mission through Files or SFTP.

On a manual host, copy your subscribed terrain into its own mod folder. Put the package’s .bikey files in the server’s keys directory and retain signature verification and the supplied signatures. For a directory you have named @Bitterroot, the launch entry is:

"-mod=@Bitterroot"

Include Bitterroot in the existing client mod list and load matching content on the player client. Placing it under -serverMod cannot provide that client requirement. The manual mod procedure covers the remaining copying, key and loading checks.

Upload the whole mission and select its folder

Place the extracted mission folder under the server’s mpmissions directory. Inspect these parts of the upload:

mpmissions/
  empty.Bitterroot/
    init.c
    areaflags.map
    cfgeconomycore.xml
    cfggameplay.json
    cfgplayerspawnpoints.xml
    cfgenvironment.xml
    cfgeventspawns.xml
    cfgspawnabletypes.xml
    mapgrouppos.xml
    mapgroupproto.xml
    db/
    env/

Upload the complete folder. This abbreviated tree omits map clusters and other mission files that must travel with it. Remove the repository wrapper from the destination path: mpmissions/Bitterroot-DayZ-main/empty.Bitterroot nests the mission too deep.

Find the file selected by -config. Change template within that file’s existing mission class:

template = "empty.Bitterroot";

Match the author’s folder spelling and capitalization, and check whether -mission overrides your selection. The reviewed mission is empty.Bitterroot; an archived empty.Bitterrootfrost example does not name this folder.

For VXPanel, open Configuration → Config, press Refresh and wait for Synced. Edit Template, press Save and check success. Upload the files as a separate step: saving Template selects a mission but cannot download it. The configuration controls document this workflow.

Enable the author’s gameplay settings

For the author’s intended setup, its server configuration notes specify:

defaultVisibility = 3000;
defaultObjectViewDistance = 3000;
enableCfgGameplayFile = 1;

Set the loader flag to activate the supplied cfggameplay.json, as documented in Bohemia’s gameplay configuration loader. Measure the test workload when evaluating the author’s view-distance values; the values do not guarantee server performance.

Retain the Bitterroot gameplay file alongside its initializer. In the inspected revision, the monthly gameplay arrays specify temperatures from 7 to 17°C and disable personal light. The init.c date-reset logic moves dates outside its seasonal window toward 20 September. A stock Chernarus replacement can alter those settings.

Check the economy before starting

Bitterroot changes or removes vanilla items, according to the author README. Keep its loot definitions with the custom building groups, spawn positions and environment files. A Chernarus db/types.xml replacement can discard the map’s item choices. Use the economy extension workflow to register later mod additions once.

From the Windows server root, inspect your working mission copy with this read-only duplicate check:

$missionRoot = (Resolve-Path -LiteralPath '.\mpmissions\empty.Bitterroot' -ErrorAction Stop).Path
$typesPath = Join-Path $missionRoot 'db\types.xml'
[xml]$types = Get-Content -LiteralPath $typesPath -Raw -Encoding UTF8 -ErrorAction Stop
$duplicates = @($types.types.type | Group-Object -Property name | Where-Object Count -gt 1)
if ($duplicates.Count -gt 0) {
    throw ('Repeated type names: ' + (($duplicates | ForEach-Object Name) -join ', '))
}

At the pinned revision, DeadFox, NBCBootsWhite, NBCHoodWhite, NBCJacketWhite, NBCPantsWhite and ZmbM_VillagerOld_White each occur twice. The paired elements have identical content. Compare each pair in your test copy; where it still matches, keep one complete definition. A conflicting pair needs a decision about its intended settings before removal. Save the original download and your correction diff for future author updates.

Parse the edited XML and JSON, then repeat the duplicate check. After starting the test instance, inspect economy logs. Several log switches are enabled in the supplied mission, so check their output and disk consumption. Parsing verifies file structure; class availability and script compilation need further checks.

Check the map from a player client

Use matching Bitterroot content to join the test instance. Record whether:

• A fresh character spawns on valid ground with the author’s custom equipment.
• Natural loot appears in houses and custom buildings after the economy initializes.
• The map-specific items you inspect work and spawn in the intended loot locations.
• Configured populated areas contain the expected wildlife and infected.
• A saved character and placed container survive a normal saving shutdown and restart with their state intact.

Visit locations your players use. Mattty-Ice-’s Workshop author reply states that AI cannot work above a certain elevation, with animals and zombies omitted from those high areas by default. Account for that limitation when investigating an empty area. The reply supplies no universal altitude threshold and cannot diagnose the entire economy.

Creating an object through admin tools demonstrates class availability. Record separate outcomes for natural spawning, weapon behavior, saved-world recovery and player joins. Keep those results with your game, terrain and mission versions before moving the community.

Diagnose failures and restore the original server

Symptom	Check first
No world with name or the wrong terrain	Verify the Bitterroot -mod entry, uploaded mission and active config’s exact folder selection.
A player cannot join	Match the terrain release, required content and signing keys with the client; follow missing-PBO diagnostics.
Custom buildings have no loot	Read economy logs and compare the complete mission’s map groups before increasing targets.
A calendar or lighting edit has no effect	Inspect the loaded JSON, enableCfgGameplayFile and the init.c date reset.
Only high areas lack AI	Investigate territory configuration and the documented elevation limitation before changing global caps.
A map-specific weapon fails	Capture the classname and script/RPT error for comparison with current author release advice. Test weapon compatibility beyond XML parsing.

Scroll to see all columns →

Stop the test service before restoring the previous configuration, packages and their matching saved world. Retain Bitterroot in separate storage; merging its saved coordinates or entities into another terrain is not a supported rollback.

Source and verification scope

This guide used AI-assisted research and drafting. On 3 October 2026, we checked the author’s linked mission files and Workshop instructions, parsed the XML and JSON, and verified duplicate corrections on workspace copies. Map binaries were not installed and no game process was started. Live script compilation, player joins, natural spawning and saved-world recovery remain acceptance checks for your test instance.