Victory And Endgame Atlas

Victory And Endgame Atlas

Canonical developer map for match end detection, winner/loser semantics, client outro flow, win-stat persistence and the patch-ready victory correctness risks. This page turns Deep-review findings DR-11, DR-12, DR-13 and DR-36 into a practical source-backed implementation guide.

Source anchors below are relative to Missions/[55-2hc]warfarev2_073v48co.chernarus/ in the docs checkout unless a section names another ref.

How To Use This Atlas

If you need to...	Start here	Then route to...
Patch match-end winner/loser correctness	Patch-ready risks, Safer patch shape	Hardening roadmap, Source fix propagation queue
Understand server startup and loop ownership	Startup and ownership, Current default detection	Server gameplay runtime atlas, Server runtime and operations
Touch the client outro, RHUD or endgame display	Endgame broadcast and client semantics	Client UI systems atlas, UI IDD collision repair
Audit final AntiStack persistence	Final score persistence and mission shutdown	AntiStack database extension audit
Clean stale logger/init bind archaeology	Stale duplicate logger	Server init bind cleanup, Dead/stale code register
Check current owner status	Current branch scope	Feature status, Pending owner decisions

Current Branch Scope

Source refreshed: 2026-06-14. Checked refs: docs checkout 2f2132f8, stable origin/master cf2a6d6a, Miksuu b8389e74, origin/perf/quick-wins 0076040f and release origin/release/2026-06-feature-bundle a96fdda2.

Scope	Current evidence	Development meaning
Default victory condition	All checked Chernarus and maintained Vanilla roots keep the same _victory == 0 detection shape: server_victory_threeway.sqf:3 reads WFBE_C_VICTORY_THREEWAY, :23 mixes elimination/all-towns precedence, :24 broadcasts HandleSpecial ["endgame", sideID], :31 writes WF_Winner, :33 sets WFBE_GameOver, :41 calls WFBE_CO_FNC_LogGameEnd, and :56/:88 call failMission "END1".	Winner/loser inversion, full-condition guard and no-break/double-fire remain patch-ready across every checked maintained root.
Victory constants	Docs/Miksuu/perf keep WFBE_C_VICTORY_THREEWAY at Common/Init/Init_CommonConstants.sqf:401-402; stable uses :421-422; release uses :417-418.	Cite the target branch when discussing line refs. Non-zero victory mode still needs an owner decision or implementation.
Stale Server/PVFunctions/LogGameEnd.sqf copy	Present in docs checkout, Miksuu and perf maintained roots; absent in stable origin/master and release maintained roots.	Do not restore or wire this copy where it has already been removed; where present, retire/delete it as DR-13 cleanup.
Server init duplicate binds	Docs checkout and Miksuu keep old live duplicate binds in Chernarus and Vanilla (Init_Server.sqf:64,89, :69,91, :83,93). Stable and release keep one live bind per function in both maintained roots. Perf fixes Chernarus but leaves Vanilla old-shape.	Treat duplicate-bind cleanup as branch-split. Use Server init bind cleanup before claiming a branch still has or already fixed DR-43b.

Why This Matters

Victory is a small script with huge consequences. It ends the mission, broadcasts the outro, stops long-running loops, stores AntiStack score deltas, flushes player lists and optionally increments persistent side win counters. A one-line logic mistake here can announce the wrong side, double-fire the endgame, overwrite winner state or permanently skew profileNamespace win statistics.

The important split:

• Server/FSM/server_victory_threeway.sqf owns default server-side detection and mission shutdown.
• Client/Functions/Client_FNC_Special.sqf receives the endgame special message and starts the client outro.
• Client/Client_EndGame.sqf treats its input as the losing side and flips it to display winner stats/camera focus.
• Server/Functions/Server_LogGameEnd.sqf is the live win-stat logger.
• Server/PVFunctions/LogGameEnd.sqf is a stale, buggy duplicate where still present; stable/release maintained roots have already removed it.

Source Map

Role	Files
Global initial state	initJIPCompatible.sqf:84-85
Victory mode fallback constant	Common/Init/Init_CommonConstants.sqf:400-402
Server compile/startup	Server/Init/Init_Server.sqf:64,89,526-529
Victory loop	Server/FSM/server_victory_threeway.sqf:1-88
Live win-stat logger	Server/Functions/Server_LogGameEnd.sqf:7-44
Stale duplicate logger	Server/PVFunctions/LogGameEnd.sqf:7-43 where present; absent from stable/release maintained roots
Client special receiver	Client/PVFunctions/HandleSpecial.sqf:16, Client/Functions/Client_FNC_Special.sqf:61-68
Client outro/camera/failMission	Client/Client_EndGame.sqf:3-89
Common loop stop flags	gameOver, WFBE_GameOver used across client/server FSMs
AntiStack final persistence	Server/FSM/server_victory_threeway.sqf:51-84, AntiStack database extension audit

Startup And Ownership

initJIPCompatible.sqf initializes both gameOver and WFBE_GameOver to false (initJIPCompatible.sqf:84-85). Many client and server loops use one or the other as their stop condition.

In the docs checkout, Init_Server.sqf compiles the live logger twice, both times to the same file (Init_Server.sqf:64,89). This is harmless today because the second bind overwrites the same code, but it is a maintenance trap and is tracked separately as the DR-43 duplicate-bind cleanup. Branch status is split: docs/Miksuu keep the duplicate in both maintained roots, stable/release have one live bind per function in both maintained roots, and perf fixes Chernarus only. Keep exact propagation notes on Server init bind cleanup.

After town initialization, the server starts the victory loop:

[] Spawn {
    waitUntil {townInit};
    [] execVM "Server\FSM\server_victory_threeway.sqf";
    ["INITIALIZATION", "Init_Server.sqf: Victory Condition FSM is initialized."] Call WFBE_CO_FNC_LogContent;
    [] ExecVM "Server\FSM\updateresources.sqf";
};

The victory loop is therefore separate from town capture, economy/resources and HQ construction. Town ownership and HQ/factory state feed it, but they do not end the match directly.

Current Default Detection

server_victory_threeway.sqf reads:

• _victory = missionNamespace getVariable "WFBE_C_VICTORY_THREEWAY" (:3);
• _total = totalTowns (:4);
• _loopTimer = 80 (:6).

Every 80 seconds, when _victory == 0, it checks each present side except WFBE_DEFENDER (server_victory_threeway.sqf:9-46).

For each side _x, it computes:

Value	Meaning	Source
_hq	Side HQ/MHQ object from side logic.	server_victory_threeway.sqf:14
_structures	Side base structures.	:15
_towns	Count of towns held by side.	:16
_factories	Count of barracks, light, heavy and aircraft factories found from side structures.	:18-21

The current condition is:

if (!(alive _hq) && _factories == 0 || _towns == _total && !WFBE_GameOver) then {

Because SQF && binds tighter than ||, this behaves like:

((!alive _hq) && (_factories == 0)) || ((_towns == _total) && !WFBE_GameOver)

That means !WFBE_GameOver guards only the all-towns clause, not the HQ/factory elimination clause.

Endgame Broadcast And Client Semantics

When the condition fires, the server broadcasts:

[nil, "HandleSpecial", ["endgame", (_x) Call WFBE_CO_FNC_GetSideID]] Call WFBE_CO_FNC_SendToClients;

The client receives HandleSpecial tag "endgame" and spawns WFBE_CL_FNC_EndGame (Client/PVFunctions/HandleSpecial.sqf:16). That function sets local gameOver = true, WFBE_GameOver = true, converts the side id to a side value and executes Client\Client_EndGame.sqf (Client_FNC_Special.sqf:61-68).

Client_EndGame.sqf then flips the side it receives:

//todo improve that script, _side is the looser.
if (_side == west) then {
    _side = east;
} else {
    if (_side == east) then {_side = west};
};

So the current client payload is semantically "loser side id", not "winner side id." This is easy to misread because the server also writes WF_Winner in the same block. Wave S tightened this further: _x is the eliminated/losing side in the HQ/factory branch, but _x is the winning side in the all-towns branch. Any patch must compute explicit _winnerSide and _loserSide per branch, then keep the client, logger and messages consistent.

The client outro:

• runs end-of-game stats for the flipped side (Client_EndGame.sqf:13);
• plays wf_outro (:14-16);
• builds a camera target list from the winner and opponent HQ/structures (:18-30);
• ejects and moves the player near friendly HQ as a safety position (:40-45);
• terminates death camera effects if needed (:47-52);
• runs a camera tour (:54-86);
• calls failMission "END1" after a short delay (:88-89).

UI note: endgame stats have a unique idd, but GUI_EndOfGameStats.sqf shares uiNamespace["currentCutDisplay"] with OptionsAvailable/RHUD action title recovery. Route visual fixes through UI IDD collision repair so the outro, RHUD/FPS and action icons are smoked together.

Winner Logging

Inside the server victory block, the code writes:

WF_Logic setVariable ["WF_Winner", _x];
...
_side = west;
if (_x == west) then {
    _side = east;
};
[_side] call WFBE_CO_FNC_LogGameEnd;

The live logger expects its first argument to be the winning side (Server_LogGameEnd.sqf:9-12). It increments profileNamespace key "%1_WIN_CHERNARUS" for that side when WFBE_Server_LogMatchWin is enabled (Server_LogGameEnd.sqf:21-44).

This is correct for a side being eliminated: if _x is the loser, the opposite side should be logged as winner. It is wrong for an all-towns victory: if _x holds all towns, _x is the winner, but the current block still logs the opposite side. Treat WF_Winner in current source as branch-dependent and therefore unreliable: it stores the condition side, not a consistently named winner.

Deep Review DR-11 owns this impact, and DR-36 owns the exact guard/precedence/no-break mechanism.

Final Score Persistence And Mission Shutdown

After gameOver becomes true, the while {!gameOver} loop exits and the tail runs.

If AntiStack is disabled, the script logs that final DB persistence is skipped, sleeps 5 seconds, writes a final RPT line and calls failMission "END1" (server_victory_threeway.sqf:51-57). This disabled-mode shortcut is intentional because the sampling loop is not running; see AntiStack database extension audit.

If AntiStack is enabled, the script:

1. iterates allUnits (server_victory_threeway.sqf:59-82);
2. for player units, reads current and old score variables by UID (:61-77);
3. stores score delta through WFBE_SE_FNC_CallDatabaseStore (:78);
4. sleeps _miniSleep = 0.05 per player (:7,79);
5. calls WFBE_SE_FNC_CallDatabaseFlushPlayerList (:84);
6. sleeps 5 seconds, logs and calls failMission "END1" (:86-88).

DR-36 found the loop cadence/performance posture clean: the victory check itself runs every 80 seconds and the final persistence tail is bounded by player count. The JIP gap is narrow: endgame broadcast and WFBE_GameOver are not replayed to a player who joins in the few seconds before failMission, but the mission is already ending.

AntiStack nuance from Wave S: mainLoop.sqf and flushLoop.sqf stop on WFBE_GameOver, but updateScoreInternal.sqf:13 uses while { true }. Mission shutdown follows shortly after victory, so this is a low-risk cleanup nuance rather than a result-integrity root cause.

Stale Duplicate Logger

Server/PVFunctions/LogGameEnd.sqf is present in the docs checkout, Miksuu and perf maintained roots, but is absent in stable origin/master and release maintained roots. Where present, it is not registered by Common/Init/Init_PublicVariables.sqf. SQF-Code-Atlas already notes the live compile uses Server/Functions/Server_LogGameEnd.sqf.

The duplicate is dangerous archaeology:

• it treats _this directly as _winnerTeam instead of _this select 0 (PVFunctions/LogGameEnd.sqf:9);
• it uses a profileNamespace getVariable result as the setVariable key (:31);
• it reads WEST_WIN_CHERNARUS and EAST_WIN_CHERNARUS as bare globals instead of string keys (:40-41).

Do not wire this PVF copy. Delete or mark it retired where present, and preserve the stable/release removal when merging from those branches.

Patch-Ready Risks

Status	Risk	Evidence	Patch direction
P1 correctness	All-towns victory logs the opposite side as winner.	server_victory_threeway.sqf:23-41, Server_LogGameEnd.sqf:9-44, DR-11.	Split elimination and all-towns branches or compute winnerSide explicitly per branch.
P1 correctness	!WFBE_GameOver only guards the all-towns clause. HQ/factory elimination can fire again after gameOver within the same side loop.	server_victory_threeway.sqf:23, DR-36.	Parenthesize the full condition or compute booleans, then guard the combined result with !WFBE_GameOver.
P1 correctness	Side loop has no break after a winner is recorded. Same-tick eliminations can double-broadcast and double-log.	server_victory_threeway.sqf:12-43, DR-36.	Exit the side loop and/or outer loop once gameOver is set.
Owner decision	Non-zero WFBE_C_VICTORY_THREEWAY skips the only detection block.	CommonConstants.sqf:401, server_victory_threeway.sqf:3,11, DR-12.	Implement non-default mode or keep it undocumented/disabled with a clear guardrail.
Cleanup	Stale Server/PVFunctions/LogGameEnd.sqf is buggy if ever wired. It is present in docs/Miksuu/perf and absent in stable/release maintained roots.	PVFunctions/LogGameEnd.sqf:9-43, DR-13, Current branch scope.	Delete/retire the duplicate where present; preserve branches where it is already gone.
Cleanup	WFBE_CO_FNC_LogGameEnd is compiled twice in server init only on some refs/roots.	Docs checkout Init_Server.sqf:64,89, DR-43, Server init bind cleanup.	De-duplicate live binds where still present; do not reintroduce duplicates into stable/release or perf Chernarus.
Semantics risk	Client endgame script expects loser side, while server variable name WF_Winner implies winner.	Client_EndGame.sqf:3-13, server_victory_threeway.sqf:24,31-41.	Pick explicit payload naming and keep server broadcast, client stats/camera and logger aligned.

Safer Patch Shape

Keep the first code patch small and source-first:

1. Compute two named booleans:
   • _sideEliminated = !(alive _hq) && _factories == 0;
   • _sideWonByTowns = _towns == _total.
2. Guard both with !WFBE_GameOver.
3. Compute _loserSide and _winnerSide explicitly:
   • if eliminated, loser is _x, winner is the opposite active side;
   • if won by towns, winner is _x, loser is the opposite active side.
4. Send the current client payload as loser side id unless you intentionally update Client_EndGame.sqf at the same time.
5. Set WF_Winner to _winnerSide if keeping that variable.
6. Call WFBE_CO_FNC_LogGameEnd with [_winnerSide].
7. exitWith after one accepted endgame path so only one endgame broadcast/log can happen per match.
8. Leave AntiStack final persistence and failMission "END1" tail unchanged.

Do not combine this with PVF dispatcher hardening or AntiStack DB wrapper hardening unless the branch is explicitly an endgame persistence branch. The match-outcome fix is valuable by itself and easier to smoke.

Smoke Checklist

Scenario	Expected result
West eliminated by dead HQ plus zero barracks/light/heavy/air factories	One endgame broadcast with west as loser; east logged as winner once.
East eliminated	One endgame broadcast with east as loser; west logged as winner once.
West holds all towns	West logged as winner, not east; client outro still shows correct winning side.
East holds all towns	East logged as winner, not west.
Same-tick mutual elimination	One winner decision only; no double HandleSpecial ["endgame", ...], no double LogGameEnd, no overwritten WF_Winner.
AntiStack disabled	Final DB persistence is skipped cleanly and mission still ends.
AntiStack enabled	Player score deltas store/flush once, then mission ends.
Non-zero WFBE_C_VICTORY_THREEWAY	Either implemented and smoked, or explicitly guarded as unsupported so admins do not expect auto-end behavior.
Generated propagation	Chernarus source patch reaches Vanilla Takistan through LoadoutManager; modded forks are separately owned.

Continue Reading

Previous: Towns, camps and capture atlas | Next: Server gameplay runtime atlas

Main map: Home | Evidence log: Deep-review findings | Patch order: Hardening roadmap