How to configure DayZ Expansion BaseBuilding and territories

By Niko Catarino

Updated 5 October 2026

Configure Expansion BaseBuilding on a DayZ Steam PC server around a test flag and two player identities. Check their deployment permissions and saved-world recovery before introducing raid rules or another construction package.

These steps draw on the original Workshop item, author wiki and March public code. We have not tested the current BaseBuilding package in a multiplayer session. Before opening territories to public players, review the membership-permission risk described below against your installed release.

Prepare the mission through Expansion installation. For native placement settings, follow vanilla build anywhere. Other building packages have separate guides: BaseBuildingPlus and RaG BaseBuilding. Check each package’s settings and permissions before combining them.

Install the original packages with client scope

Select the original DayZ-Expansion-BaseBuilding, Workshop ID 2792982513. The item declares these dependencies:

Package required by the listing	Workshop ID
CF	1559212036
Dabs Framework	2545327648
DayZ-Expansion-Core	2291785308
DayZ-Expansion-Licensed	2116157322

Scroll to see all columns →

Treat Licensed as required by the listing. Its older “if combined” feature description does not override the dependency panel.

On the stopped VXPanel test service, search the IDs in Mods and inspect Installed mods with client scope. Follow the Mods reference for those controls and Expansion installation for keys, framework preparation and the CF saved-world precaution.

If your manual service uses these folder names, include this quoted argument in its existing launch command:

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

Choose individual modules or Bundle, which includes BaseBuilding. Loading both overlaps their contents. After the first territory passes, consider Book for its territory interface, Groups for group-only invitations, or Spawn Selection for territory respawns.

Locate settings and preserve the world

Preserve the test mission, profiles and persistence while the service is stopped, using backup and restore. Initialize the selected packages, retain that run’s log and stop before JSON edits. Locate the active directories from the mission template and -profiles argument.

Use the inspected path constants to distinguish the files:

Generated file	Location in reviewed source	Schema version
BaseBuildingSettings.json	expansion/settings/ in the active mission	5
TerritorySettings.json	ExpansionMod/Settings/ beneath profiles	6
RaidSettings.json	ExpansionMod/Settings/ beneath profiles	5

Scroll to see all columns →

An old profiles copy of BaseBuilding settings is moved to the mission by its reviewed loader. Retain the generated m_Version and compare conversion output with your stopped backup. Do not raise that version number to skip conversion. Check whether your installed release supports the saved settings.

In the reviewed flag implementation, CF mod storage saves the territory’s ownership, invitations and members with its flag. Include compatible world and player data in the recovery set; JSON preserves the policy without preserving those objects.

Create one test territory before tightening deployment

Apply this baseline to the generated mission-side BaseBuildingSettings.json while retaining fields outside the patch:

{
  "CanCraftVanillaBasebuilding": 1,
  "CanCraftExpansionBasebuilding": 1,
  "CanCraftTerritoryFlagKit": 1,
  "AllowBuildingWithoutATerritory": 1,
  "CanBuildAnywhere": 0,
  "SimpleTerritory": 0,
  "AutomaticFlagOnCreation": 0,
  "FlagMenuMode": 1,
  "DismantleInsideTerritory": 0,
  "DismantleOutsideTerritory": 0,
  "DismantleAnywhere": 0,
  "DismantleFlagMode": -1,
  "EnableVirtualStorage": 0
}

Then merge this policy into TerritorySettings.json beneath profiles:

{
  "EnableTerritories": 1,
  "UseWholeMapForInviteList": 0,
  "TerritorySize": 100.0,
  "TerritoryPerimeterSize": 100.0,
  "MaxMembersInTerritory": 6,
  "MaxTerritoryPerPlayer": 1,
  "TerritoryInviteAcceptRadius": 100.0,
  "InviteCooldown": 0,
  "OnlyInviteGroupMember": 0,
  "AuthenticateCodeLockIfTerritoryMember": 0
}

The example is a small test policy with no server-capacity claim. In metres, TerritorySize specifies radius. The inspected perimeter helper combines that radius with TerritoryPerimeterSize and a five-metre allowance for the surrounding exclusion. Observe its boundary; a second territory diameter is a different measurement.

Use three sticks and one rope for the author’s flag-kit recipe. Pick open ground beyond safe zones and other owners’ perimeters. Deploy the kit, construct the pole and attach its flag under this manual-construction baseline. Create the territory through the flag interaction and inspect its recorded name and owner.

If you invite through Book, inspect its generated BookSettings.json territory tab and client interface. Groups and Book setup documents that menu package and input configuration. Diagnose a hidden tab apart from a missing flag action.

Use TerritoryPerimeterSize and TerritoryInviteAcceptRadius when those are the installed release’s generated fields. The older wiki instead contains TerritoryPerimterSize and TerritoryAuthenticationRadius. The latter is read during the inspected version-two conversion, while the version-six schema declares the current names.

Check invitations, membership limits and access

Have the second identity stand near the flag, receive the invitation and accept inside TerritoryInviteAcceptRadius. A whole-map list selected through UseWholeMapForInviteList expands discovery of players; the reviewed acceptance path retains its distance requirement.

The inspected territory module applies MaxTerritoryPerPlayer to joined memberships as well as creation. With one allowed territory, joining another owner’s claim can be blocked. Invitation sending checks MaxMembersInTerritory; assess several outstanding invitations against the installed release before relying on that cap.

Begin with the example’s zero cooldown. For a later interval, test leaving and reinvitation: the inspected player and territory timers measure seconds since departure, rather than invitation expiry. Introduce OnlyInviteGroupMember after Groups and the player’s party membership have passed their checks.

Check invitation permissions before public use. The inspected March acceptance method validates a flag, territory, player, membership-count limit and radius before removing an invitation and adding a member. It shows no explicit pending-invitation check. Surrounding authorization and the current distribution remain unverified. Review your installed release and confirm that it rejects an uninvited player in a controlled test before public use. A successful invited join doesn’t check that boundary.

Observe locks, placement and dismantling with ordinary player permissions. An administrator tool’s bypass can hide the restriction that a member or outsider needs to satisfy.

Require territories without blocking the first flag

Once creation and invitations pass, constrain deployment outside territories. This fresh-test patch keeps flag kits available there while requiring membership for the other controlled deployments:

{
  "AllowBuildingWithoutATerritory": 0,
  "DeployableOutsideATerritory": ["TerritoryFlagKit"]
}

Preserve the server’s existing allowlist choices when merging this policy. The flag exception lets a newcomer deploy the kit needed to establish a territory. The inspected deployment branch continues checking another owner’s perimeter for that exception, so assess the neighboring claim before placement.

Review hostile-territory exceptions in DeployableInsideAEnemyTerritory as part of raid policy. That list grants specific deployments there. Changing CanBuildAnywhere relaxes native placement limits while the reviewed deployment path still applies safe-zone, territory and configured-zone conditions.

Place a flag kit and wall kit within the member’s territory, outside it and beside another owner’s perimeter. For a rejection, compare the preview, server response and player position before changing a setting.

Configure Expansion locks as their own test

Test six-digit codes on Expansion locks attached to Expansion constructions with this patch; wrong-code injury stays disabled:

{
  "CodeLockLength": 6,
  "CodelockAttachMode": 0,
  "RememberCode": 1,
  "DoDamageWhenEnterWrongCodeLock": 0
}

Read the generated field against the inspected attachment enum. Its modes are 0 Expansion constructions, 1 Expansion plus fences, 2 Expansion plus fences and tents, and 3 Expansion plus tents. Legacy CanAttachCodelock values are converted under a different mapping; compare that conversion before broadening attachment scope.

The inspected lock handlers reject an empty code or one longer than CodeLockLength. Don’t assume this field requires exactly six digits. Check shorter codes and the installed release’s input handling in the test.

Give the new test door a disposable code. Observe the owner, another member and a nonmember entering a wrong code. With AuthenticateCodeLockIfTerritoryMember disabled, check each player’s code access rather than assuming that territory membership grants it. Check remembered access after reconnect and a normal restart.

Use the standalone Code Lock guide for that separate mod. For an Expansion lock integration, inspect the author-listed bridge and target construction, then restrict the test to classes supplied by your installed packages.

Add a measured no-build zone

Stop the service and add one complete Zones record in the mission file with ZonesAreNoBuildZones set to 1. Measure a terrain-specific Center using three numeric [X,Y,Z] values. The label patch below omits that required coordinate field and must be merged into the complete record:

{
  "Name": "Community protected area",
  "Radius": 25.0,
  "Items": [],
  "IsWhitelist": 1,
  "CustomMessage": "Building is disabled in this area."
}

The inspected zone branch allows an Items match when IsWhitelist is one, so this empty whitelist denies the checked deployments. Zero instead denies listed matches. State the selected rule in your server policy before exposing the area to players.

Zone lookup in the inspected code selects the first matching record by three-dimensional distance from the player’s position. Keep the first experiment free of overlaps and test both player and preview across its edge. With ZonesAreNoBuildZones off, the outside-zone policy becomes build-zone enforcement. Confirm server acceptance as well as preview color.

Verify damage, persistence and rollback

Define damage policy across profiles’ RaidSettings.json, native settings and installed damage mods. Check raid protection separately from territory membership: test walls, safes, locks and dismantling. For an explosion allowlist, inspect the installed-release reference’s explosion classname; the weapon or inventory explosive classname serves another purpose.

Retain these player observations beside the game build, terrain, package versions, active paths and field changes:

Acceptance check	Observation to keep
Installation	The matching client joins with the required classes recognized.
Flag	Observe creation, pole/flag actions and the assigned owner.
Member and outsider	Observe invitations, distance/cap rules and rejection of unauthorized membership.
Deployment	Compare territory, perimeter and no-build-zone results with the policy.
Door and dismantling	Check ordinary member/nonmember permissions for code access and dismantling.
Damage	Observe the intended damage on a disposable structure for each enabled raid method.
Restart	Inspect the same saved flag, members, structures and lock state.
Recovery	Repeat those observations after restoring a compatible stopped backup.

Scroll to see all columns →

After membership and its access boundary pass, introduce territory respawns. Observe a member and nonmember, destination clearance and the selected interval.

Stop on a failed edit and recover the affected settings. Changes to memberships or saved structures require compatible mission storage and profiles from the same stopped backup. Retain diagnostic logs while keeping the live world’s objects intact.

After updates, inspect generated files beside the author’s BaseBuilding, Territory and Raid references. Continue through the DayZ guide directory.