Install and configure Basic Territories on a DayZ server

By VYKIX

Updated 7 October 2026

Basic Territories adds ownership and membership to vanilla territory flags. Install CF and Basic Territories on the server and joining clients, then review the generated public permissions before letting players claim bases. In the source checked here, the defaults allow outsiders to build and lower a flag.

This guide covers DaemonForge’s original Basic Territories, Workshop item 2398911445. Its latest Workshop change is 30 June 2021. The author’s public repository at 324b6a59 was checked on 7 October 2026. The repository warns that its developing source may differ from the published mod; it has not been matched to a current Workshop binary.

Review enforcement before public use

The checked territory implementation returns immediately from its position-permission helper on a dedicated server. Its build, dismantle and placement actions also take a separate server path before the client territory checks.

That source behavior means a hidden or disabled action in a normal client is insufficient evidence that the server enforces the same restriction. Before relying on this mod to protect a public server’s bases, verify the installed release’s server-side permission handling. No current-build enforcement test has been performed here. Use the steps below to prepare and evaluate an isolated setup while that requirement remains open.

Install and generate settings

Stop the server and back up its mission, profiles, world saves and launch settings. Keep flags and their saved ownership data together in the recovery copy. If CF is new to the world, read CF’s first-installation wipe requirement before proceeding.

In VXPanel Mods, install CF (1559212036) and Basic Territories (2398911445) with client-visible loading. Put CF first. Manual hosts should follow the package and signing-key procedure, retaining the supplied package contents and signature verification. Basic Map and Notifications are optional integrations described by the author; neither replaces CF.

Start the isolated instance, inspect the log, then stop. The configuration loader uses these files beneath the active profiles directory:

BasicTerritories/
  settings.json
  RaidHandlers.json

The second file is conditional: this source loads or creates raid handlers when native base damage is enabled. Its absence with base damage disabled isn’t, by itself, an installation failure.

Back up the generated settings.json, edit it while stopped, validate the JSON and restart. Preserve the generated ConfigVersion and value types. The repository’s older JSON schema includes version "1", while this loader uses "2"; don’t replace the generated configuration with that older example.

Choose public and member permissions

PublicPermissions applies to players outside a territory’s membership. MemberPermissions supplies the value assigned when adding a member. These numbers combine individual permissions; they are not simple on/off switches.

The author’s permission constants define the relevant values:

• 2: deploy an item.
• 4: build a construction part.
• 8: dismantle.
• 16: lower the flag.
• 32: add a member.
• 64: remove members.
• 256: the CarCover removal permission used by an integration.

The defaults are public 20 (4 + 16) and member 30 (2 + 4 + 8 + 16). For a rehearsal where outsiders receive none of those permissions and members can deploy, build and dismantle, merge these two fields into the generated settings:

{
  "PublicPermissions": 0,
  "MemberPermissions": 14
}

Keep the other fields. This example excludes flag lowering and membership management from the member value. Choose those actions separately if your rules require them. In the membership implementation, a stored member value of 1 grants all checked permissions. Don’t use 1 to mean “membership enabled.”

Changing MemberPermissions doesn’t rewrite every existing member: the value is copied when a new member is added and stored with the flag. Compare a newly accepted member with one already in the territory after any policy change. Plan revocation or re-enrollment before changing a live community’s access.

Owners and configured server administrators have separate access. ServerAdmins expects the DayZ GUID used by this mod, rather than an unexamined Steam64 ID. Check the identity format in the author’s settings schema, and use ordinary accounts for the permission tests.

Claim a flag and add a member

On the test instance, construct a flagpole, attach a flag and raise it. Use Claim on an unowned flag, then check ownership with a second player. The author also describes claiming existing flags, which still needs a recovery rehearsal on a copied world.

For membership, the checked actions use this sequence:

1. The owner chooses Add Member on the raised flag.
2. The intended player approaches the flag and chooses Accept Membership.
3. Test that member’s allowed and denied actions, then repeat with an outsider.

The source leaves the flag accepting a member for up to five minutes, ending the window after acceptance or cancellation. Add one person at a time and check who joined. It does not select a named recipient when the owner opens that window.

A non-owner member can use Leave Territory. Clear All Members removes the membership list, so use it only when you intend to remove everyone and have planned who must rejoin. Reset Owner is a different action; don’t use it as a routine settings refresh. The membership actions distinguish these operations.

Set building areas and maintain flags

Review these controls in settings.json against your map and community rules:

• RequireTerritory: requires a territory for ordinary placement when enabled. The checked placement code has exceptions for territory kits and allowed item names.
• WhiteList: bypasses placement restrictions for matching item names. Matching uses case-insensitive substrings, so a short entry can cover more classes than you intended.
• NoBuildZones: defines circular areas using X, Z and radius R. Replace the generated sample locations with measured positions for your map, or remove sample entries if you want no such zones. DrawOnMap depends on the optional map integration.
• Notifications: 0 uses chat; 1 selects the separate Notifications integration. Install that integration before expecting its messages.

Keep a flag raised and test what happens as it lowers. In the checked permission method, a flag outside the raised state allows actions that would otherwise depend on membership. A claimed pole alone is not permanent protection. The June 2021 changelog also aligns territory radius with the refresh radius; don’t guess an extra TerritoryRadius JSON field.

FlagRefreshFrequency and KitLifeTimes help the mod produce expiry warnings. Changing those warning values doesn’t replace the mission’s actual economy lifetimes. Keep the warning settings consistent with the mission and verify the objects you want to retain.

The tent implementation refreshes nearby lifetimes when a tent is opened or closed, using TentRadius. A negative radius disables that refresh path. Tents don’t acquire territory membership through this feature.

Test access, damage and recovery separately

Use an owner, a member and an outsider without administrator privileges. Record the installed game/mod versions and the flag state alongside each result:

1. Try placement, building, dismantling and flag lowering inside the territory, at its boundary and outside it.
2. Check member acceptance, leaving and deliberate removal. Repeat the denied actions after reconnecting and restarting.
3. Test your actual building and storage mods. Their own actions may need an integration; a vanilla fence result doesn’t establish BaseBuildingPlus or CarCover behavior.
4. Check weapon or explosive damage separately from dismantling permission. Choose native base-damage and raid-handler rules deliberately; territory membership alone doesn’t define the raid policy.
5. Restore the stopped backup on the separate instance and verify flag ownership, membership, structures and stored items.

Keep the logs and failed action before trying another setting. Review the installed release’s server-side enforcement as required above, even if all normal-client checks pass.

Source and verification scope

The original Workshop description, all nine change entries and fifteen complete files from the pinned author repository were read on 7 October 2026. Those files cover setup, settings/schema, membership, flags, placement/build/dismantle actions and tent refresh. Other similarly named Workshop forks use their own configuration and migration instructions; this guide does not substitute a fork for the original. Current binary matching, compatibility, permission enforcement and saved-world recovery remain unverified.