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.

Connect-time sync map

Use this as the first-pass checklist when reviewing any new JIP-visible feature. If a value is not on a durable path here, it must either be rebuilt locally or given an explicit catch-up path before it is safe for late joiners.

Data / feature	Current delivery path	JIP expectation
Own player group, side, and funds	Server stamps the joining player's group during Server_OnPlayerConnected; client reads its own local group, e.g. (group player) getVariable "wfbe_funds".	Safe for own-player state. Do not replace this with a side-logic roster read.
Commander-vote roster	Server builds primitive rows in WFBE_JIP_ROSTER_<SIDE> and sends them to the joining client with _id publicVariableClient; the early client receiver in initJIPCompatible.sqf stores WFBE_JIP_ROSTER_PRIMS.	Safe when the payload stays primitive-only. Proof tokens are ROSTER-PUSH, `CLIENTROSTER
wfbe_teams on side logic	Server broadcasts an array of group objects on WFBE_L_<side>.	Not safe for late-JIP UI or bootstrap logic. Late clients can miss the object variable entirely, and group handles can deserialize as broken refs.
Own-side team/factory markers	Marker FSMs and heal/rebind loops eventually attach to live objects/groups when those objects settle on the client.	Degrades gracefully, but it is not an instant catch-up channel. New marker features need a primitive snapshot or a request/reply replay if the marker must exist immediately after connect.
AICOM / patrol / marker-feed arrays	The B63/B74.2 connect handler pushes current marker feeds and side-keyed AICOM status primitives to the joining client. Older PR #125 also introduced a WFBE_ReqAicomFeed request/reply pattern for feeds that need an explicit replay after connect.	Treat this as named catch-up, not proof that every future feed is safe. Any new feed still needs a current snapshot, a request/reply route, or a local rebuild story plus client-side shape defaults. Proof tokens include B63 JIP-MARK and B74.2 AICOM-JIP.
Side upgrades and side supply	Build84 keeps wfbe_upgrades on the side-logic object and wfbe_supply_<side> in missionNamespace; both are normally updated when the economy state changes. Draft PR #489 (codex/lane189-jip-sync-pack, 33f7298) adds B63.2 connect-time catch-up: re-broadcast wfbe_upgrades from the side logic and targeted _id publicVariableClient for wfbe_supply_<side> when currency mode uses side supply.	Baseline Build84 consumers should still use defaults and guards. Once PR #489 lands, proof tokens are B63.2 JIP-UPGRADES and B63.2 JIP-SUPPLY; until then, treat upgrade/supply visibility for late joiners as pending catch-up debt.
Client presentation changes	Stored in the mission PBO downloaded by the player's machine.	Requires a new PBO filename. Same-name hotfixes often leave clients running the cached old script.

B63/B64 block anatomy

The B63/B64 fixes that survived production all follow the same shape:

1. Install any addPublicVariableEventHandler and one-shot poll before blocking waits, UI construction, or Init_Client consumers.
2. Use primitive payloads: strings, numbers, booleans, simple arrays. Never send group/object handles as the only late-JIP source of truth.
3. Bound every bootstrap wait with uiSleep and a counter. If the data is late or missing, log and continue with a degraded state instead of freezing the loading screen.
4. Keep presentation loops from erasing fallback data. The vote menus needed a ..._USING_PRIMS gate so the 0.05 s refresh loop did not clear primitive rows before live groups appeared.
5. Add raw diag_log tokens that survive public builds. The useful family here is CLIENTROSTER, TEAMREG, ROSTER-PUSH, CLIENTTEAMS, B63 JIP-MARK, B74.2 AICOM-JIP, B63.2 JIP-UPGRADES, and B63.2 JIP-SUPPLY.
6. Prefer one-shot adoption plus later handoff to live state. The client can render a primitive roster immediately, then rebuild once live player-led groups become valid.

Client/Init/Init_BaseStructure.sqf mirrors the same lesson on the base-marker path: it uses a bounded clientInitComplete gate and compares against the server-fed side id instead of trusting JIP-time client side drift. It is a good small template for "wait briefly, validate shape, then continue".

Lane-189 gaps and feed replay

The "lane 189" class is best understood as late-JIP catch-up debt: places where a connected client sees event-driven public state only after the next event, not from a current snapshot. Marker feeds, AICOM public status, patrol arrays, support effects, UI-only event streams, side upgrades, and side supply can all fall into this bucket.

The current lane-189 implementation is draft PR #489, Push JIP upgrade and supply state (codex/lane189-jip-sync-pack at 33f7298, still open/draft as of 2026-07-03). It adds a B63.2 block in Server_OnPlayerConnected.sqf for Chernarus plus the maintained Vanilla Takistan/Zargabad mirrors:

• wfbe_upgrades remains a side-logic object variable, so the join handler re-sets the current value with setVariable [..., true] to dirty the object var for replication.
• wfbe_supply_<side> is a primitive missionNamespace value, so the join handler can send it directly to the joining client with _id publicVariableClient _jipSupplyKey when WFBE_C_ECONOMY_CURRENCY_SYSTEM == 0.
• The production proof tokens are [WFBE][B63.2 JIP-UPGRADES] and [WFBE][B63.2 JIP-SUPPLY].

PR #125 is an older adjacent checkpoint, not the lane-189 result. Its WFBE_ReqAicomFeed request route and server-side rebroadcasts for active AICOM/focus/team/funds and marker-feed variables are still the pattern to copy when a feed needs client-requested replay, and its consumer shape guards prevent stale or malformed arrays from becoming forEach nil / bad-index crashes. A new feature should explicitly choose one of these stories:

1. It is durable own-player state and can be read from the local player/group.
2. It is sent to the joining client with targeted publicVariableClient.
3. It has an explicit request/reply catch-up channel like WFBE_ReqAicomFeed.
4. It is presentation-only and can be rebuilt locally from already-durable state.
5. It is not JIP-safe yet and must stay behind a default-off flag or docs-only status until the catch-up path exists.

Black-screen history and MaxSizeGuaranteed

The black-screen fixes were a chain, not one magic line:

• B49's attempted wait fix was effectively a no-op for the real late-JIP failure.
• B54 moved loading-screen waits onto uiSleep, because mission time and ordinary sleeps are unreliable while the player is still in the loading shell.
• B56 bounded the WFBE_PRESENTSIDES and per-side wfbe_teams waits in initJIPCompatible.sqf; this stopped permanent black screens but still did not make wfbe_teams a valid JIP data source.
• The server MaxSizeGuaranteed=512 change belongs to the connection-stability layer. It helped with the "message not sent" / oversized guaranteed packet box, but it did not change A2-OA's object-variable replay semantics. Do not cite it as proof that late clients can read old setVariable [..., true] broadcasts.

So the current rule is: bounded waits prevent black screens, MaxSizeGuaranteed protects network packet delivery, and primitive targeted sync fixes the actual data model.

JIP-safe pattern for new features

1. Decide the late-join payload first. Prefer primitives and give every array read a getVariable [name, []] default.
2. Send the current snapshot on connect to _id, or expose a client request that causes the server to rebroadcast the current snapshot.
3. Install the client receiver before waits and UI consumers.
4. Bound the wait with uiSleep; keep the mission playable if the data is late.
5. Keep fallback UI rows alive until live objects are actually valid.
6. Never forEach an unset global, and never treat an object/group handle from a broadcast var as portable evidence.
7. Add raw RPT tokens that prove send, receive, adoption, and fallback/handoff.
8. If any client-side script changed, ship under a new PBO filename and verify the client RPT, not only the server RPT.

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.
8. Every JIP-visible feature needs a named catch-up path. Durable local state, targeted publicVariableClient, request/reply replay, or local rebuild are valid answers. "It was publicVariabled earlier" and "the side logic should have it" are not valid answers for late clients.

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.