50 lines
8.0 KiB
Markdown
50 lines
8.0 KiB
Markdown
# 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` and `OnStop` 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 an accessible, guaranteed clue route and a starting map. Native tests mutate separate definition instances to verify invalid inputs are rejected. [Authoring details and current stock](site-authoring.md).
|
|
|
|
## 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.
|