Skip to content

Architecture Overview

rayswaynl edited this page Jun 5, 2026 · 16 revisions

Architecture Overview

For upstream development patterns and negative knowledge from Miksuu PRs, reverts and branch history, start with Developer history and upstream lessons. It helps distinguish current architecture from old experiments and abandoned merge attempts.

The repository is an Arma 2 OA Warfare/CTI mission derived from Benny's Warfare and actively modernized for the Miksuu/WASP server. The core runtime is SQF in a mission folder, surrounded by C# helper tools, a Discord status bot, and a Windows extension bridge.

Runtime Partitions

  • Common: shared constants, config, utility functions, public-variable registration, faction/core data, artillery and shared modules.
  • Server: authoritative game state, economy, towns, AI spawning, victory checks, PVF request handling, cleanup, callExtension integration, anti-stack/database hooks.
  • Client: UI, menus, player actions, local HUD/marker loops, skill modules, supply mission start flow, map interactions, PVF client handlers.
  • Headless: detection and initialization for headless clients. The mission disables headless delegation when the OA build is too old.
  • WASP: older/custom gameplay layer with MHQ repair, RPG dropping, base repair and marker monitor scripts. Some of it is still present but one old init block is commented out.

Partition caveat: Common/Init/Init_Common.sqf is mostly shared, but it also contains server-only compile/setup branches guarded by isServer around :301-307. Do not treat Common as purely client-safe shared code when moving compile registrations; confirm the branch owner first.

Source Mission Versus Generated Missions

Missions/[55-2hc]warfarev2_073v48co.chernarus is the authoritative mission folder. The Takistan vanilla folder and modded mission folders are copy/generation outputs. The repo instructions say mission edits should be made in Chernarus, then copied with Tools/LoadoutManager via dotnet run.

Initialization Model

initJIPCompatible.sqf is the main bootstrap. It:

  • logs map, mission name, start distance, player count and log-content state;
  • detects hosted server, dedicated server, normal client and headless client;
  • reads mission parameters and common constants;
  • starts Common/Init/Init_Common.sqf and Common/Init/Init_Towns.sqf;
  • starts Server/Init/Init_Server.sqf on server/host;
  • starts Client/Init/Init_Client.sqf on clients after side logic is ready;
  • starts Headless/Init/Init_HC.sqf on headless clients.

Boot fragility callouts:

  • Headless init currently uses Headless/Init/Init_HC.sqf:12 sleep 20 and announces connected-hc at :15; it does not wait on serverInitFull from Server/Init/Init_Server.sqf:507. Treat this as a timing proxy, not a dependency barrier.
  • Client/JIP startup waits for replicated globals such as townInit, wfbe_structures, wfbe_commander, wfbe_radio_hq, wfbe_startpos, wfbe_hq_deployed and wfbe_votetime without timeout/retry fallbacks. The canonical wait graph lives in Lifecycle wait-chain.
  • Server init still has duplicate/legacy compile registrations in the early compile block. Keep init hygiene notes in Mission entrypoints and SQF code atlas close to any compile refactor.

Data Flow At A Glance

  1. description.ext includes version, sounds, music, resource/dialog/title definitions and mission parameters.
  2. initJIPCompatible.sqf initializes globals, common constants and runtime partition entrypoints.
  3. Init_Common.sqf compiles shared functions, loads faction/core/gear/defense/group config, and registers PVF handlers.
  4. Init_Server.sqf creates side logic state, server functions, AI/town loops, cleanup loops, anti-stack, server FPS publishing and day/night authority.
  5. Init_Client.sqf compiles local functions, wires player event handlers, UI actions, hotkeys, skill/action modules, client marker loops and HUD behavior.

Representative Source Anchors

Claim Source anchors
Mission front door and include graph description.ext:37-69 defines version/debug switches and includes sounds, music, resource/dialog/title/parameter headers.
Runtime role detection and shared constants initJIPCompatible.sqf:132-134 loads MP parameters and common constants; :185-193 gates headless-client support by OA build.
Common compile/config layer Common/Init/Init_Common.sqf:19-63 compiles economy/town/helper functions; :147-149 selects the OA/vanilla server-send wrapper.
Server-owned loops Server/Init/Init_Server.sqf:509-531 launches town, town-AI, victory and resource loops; :577-595 starts FPS publishers and performance helpers.
Client-owned UI/action layer Client/Init/Init_Client.sqf:49-65 compiles local UI/player helpers; :492-503 initializes CoIn and JIP HQ killed handling.
Headless entry point Headless/Init/Init_HC.sqf:4-15 compiles delegation handlers and announces the HC to the server through RequestSpecial.

Development Philosophy

This mission values runtime performance and live-server stability. Many systems have explicit audit logging, cached UI writes, deferred loops, and optional switches. Documentation and feature work should preserve those patterns instead of reintroducing large per-frame scans or unconditional global broadcasts.

Continue Reading

Previous: Quickstart | Next: Mission entrypoints and lifecycle

Main map: Home | Source map: Source inventory | Runtime: Lifecycle wait-chain

Sidebar

Clone this wiki locally