Skip to content

Mission Entrypoints And Lifecycle

rayswaynl edited this page Jun 14, 2026 · 18 revisions

Mission Entrypoints And Lifecycle

For the machine-role truth table, per-role boot timelines, and global flag -> waitUntil dependency graph, read Lifecycle wait-chain reference before reordering any init call.

Source Scope

Unless a row names another ref, line refs on this page are from docs checkout docs/developer-wiki-index 9da5f1d0 and the Chernarus source mission root Missions/[55-2hc]warfarev2_073v48co.chernarus/. Rechecked 2026-06-14: description.ext, initJIPCompatible.sqf, mission.sqm, Common/Init/Init_Town*.sqf, Common/Init/Init_Common.sqf, Server/Init/Init_Server.sqf, Client/Init/Init_Client.sqf and Headless/Init/Init_HC.sqf support the entrypoint claims below.

Branch spot-check 2026-06-14: stable origin/master cf2a6d6a, release a96fdda2, Miksuu b8389e74 and origin/perf/quick-wins 0076040f keep the same front-door topology from initJIPCompatible.sqf (Common/Towns, then Server, Client and Headless branches), but line refs drift. For branch behavior claims, route through Current source status snapshot and the narrower owner pages before citing branch-specific lines.

description.ext

The mission metadata and UI resource graph is assembled from:

  • version.sqf
  • Sounds/description.ext
  • Music/description.ext
  • Rsc/Header.hpp
  • Rsc/Styles.hpp
  • Rsc/Parameters.hpp
  • Rsc/Ressources.hpp
  • Rsc/Dialogs.hpp
  • Rsc/Titles.hpp
  • Rsc/Identities.hpp when not VANILLA

It also sets loadScreen, disables spoken sentences, disables channels 3 and 6, and leaves disabledAI=0.

version.sqf is included here and again by initJIPCompatible.sqf. The 2026-06-14 checkout has no tracked version.sqf rows and no generated version.sqf files present in the checked Chernarus or Vanilla Takistan roots; .gitignore:1,23 still ignores those paths when generated. Treat it as required generated terrain metadata, not as optional decoration or durable checked-in source.

Source verification: description.ext:39 includes version.sqf; :41-58 include sound, music and Rsc bundles; :64-67 set loadScreen, disableChannels[] and disabledAI. The clean-checkout/release warning still stands: run/generate/check target roots before boot, pack or test claims.

Confirmed finding cross-link: Deep-review findings DR-43a tracks the version.sqf source/build ownership gap.

initJIPCompatible.sqf

This is the first major runtime script. It creates early logging, determines server/client/headless roles, runs version detection, initializes common constants and parameters, applies environment time, then dispatches common/server/client/headless init scripts.

Source anchors: role detection at initJIPCompatible.sqf:52-56, version wait at :49, parameter readiness at :212, Common/Towns startup at :214-215, server branch at :218-220, client branch at :224-233 and headless branch at :237-238.

Boot Ordering Handoff

This page only summarizes entrypoints. The canonical boot timeline, role truth table and flag dependency graph live in Lifecycle wait-chain.

Do not duplicate the flag matrix here. For producer/consumer lines, use Lifecycle wait-chain for VERSION_SET, WFBE_Parameters_Ready, townModeSet, commonInitComplete, townInit, serverInitComplete, serverInitFull and clientInitComplete. Keep this page focused on which file starts which role-owned layer.

Common/Init/Init_Parameters.sqf:5-10 copies each description.ext Params class name into missionNamespace, so parameter names are live runtime globals. initJIPCompatible.sqf:142-162 can then override several of those values for air-war/debug modes before later init code consumes them. The most easily misread gates are WFBE_DAYNIGHT_ENABLED, WFBE_C_AI_DELEGATION, economy/supply mode constants, WFBE_C_BASE_START_TOWN, module toggles such as EASA/ICBM/IRS/CM, and map-icon blinking.

Headless mode is especially stateful: WFBE_C_AI_DELEGATION == 2 means HC mode in configuration, but initJIPCompatible.sqf:168-170 downgrades it to 0 when the detected OA build does not support HC. That downgrade happens during boot, so bug reports can show a different runtime value than the lobby parameter suggested.

WASP should not be described as a live parallel bootstrap branch. The old WASP block in initJIPCompatible.sqf is commented out; current WASP behavior is wired per feature from client/server init and from the specific WASP scripts documented in WASP overlay.

Mission Object Init Layer

mission.sqm is part of the lifecycle, not just terrain metadata. Town logic objects run Common\Init\Init_Town.sqf from their init fields, and the WF_Logic object sets town-mode removal lists before running Common\Init\Init_TownMode.sqf.

Verified anchors:

Source Runtime role
mission.sqm:128 and following town logic entries Town objects call Common\Init\Init_Town.sqf with name, dubbing name, start SV, max SV, range and group templates. Current source scan found 40 such explicit Init_Town.sqf calls.
mission.sqm:3265 WF_Logic sets totalTowns = 43, disables simulation and seeds Towns_Removed* lists before ExecVM "Common\Init\Init_TownMode.sqf".
Common/Init/Init_Town.sqf:18 Each town waits for townModeSet && WFBE_Parameters_Ready before applying town state.
Common/Init/Init_Town.sqf:42 Town object setup then waits for commonInitComplete.
Common/Init/Init_Town.sqf:92 Server-side town model/camp setup waits for serverInitComplete.
Common/Init/Init_Town.sqf:134 AI/patrol follow-up waits for townInitServer.

This means town lifecycle bugs can live in mission object init, town init scripts and server FSMs together. Regex-only scans of SQF files will miss the mission.sqm entry layer.

Count verification note: a 2026-06-04 lifecycle scout suggested the count might be 42, but a direct source recheck with Select-String -LiteralPath "Missions\[55-2hc]warfarev2_073v48co.chernarus\mission.sqm" -Pattern "Common\\Init\\Init_Town\.sqf" returned 40. Keep this count source-verified before using it in balance or capture-mode assumptions.

Common Init

Common/Init/Init_Common.sqf compiles most shared helpers and config. The central idea is that config arrays and helper functions are available to both server and clients before side-specific runtime code starts using them. For the exact consumer waits, use Lifecycle wait-chain.

Major common responsibilities include:

  • combat handlers: reload, AT, AA, artillery, alarm;
  • economy helpers: team funds, side supply, income, commander team;
  • structure and town helpers: factories, closest town/camp/depot, side structures;
  • network helpers: Common_SendToClient, Common_SendToClients, Common_SendToServer;
  • config loading: core models, gear, root definitions, defenses, groups;
  • module initialization: ICBM, IR smoke, CIPHER, boundaries.

Ownership nuance: this file is not purely shared. It also contains isServer-guarded compile/setup work around Common/Init/Init_Common.sqf:301-307, so moving functions between common/server/client owners needs a role check, not just a path check.

Server Init

Server/Init/Init_Server.sqf is authoritative. It compiles server functions, creates resistance center, initializes side logic and team state, starts global town scripts, starts cleanup/restorer loops, starts anti-stack if enabled, publishes server FPS, runs performance audit on server, launches day/night authority, and starts victory/resource loops.

Notable server loops:

  • Server/FSM/server_town.sqf
  • Server/FSM/server_town_ai.sqf
  • Server/FSM/server_victory_threeway.sqf
  • Server/FSM/updateresources.sqf
  • Server/FSM/server_collector_garbage.sqf
  • Server/FSM/emptyvehiclescollector.sqf
  • dropped item, crater, ruin and mine cleaners;
  • building restorer;
  • Server/Module/serverFPS/monitorServerFPS.sqf.

Source anchors: serverInitComplete = true at Server/Init/Init_Server.sqf:117, serverInitFull = true at :507, town AI at :514, victory at :528 and resource loop at :531.

Init hygiene note: the early server compile block still contains duplicate/legacy assignments such as WFBE_CO_FNC_LogGameEnd around Server/Init/Init_Server.sqf:64-65 and WFBE_SE_FNC_PlayerObjectsList around :88-91. Treat duplicate compile cleanup as a small but real init-maintenance lane; do not mix it with behavior changes unless smoke coverage names the affected functions.

Client Init

Client/Init/Init_Client.sqf initializes player-side behavior. It compiles client functions, registers damage/fired handlers, adds map/menu/action behaviors, starts day/night client sync when needed, applies skill/module actions, sends join/anti-stack handshakes, and starts client update loops.

Global gameplay hotkeys are wired here through findDisplay 46 KeyDown handlers. Gear filler hotkeys are separate in Client/Init/Init_Keybind.sqf.

JIP Stall Risks

Client init has several waitUntil gates on replicated state with no local timeout/retry path. The highest-risk waits are townInit, wfbe_structures, wfbe_commander, wfbe_radio_hq, wfbe_startpos, wfbe_hq_deployed and wfbe_votetime around Client/Init/Init_Client.sqf:360-371, :467-490 and :787-789. Keep the detailed dependency table in Lifecycle wait-chain, but mention this risk in entrypoint work because broken replication can look like a client boot freeze rather than a later gameplay bug.

Headless Init

Headless support is gated by the OA version check in initJIPCompatible.sqf. When supported and configured, Headless/Init/Init_HC.sqf loads client PVF handling and common init pieces needed for delegated AI.

Headless/Init/Init_HC.sqf currently uses a fixed delay and then sends ["RequestSpecial", ["connected-hc", player]] to the server. There is no explicit waitUntil {serverInitFull} barrier in that file, so HC timing bugs should be investigated against Lifecycle wait-chain and AI/headless together.

Source verification: Headless/Init/Init_HC.sqf:12 is sleep 20; :15 sends the connected-hc request. The server sets serverInitComplete = true early at Server/Init/Init_Server.sqf:117, waits for commonInitComplete && townInit at :127, and only later sets serverInitFull = true at :507. Treat the HC sleep as a timing proxy, not a real dependency barrier.

Confirmed finding cross-link: Deep-review findings DR-37 is the boot wait-chain review; use Lifecycle wait-chain before reordering init flags or replacing waits.

2026-06-02 Lifecycle Report Verification

Anscombe's lifecycle readout was source-checked against the actual Missions/[55-2hc]warfarev2_073v48co.chernarus tree. The report's Migrations path spelling was a typo; the substantive claims were confirmed and split between this page and Lifecycle wait-chain:

  • This page owns the entrypoint/include graph, role dispatch, mission-object town init layer and per-role init responsibilities.
  • Lifecycle wait-chain owns the machine-role truth table, ordered boot timelines, global flag dependency graph, JIP waits and HC timing caveat.
  • Keep future lifecycle additions in the page that owns the behavior. If the note is about "which file starts what", add it here. If it is about "what waits on what", add it to the wait-chain page.

Continue Reading

Previous: Architecture overview | Next: Lifecycle wait-chain

Main map: Home | Fast path: Quickstart | Agent file: agent-context.json

Sidebar

Clone this wiki locally