JIP Enrollment And Client Data Delivery

JIP Enrollment And Client Data Delivery (b74.2 lessons)

How a joining player gets their team, cash, commander‑vote roster and own‑side map markers — and the hard A2‑OA limitations that made the long‑standing "join a team but have no cash / no markers / not in the vote menu = mission unplayable" bug so stubborn. Captured after it was finally fixed in b744 (June 2026) following five failed attempts. Read this before touching anything on the JIP/enrollment path.

The symptom

A player who joined a team (from the lobby or mid‑game) could end up with:

• no funds in the HUD,
• no own‑side map markers (team arrows / factories),
• missing from the commander‑vote roster (only "No Commander" shows),

i.e. effectively unable to play. World/AICOM markers eventually appeared; only the player's own enrollment failed. It hit WEST and EAST (not GUER‑specific) and got worse under heavy AI load / low server FPS.

Root cause (the thing that took 5 tries to see)

The client's team roster comes from the side‑logic object variable wfbe_teams, set on the server with the broadcast flag: WFBE_L_<side> setVariable ["wfbe_teams", _teams, true] (Server/Init/Init_Server.sqf). _teams is an array of GROUP OBJECTS.

In Arma 2 OA 1.64 this has two fatal properties for a late joiner:

1. Object setVariable [..., true] is NOT JIP‑durable. A broadcast performed before a client connected is not stored‑and‑replayed to it. Re‑setting the same value on connect (a "mark dirty" re‑broadcast) is unreliable under load — the side‑logic object itself is slow/never to fully sync to the joiner.
2. Group objects do not survive the wire to a machine that did not create them. Even when the array eventually arrives, the group handles inside it deserialize to broken / null refs on the client. Every consumer reads through those groups — the vote menu (isPlayer leader (WFBE_Client_Teams select i), name leader …), the own‑team marker FSM (getPos/getDir/leader on each group). With broken groups the roster shows nothing and the arrows never draw.

Why the earlier fixes failed: B56 (bounded loading wait), B62/B64 (120 s reconciliation), and the B74.2.4 persistent heal (poll every 2 s for 30 min) all read the same dead channel — _logik getVariable "wfbe_teams". They differ only in how long they wait. But the failure is not a timing problem you can wait out: the channel does not deliver to a late joiner and the payload type (group handles) is non‑portable. A real capture confirmed it: CLIENTTEAMS|EARLYHEAL|side=EAST|count=17|at=670s — the array "arrived" at 11 minutes, full of broken refs, player still saw nothing.

The fix (b74.2.5 / b744)

Stop fighting the un‑deliverable channel. Deliver primitives over the channel A2‑OA does guarantee to a connected client — the same one the B63 marker feeds already use successfully:

• Server, on connect (Server/Functions/Server_OnPlayerConnected.sqf, where _id and _sideJoined are valid; gated to west/east which are the only sides with a commander vote): build a per‑side primitive roster — per player‑led team [name leader, isPlayer(0/1), funds, str group] — set it into a side‑keyed missionNamespace var WFBE_JIP_ROSTER_<SIDE> and _id publicVariableClient it. Strings/numbers replicate cleanly; no group handles go over the wire.
• Client, EARLY (initJIPCompatible.sqf Part I, before the B56 wait and before Init_Client): an addPublicVariableEventHandler for the WEST/EAST keys stores the payload into WFBE_JIP_ROSTER_PRIMS, plus a one‑shot poll that adopts a value that landed before the EH installed (a publicVariable target persists in missionNamespace).
• Vote menus (GUI_VoteMenu.sqf, GUI_Commander_VoteMenu.sqf): render rows from the primitive cache when no live player‑led team exists, and gate every per‑tick refresh loop behind a …_USING_PRIMS flag so they never prune/blank the primitive rows. Hand over to live groups (one lnbClear+rebuild) the moment a live player‑led team appears, so vote casting still maps to real group objects.
• Cash was already fine — GetPlayerFunds reads (group player) getVariable "wfbe_funds", the player's own (local) group, which the server stamps broadcast at connect. Don't touch it.
• Markers keep upgrading automatically: the existing heal rebinds clientTeams to live groups when they finally replicate, and the marker FSM redraws. Marker geometry genuinely needs live objects, so it is not accelerated — that degrades gracefully (roster + cash arrive fast; arrows fill in on heal).

Outcome the player sees: cash within seconds, a stable vote roster within seconds (CLIENTROSTER|RECV|key=WFBE_JIP_ROSTER_WEST|rows=N on the client RPT is the proof), markers + casting as the live groups settle.

Second root cause (cmdcon30, 2026-06-30): a reaped editor‑slot group → DEADSPAWN

This is a different enrollment failure from the b74.2 channel bug above, found by a 16‑agent audit and fixed in cmdcon30. Symptom is worse than the b74.2 one: not "join a team but no cash/markers", but no team at all — the player lands in DEADSPAWN (no team / HUD / markers / vote). JIP / mid‑match only.

The chain:

1. PR#122 (the qol‑polish‑pack) added an editor‑slot reaper to the WFBE_EDITOR_GROUPS_TAGGED sweep in Server/Init/Init_Server.sqf (the block at ~line 828). To reclaim per‑side group‑cap headroom it called deleteGroup on empty west/east/resistance editor player‑slot groups.
2. But ~13/side are "overflow" slots whose placeholder unit self‑deletes at load (mission.sqm init="… deleteVehicle this"), leaving an empty group that a human can STILL JIP into. The reaper's only discriminator was zero units, so it deleteGroup'd a JIP‑selectable slot's group.
3. A player joining that slot landed in the already‑deleted group. The group had no wfbe_side variable.
4. The B746 enrollment resolver in Server/Functions/Server_OnPlayerConnected.sqf reads _team getVariable "wfbe_side" (~line 134); when it is nil it bails and re‑arms the handler — the WFBE_CONNECT_RETRY_<uid> "re‑arming enrollment … attempt N/3" loop (~lines 118‑140), capped at 3.
5. The re‑arms hit the same dead group every time, exhaust the 3‑attempt budget, and the player is left in DEADSPAWN forever (for that session).

The re‑join trap (the nasty part). WFBE_CONNECT_RETRY_<uid> was cleared only on enrollment SUCCESS (Server_OnPlayerConnected.sqf ~line 143), never on disconnect. So after a 3×‑exhausted enrollment, a re‑join with the same UID found the counter already at 3 → got zero fresh re‑arms → re‑bailed → permanent deadspawn until a server restart, even if a good slot was now free.

Fix (cmdcon30):

• Removed the reaper entirely — reverted to the pre‑PR122 audit‑only tag sweep. The empty overflow slots ran the whole pre‑PR122 history with no group‑cap problem, and the only safe reap would have to skip them anyway (active player‑slot groups carry wfbe_persistent=true, which the persistence‑aware server_groupsGC honours and the reaper did not). The sweep now only does setVariable ["wfbe_group_src", "editor-player-slot", true] (Init_Server.sqf ~line 850). Never deleteGroup a JIP‑selectable slot group at boot.
• Clear WFBE_CONNECT_RETRY_<uid> on disconnect so a re‑join always gets the full 3‑attempt self‑heal again (Server/Functions/Server_OnPlayerDisconnected.sqf lines 20‑27, setVariable […, nil]; HCs never hold the key so it is a harmless no‑op for them).
• Two related cmdcon30 client fixes shipped at the same time (both in the PR#122 name‑tag overlay path): getPosVisual (Arma‑3‑only, undefined in A2‑OA 1.64 — the file's "A2‑safe … no A3 commands" comment was wrong) → visiblePosition in Client/Init/Init_Client.sqf (~line 245); and an isNil "WFBE_Client_Logic" guard around the setVariable in Client/Functions/Client_FNC_Special.sqf (~lines 268‑274) for a JIP race.

Correction to earlier docs: any note that describes the editor‑slot reaper as active, or getPosVisual as "A2‑safe", is now wrong — see the cmdcon30 revert above.

The server‑only changes (reaper revert, disconnect retry‑clear) take effect in‑place on a restart; the two client fixes had to ship under a new PBO filename (see the deploy lesson below) or they would have looked inert on cached A2‑OA clients.

Reusable rules

1. A2‑OA JIP data delivery. Object setVariable [...,true] is not replayed to a client that joined after the set, and group/object handles arrive broken on a client that did not create them. To get side/global state to a JIP client reliably, push primitives with publicVariableClient to that client on connect (onPlayerConnected, _id is the target), and rebuild UI from the primitives. Never expect a JIP client to read live group handles out of a broadcast var.
2. count nil is 0 (safe); forEach nil THROWS. A global read with no default (missionNamespace getVariable "X") is nil when unset. for _i from 0 to count X - 1 is safe (count nil = 0), but {...} forEach X over nil is a runtime error. Default such arrays to [] (getVariable [name, []]) before any forEach.
3. Client‑facing changes REQUIRE a new PBO filename. See the deploy note below — this is the reason four correct fixes looked like they "did nothing."
4. Diagnose from the CLIENT RPT. Client script errors never appear in the server RPT. WFBE_CO_FNC_LogContent ([INITIALIZATION]/[WARNING]) is filtered out on public builds (WF_LOG_CONTENT off in version.sqf) — use raw diag_log for production telemetry. The markers added for this bug: server TEAMREG|side=…|registered=N, ROSTER-PUSH; client CLIENTROSTER|RECV/POLL-ADOPT, CLIENTTEAMS|atInit/EARLYHEAL/WAIT.
5. Verify before deploy. Multi‑agent adversarial review caught two ship‑blockers in the primitive design that single‑pass authoring missed: pushing group objects (still broken on JIP) and an ungated 0.05 s vote loop that blanked the primitive names + threw nil getVariable every tick. Root‑cause + fix were both wrong on earlier passes; verification is not optional on the join path.
6. Never deleteGroup an empty editor player‑slot group at boot (cmdcon30). "Empty" is not "unused": the ~13/side overflow slots have their placeholder unit deleteVehicle'd at load yet stay JIP‑selectable. Reaping them for group‑cap headroom strands any joiner in a dead, wfbe_side‑less group → exhausted enrollment → DEADSPAWN. Active slot groups carry wfbe_persistent=true; let the persistence‑aware server_groupsGC own group reclamation, and keep the editor‑slot sweep audit‑only (tag, don't delete).
7. Clear UID‑keyed retry budgets on disconnect, not just on success (cmdcon30). A self‑heal counter that is only reset on the success path (WFBE_CONNECT_RETRY_<uid>) makes failure sticky across reconnects: a re‑join with the same UID inherits the maxed counter and gets zero fresh re‑arms → permanent deadspawn until restart. Reset such counters in Server_OnPlayerDisconnected.sqf so every fresh join starts with the full self‑heal budget.

CRITICAL deploy lesson — bump the PBO name for client changes

The single biggest time sink: in‑place hotfixes (same PBO filename) do not reach clients. Arma 2 OA caches downloaded missions by filename in the client MPMissionsCache; when the server's PBO content changes but the filename stays the same, clients re‑download unreliably and usually reuse the stale cache. The server picked up every b74.2.x fix (verified in the deployed PBO + server RPT), but the player's client kept running the stale cached b742aicom — so every client‑side fix was invisible and the bug "persisted" through multiple deploys (the client RPT had zero of the new telemetry).

The repo's whole version history (…b55, …b56, … …b742aicom) uses a distinct filename per build for exactly this reason. The fix that finally reached the client was renaming b743aicom → b744aicom.

Reinforced by cmdcon30 (2026-06-30). That patch is a clean split of the two cases: its client‑side fixes (getPosVisual→visiblePosition in Init_Client.sqf, the isNil "WFBE_Client_Logic" guard in Client_FNC_Special.sqf) would have looked inert on cached A2‑OA clients, so the whole patch shipped under a new PBO filename. Its server‑only fixes (the editor‑slot reaper revert in Init_Server.sqf, the disconnect retry‑clear in Server_OnPlayerDisconnected.sqf) took effect in‑place on the restart regardless of the name. Same rule, fresh proof: bump the name whenever the player's machine runs the changed script.

Rule: any change touching client‑side scripts (Client/*, Init_Client.sqf, GUI, marker FSMs — anything the player's machine runs) MUST deploy under a new PBO filename and repoint the server.cfg mission template, with the PBO prefix set to match. Server‑only changes (Server/*, HC AICOM logic) do take effect in‑place on a restart. When in doubt, bump the name. Deploy mechanics that bit us:

• Stop the service before editing server.cfg — it is file‑locked while the server runs (Set-Content fails with "being used by another process"). Stop → edit → restart.
• The deployed PBO path contains [brackets]; use literal‑path file copy ([IO.File]::Copy), not wildcard‑expanding Copy-Item/Get-Item, or the copy silently no‑ops.
• The restart wrapper runs a ~5‑minute headless‑client reseat dance and archives the RPT — don't race it with concurrent polls; wait for a new "RESTART DONE" marker.
• Boot‑smoke = MISSINIT reads the new build name + ErrInExpr=0. Confirm the fix reached the player by checking the client RPT for the new telemetry, not just the server RPT.

See also: Server Ops Runbook, Developer History And Upstream Lessons, Client Marker FSM Updater Map, AI Commander Logging And AICOMSTAT Telemetry.