Partisan: Everon is an original, persistent resistance campaign for Arma Reforger. Players build a resistance movement on Everon while an occupying force and an invading force pursue their own campaign objectives.
The project is in broad alpha. Its campaign foundation is substantial, but it is still under active development. Campaign Schema 71 and runtime-settings Schema 24 are the current persisted contracts.
Warning
Automated source, Workbench, focused engine, and scoped fresh-process checks do not yet close the broad Workshop-installed server, full-campaign restart, multiplayer, or soak gates. Until those gates pass, use disposable or backed-up profile data for alpha testing.
The Everon preset uses a three-way war:
- FIA: the player resistance
- US: the occupying force
- USSR: the invading force
The campaign is server-authoritative and combines persistent strategic state with physical AI near players and active objectives. Its current broad-alpha feature set includes:
- Setup-phase HQ selection, HQ relocation, Petros interactions, respawn, and campaign lifecycle controls
- Persistent campaign state, economy, resources, membership, arsenal, loadouts, garage vehicles, selected durable field-vehicle transforms and abstract cargo, mission state, locations, and ownership
- Town support, population, security, capture, garrisons, recruitment, training, income, rewards, and penalties
- A mission catalog covering resistance operations, rescues, assassinations, convoys, defenses, logistics, and strategic objectives
- Resistance support requests, purchased forces, patrols, enemy responses, and virtual-to-physical operation lifecycles for supported force types
- Abstract off-screen forces with render-bubble materialization, casualty reconciliation, survivor persistence, and map projection for supported force families
- Civilians, pedestrian danger behavior, civilian traffic, vehicle recovery, loot, build mode, radio sites, and strategic facilities
- An in-game command interface for setup, missions, forces, map/war information, arsenal, garage, members, and administration
- A one-button campaign diagnostic suite for controlled development testing
The implementation is not feature-complete, and several campaign systems still need broader runtime and multiplayer validation. See the feature checklist and parity tracker for the authoritative status.
- Arma Reforger
- The Partisan: Everon addon
- No hidden gameplay-addon dependency; the project depends on the Reforger base game only
Server and clients must use the same published addon version. A newer source checkout does not update an already published or cached Workshop revision.
- Install or subscribe to the current Partisan: Everon release.
- Enable the addon on the server and every connecting client.
- Select the Partisan: Everon campaign scenario.
- Start with a new or backed-up profile while the project remains in alpha.
- On first launch, review the generated settings before beginning a long campaign.
For a dedicated server, publish the current project from Workbench to Workshop,
install that Workshop revision through the normal game/server flow, and confirm
that the server and clients report the same embedded source identity.
Save/restart proof should use the exact published revision that produced the save. No generated
data.pak belongs in this source checkout or in a repository release workflow.
The repository provides two scenarios:
Missions/HST_Everon.conf: full-island campaign scenarioMissions/HST_Dev.conf: compact development and diagnostic scenario
Open the project in Arma Reforger Tools, compile the Game scripts, and run the
appropriate scenario. HST_* remains the internal source and resource naming
convention; the player-facing project name is Partisan: Everon.
Press I in either Partisan scenario to open the alpha command interface.
During initial setup, complete HQ placement on the map first; the setup map owns
input until placement is complete.
MenuUp/MenuDown: change selectionMenuSelect: activate the selected commandMenuBackorI: close the interface
Petros interactions open the same server-authoritative command path. Commands that require a target use the in-game map and may require the player to carry a map gadget. The server resolves the requesting player through network ownership and validates costs, permissions, and campaign state before applying a command.
$profile means the active Reforger or dedicated-server profile root. Partisan
stores generated data under $profile:Partisan:
| Purpose | Path |
|---|---|
| Runtime settings | $profile:Partisan/HST_Settings.json |
| Campaign recovery journal, canonical slot | $profile:Partisan/HST_CampaignSaveData.json |
| Campaign recovery journal, recovery slot | $profile:Partisan/HST_CampaignSaveData.recovery.json |
| Loadout editor preferences | $profile:Partisan/HST_LoadoutEditorSettings.json |
| Personal loadouts | $profile:Partisan/loadouts/v2 |
| Campaign Debug artifacts | $profile:Partisan/debug |
HST_Settings.json is generated on first load and contains JSON-safe _comment
fields explaining nearby options. Stop the server before editing it. The file
contains campaign, faction, economy, pacing, capture, world, civilian,
persistence, membership, and feature settings. Some values are defaults for new
campaign state and are not intended to rewrite facts already persisted in an
active campaign.
Notable feature switches include Game Master budget policy, infinite stamina, and resistance support-group map tracking. Prefer the generated comments over copying settings from an older schema by hand.
Campaign Schema 71 keeps a two-slot, crash-tolerant JSON recovery journal beside native persistence. When native persistence is active, the exact staged campaign snapshot advances the journal only after the native checkpoint completion callback reports success; the two copies are therefore coordinated, not written literally at the same instant. When native persistence is unavailable or the session has explicitly entered degraded profile-only recovery, the journal checkpoint is written synchronously.
Each journal generation stores the exact serialized snapshot payload, its
generation and parent identity, and an integrity fingerprint formatted as
uuidv8-sha256-v1:<serialized-length>:<UUID>. The writer changes only the
inactive slot, reads it back, and verifies the selected chain before the new
generation can supersede the prior known-good slot. This detects accidental
damage; it is not a cryptographic authentication or tamper-proofing mechanism.
The engine file API provides neither atomic rename nor an exclusive writer lock,
so only one server or Workbench process may write a profile at a time. Future
native authority is preserved and startup fails closed. Invalid journal data is
preserved during source selection, and a valid native save may still start; a
later verified native checkpoint may repair an ordinary invalid inactive slot.
Unsupported-future or ambiguous/conflicting history is write-fenced instead.
Without usable native authority, present invalid journal artifacts make startup
fail closed. Keep off-device backups for long-lived alpha campaigns because the
two slots share one profile and one storage device.
New native checkpoints use a version-2 native envelope that stores the exact serialized payload string and fingerprints those bytes before parsing them on load. Existing Schema-70 version-1 native rows are validated against their reconstructed legacy layout and normalized before source comparison. Native and journal snapshots are ordered by checkpoint sequence, then restore sequence, then save second; equal order requires equal normalized fingerprints. An administrative new-campaign reset retains the prior checkpoint/restore order, exact-clones its prospective campaign, and commits that DTO to the verified journal before old runtime cleanup or native staging. That JSON write-ahead generation remains recoverable if native replication subsequently fails.
Partisan uses $profile:Partisan as the only canonical generated-data root.
On first startup after upgrading, it automatically transfers the retired
profile tree, including nested and otherwise unrecognized files. Existing
canonical files take precedence, and conflicting older files are retained in a
legacy archive rather than overwritten. Campaign authority is stricter: a
difference between retired and canonical campaign files in either journal slot
is retained and startup fails until an operator resolves the conflict. The
retired directory is removed only after every file has been safely transferred
or archived; incomplete work is left in place for a later retry.
A valid raw Schema-70-or-earlier canonical campaign JSON is adopted as journal generation zero. Its bytes remain untouched while the first Schema-71 checkpoint writes recovery generation one linked to that legacy authority.
Before the first migration, stop every server, client, and Workbench instance that shares the profile, back up long-lived alpha data, and let one process complete startup before another uses that profile. See Migrations for schema-specific behavior, recovery details, and compatibility rules.
Add each administrator's raw 17-digit SteamID64 to
membership.adminIdentityIds in
$profile:Partisan/HST_Settings.json. Backend UUIDs, anti-cheat identifiers,
Workbench aliases, and per-session player IDs are not durable Partisan admin
identities.
After changing membership settings, restart the server and verify the runtime admin-grant log before relying on the Admin tab. Admin actions include campaign inspection, controlled state operations, checkpoint/reset helpers, focused diagnostics, and the full campaign diagnostic suite.
The Admin tab exposes Run Full Campaign Debug. The in-process suite is
restricted to HST_Dev, runs against a cloned campaign state, suspends normal
campaign checkpoints, and restores the live campaign state after completion or
cancel. Results are written under $profile:Partisan/debug as structured JSON,
summary text, and state-diff text.
The runner isolates bounded synthetic time from the shared campaign clock, holds ordinary enemy-commander cadence while explicit production-path fixtures own the clone, settles debug-created enemy orders through their typed operation owners, and validates exact operation-marker backing through the marker publisher. These protections reduce cross-case contamination; they do not turn an incomplete run into certification.
The one-button suite is a diagnostic harness, not automatic runtime certification. World entities, player state, service caches, published revision identity, and real process restarts sit outside the cloned campaign-state boundary. Use a separately managed disposable profile for restart, Workshop-installed server, multiplayer, and soak testing, and verify those behaviors in real installed runs.
Detailed evidence and outstanding gates live in the Campaign Debug verification audit.
Run the repository foundation gate before Workbench testing:
powershell -NoProfile -ExecutionPolicy Bypass -File tools/validate-foundation.ps1
git diff --checkThe validation ladder is intentionally cumulative:
- Foundation/static contract validation
- Workbench Game-script compilation and target-configuration validation
- Focused command-line engine autotests registered with the Game runtime
- Focused and Full Campaign Debug execution in
HST_Dev - Real profile save, process restart, reload, and reprojection
- Workshop-installed dedicated-server/client, multiplayer, reconnect, JIP, and soak proof
Separately registered focused engine autotests provide deterministic checks for
selected campaign-authority subsystems. They are distinct from the guarded
HST_Dev focused profile summarized below and do not prove that coordinator,
Full Campaign Debug, world integration, persistence, restart, Workshop-installed
server/client behavior, or network behavior. Exact test identities and run
evidence belong in the Campaign Debug verification audit rather than this
project overview.
The generated current status owns the active source checkpoint, exact validation counts, and proof-ladder decision. Do not copy an older checkpoint's compile or focused result forward after source changes.
Separate guarded evidence also covers selected journal recovery, controlled shutdown, mixed-native restoration, and exact garrison-rebuild cuts. See the Campaign Debug verification audit for exact identities, results, and remaining gates.
Do not promote a narrower validation rung to broader runtime proof. When testing a Workshop-installed revision, capture the published revision, embedded source identity, server/client logs, debug artifacts, and save/restart evidence together. Close Workbench instances after validation so stale processes do not retain resources or confuse later logs. Accept a guarded run only after its owned processes, disposable profiles, generated logs, guard roots, and temporary artifacts have all returned to zero.
- Feature Checklist: current feature status and next concrete work
- Phase Plan: dependency order, acceptance gates, and delivery roadmap
- Parity: implemented behavior and remaining campaign gaps
- Architecture: service boundaries and authoritative state model
- Migrations: campaign, settings, and profile migration contracts
- Campaign Debug Verification Audit: runtime evidence and open verification gates
- Enfusion/Enforce Notes: engine mechanics and implementation lessons
Partisan: Everon is licensed under the Arma Public License No Derivatives. See Third-party notices for required attribution.