Mission Entrypoints And Lifecycle

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.

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, but it is not committed in the current repo checkout. Treat it as generated terrain metadata from LoadoutManager, not as an optional nicety: a fresh source mission needs version.sqf produced or supplied before it can preprocess cleanly.

Source verification: description.ext:39 includes version.sqf; :41-58 include sound, music and Rsc bundles; :64-67 set loadScreen, disableChannels[] and disabledAI. version.sqf is absent from the current Chernarus source mission checkout, so the generated-file warning is current.

Confirmed finding cross-link: Deep-review findings DR-43a tracks the missing version.sqf source/build 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, 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.

Key flags to look up there before reordering init code:

Flag	Why it matters
VERSION_SET	Unblocks version-dependent initialization.
WFBE_Parameters_Ready	Unblocks town mode and town object setup.
commonInitComplete	Unblocks server/client/town consumers of common functions and config.
townInit / townInitServer	Separate common town setup from server-side town distribution/camp follow-up.
serverInitComplete / serverInitFull	Distinguish early server readiness from full per-side setup.
clientInitComplete	Signals that client-local initialization finished.

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.

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.

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.

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.

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