9.8 KiB
Architecture
Dependencies
core -> ArmaReforger; ai -> core; intel -> core; map -> core; chat -> core, ai, intel, map. Every project declares the vanilla dependency explicitly. Addon GUIDs are listed in addons.json; metadata supplies new resource GUIDs. tools/check.py rejects external addon dependencies, duplicate resource identities, unresolved resources and legacy Escapists symbols.
Core owns ERR_GameMode, mission rules, native spawn lifecycle integration, settings, the location registry, the vanilla faction catalog and authored scenario construction. ERR_Phase transitions are checked centrally. ERR_LocationComponent registers stable location IDs and replicates discovery. Mission phase, discovery and persistent settings mutations are server-owned.
The mode exposes OnPhaseChanged, OnGroup, OnTick, OnStop and server-side OnLocationDiscovered events. ERR_CommandService is the response-coordinator interface. AI supplies its implementation through CreateCommandService. Core owns ERR_DiscoveryService, recovering physical documents and remembering consumed folder identities, and presents discovered objective markers. Intel subscribes to group and mission ticks only to distribute optional extra documents to enemies. Map supplies its shared field-map item through the scenario resource hook. Chat sends authenticated owner RPCs to mutate validated settings or read HQ status. Scenario placement and mission transitions are separate classes, but richer lifecycle and objective service interfaces remain migration work.
HQ information flow
Physical group members observe through vanilla AI perception. ERR_HQObservation requires fresh visual observations; ERR_HQReport snapshots the available information. The radio graph uses living, correctly affiliated actors actually carrying radios. Reports traverse bounded physical routes, with delay and inventory/affiliation checks at each hop. The delivered contact registry expires stale reports. Orders return through the radio graph before an existing eligible group receives a native search waypoint.
The coordinator is the sole source of strategic response orders. Individual units retain vanilla tactical combat. It does not spawn reinforcements when alerted. Initial physical forces are authored by the scenario. No distant-unit virtual simulation is implemented.
The current coordinator is a reduced implementation. Full contact scheduling, supporting aircraft and physical logistics remain incomplete. A finite physical mortar controller now compiles; its initialization, ammunition depletion and permanent asset loss pass local tests. Actual firing has not been validated. Aircraft availability helpers must not be mistaken for an operational controller.
Bounded work and ownership
HQ bounds group/contact registries and staggers report checks; routes have hop limits and timeouts. Intel has a bounded insertion queue. Core remembers physical folders already consumed, so handing a folder to another player cannot rediscover a location. The journal buffers and rotates output. Spawn retries are bounded and server-authored tickets constrain spawn resources and positions.
Stop events cancel service timers, remove HQ waypoints and despawn owned AI groups through the native group lifecycle. Composition walls have explicit hierarchy ownership. Two scripted round completions across restart are recorded, but full entity-count and memory soak tests are still required. The engine destroys the world during a scenario restart; merely clearing an owner array is not evidence of complete entity cleanup.
Round player lifecycle
ERR_PlayerRoster owns life records by backend identity; transient connection IDs are only lookup keys. Spawn, disconnect and rebind publish OnChanged. The native reconnect component retains the same physical character for voluntary as well as involuntary departures during its configured reservation interval. Reservation expiry does not restore a spent life. The defeat check includes reserved living characters. A server with no connected players pauses defeat and clears the radio defence timer.
First-time arrivals may spawn during prison, search or defence. Late spawn positions are checked beside conscious, on-foot survivors, with the authored prison as fallback. New arrivals during extraction observe until the next round. Dead players cannot request another life. Unconscious characters remain survivors and retain their own camera; they do not hold the radio objective.
The server selects a living friendly survivor for each spectator and replicates only its replication ID and fallback position. A local camera follows that survivor; owner RPCs allow /esc spectate next and /esc spectate previous. Only the selected survivor and occupied vehicle are pinned for streaming to that spectator. Loss, target changes and mission stop release pins. Reconnect, remote streaming and multi-client camera behavior still require multiplayer tests.
Base objective presentation
ERR_Objectives subscribes to phase and tick events and publishes one native SCR_Task per active phase, completing the previous task or failing it on defeat. Core mission rules alone advance phases. Native task replication carries current instructions to joining players; task markers remain list-only because the discovery registry owns map disclosure. Radio descriptions update on five-second boundaries and show interruptions. These APIs compile against installed vanilla scripts; actual task UI presentation and remote-client delivery still require gameplay validation.
Authored sites and finite scavenging
Core reads ERR_ScenarioDefinition from Configs/ERR/EveronSites.conf. ERR_SiteService owns the resulting locations, guards, containers and stock. The scenario component handles pending/ready/failed preparation separately from mission progression. Location IDs are supplied by configuration and replicated; templates carry no fixed scenario identity. Initial inventory items are created once, and retries move the same entities into the container. Readiness requires observed physical inventory contents. A completed service never refills stock or replaces destroyed sites.
ERR_DocumentComponent binds each mandatory physical clue to a radio location. Core recovery applies it only to that destination; optional generic enemy intel retains its broader discovery behavior. Definition validation requires a starting map and, for Everon, two separate guaranteed clue sources at least 100 metres apart. Each has enough documents to identify the radio independently. Optional supply/outpost locations use bounded five-second conscious-player visibility scans; progression sites remain document-controlled. Location names and discovery state replicate to the map, while actual knowledge transitions publish the server-side discovery event. Native tests mutate separate definition instances to verify invalid inputs are rejected. Authoring details and current stock.
Base configuration and administration
ERR_FactionCatalog is authored in Configs/ERR/VanillaFactions.conf and injected through the game mode resource. The scenario chooses guard groups from it; spawning, spawn authorization and spectator filtering use its player faction; HQ and support use its enemy faction. Startup rejects missing, identical or non-hostile faction keys, and site preparation rejects guard groups with mismatched affiliation. Shared intel and waypoint resources belong to ERR_Resources, not a faction selector. A new catalog alone does not provide new factions or suitable support compositions.
Core owns the /esc command registration, owner RPC, server-derived admin authorization, rate limit and command service. /esc status, settings and mission radio show|set N work without companion addons. Spectator cycling is available to players through its existing owner RPC. Chat extends the service with existing HQ/Intel aliases and HQ journal output; it does not install a second command transport. Native service fixtures test parsing and rejected mutations, not remote RPC identity enforcement.
Preparation failure is retained in replicated state. Spawning remains disabled, local guidance can explain failure before a character exists, and administrators can request the detailed cause. Waiting for site preparation does not consume a player's bounded spawn-attempt budget. The failure path stops services instead of silently leaving their timers running. Remote and visible pre-spawn presentation remain runtime acceptance work.
Extraction and personal results
ERR_ExtractionService owns the registered helicopter, capacity validation and immutable account-identity escape snapshot. It emits OnResolved to mission progression and never replaces its asset. A living registered participant must physically occupy that vehicle beyond the escape boundary during extraction; unconscious and reserved disconnected occupants remain eligible. Early helicopter loss is terminal even before radio completion. Late preparation failure rolls back all authored site content.
The native end-data connection ID list is retained only as a framework adapter. Core publishes an account-derived personal result on each player's controller, keyed to the current mission replication ID and reset at round startup/audit. Binding/rebinding republishes the result. The successor victory content ignores stale end-data winner IDs and refreshes if personal-result replication arrives after the end screen opens. Local widget tests and real network reconnect acceptance are distinct.
ERR_TimeService configures the native world clock once before the prison phase. Core administration saves start time and progression for the next round while showing the current applied values separately. The native manager advances and replicates time; there is no per-tick clock reset. See mission time and extraction.