Skip to content

AI Headless And Performance

rayswaynl edited this page Jul 2, 2026 · 36 revisions

AI, Headless And Performance

This page is the broad gateway for AI, headless-client behavior, player-AI recovery and performance ownership. For loop-level runtime and HC delegation tables, use AI runtime/HC loop map; for implementation decisions, use the narrower owner pages linked below.

For the old BennyBoy WarfareBE vs current Wasp FPS archaeology pass, see Old WarfareBE performance comparison. It is useful when discussing whether older mission code was lighter, because it compares old per-town FSM activation and FPS-gated client delegation against current global town loops and HC mode.

Unless a row names another ref, source anchors below are from the repo docs branch HEAD@c0e865626ff2 (docs/developer-wiki-index). Rechecked 2026-06-24 for the AI commander supervisor lane: docs/source still lacks checked maintained-root Server/AI/Commander/AI_Commander.sqf and AI_Commander_Produce.sqf files, while current stable/B74.1 is origin/master@f8a76de34 and current B74.2 is origin/claude/b74.2-aicom@21b62b04. Detailed HC, town-AI, supply-truck and branch-only feature matrices stay on the owner pages linked below.

How To Use This Page

Need Open first
Runtime loop and HC delegation source map AI runtime/HC loop map
HC disconnect, callback, timeout and failover design Headless delegation and failover, HC upstream history and lessons
AI commander, autonomous logistics or feat/ai-commander review AI commander autonomy audit, branch-only feature smoke pack
AICOM stuck teams, recovery v2 tokens and TARGET_ABANDON reasons AICOM stuck-recovery v2
Town AI cleanup safety and player-occupied vehicles Town AI vehicle despawn safety
Patrols v2 vs old patrols Towns/camps/capture, AI runtime/HC loop map
Server FPS, audit RPTs and full-server performance tests Server gameplay runtime atlas, Performance opportunity sweep, Testing workflow
Old BE comparison, player-AI caps and role balance Old WarfareBE performance comparison, Player AI caps and role balance

Current Branch Scope

Use this table before turning this broad atlas into a branch claim. Detailed matrices stay on the owner pages.

Ref AI / HC / performance scope Practical route
Repo docs branch HEAD@c0e865626ff2 Checked maintained roots have no Server/AI/Commander/AI_Commander.sqf or AI_Commander_Produce.sqf; they compile the old upgrade worker at Server/Init/Init_Server.sqf:48, reset wfbe_aicom_running at :364, and still raw-spawn the missing-FSM AI supply-truck worker when truck supply plus AICOM logistics are enabled (Init_Server.sqf:36,381-383). Use this page for orientation, then open AI runtime/HC loop map or AI commander autonomy audit before making patch-status claims.
Current stable/B74.1 origin/master@f8a76de34 / origin/claude/b74.1-aicom@f8a76de34 Current stable has a real maintained-root AICOM supervisor route: it compiles WFBE_SE_FNC_AI_Commander at Chernarus Init_Server.sqf:72 and Vanilla :66, spawns it for present non-GUER sides at Chernarus :1028 / Vanilla :1015, sets/clears the full-command latch at AI_Commander.sqf:161,339 in Chernarus and :161,338 in Vanilla, calls the upgrade worker at :288, and calls AIBuyUnit for AI-team production from AI_Commander_Produce.sqf:320. Legacy AI supply-truck logistics are warning-disabled instead of raw-spawned at Chernarus Init_Server.sqf:44,625 and Vanilla :44,619. Current-master AI runtime claims should start from AI commander autonomy audit, AI runtime/HC loop map, Towns/camps/capture and Server gameplay runtime atlas.
Current B74.2 origin/claude/b74.2-aicom@21b62b04 Branch-only source Chernarus work over current stable. Maintained Vanilla keeps the stable/B74.1 supervisor anchors. Source Chernarus keeps the same compile/run-flag/worker semantics, line-drifts supervisor spawn to Init_Server.sqf:1061 / restart spawn :1089 / wildcard :1102, reads pop-tier AI cap data at AI_Commander_Produce.sqf:28, and current-head d472da6a..21b62b04 moves the GUER stipend launch to Init_Server.sqf:813. There is no maintained Vanilla payload for those B74.2-only changes. Treat as branch-only until branch-only feature smoke pack evidence and a Vanilla/Takistan scope decision exist.
Historical release commit a96fdda2 Safe-disables legacy AI supply-truck logistics at Init_Server.sqf:37,384 in both maintained roots and has the single server-FPS publisher shape, but no checked maintained-root Server/AI/Commander/AI_Commander.sqf / _Produce.sqf files and no live release/* head was exposed in the 2026-06-24 source sweep. Do not cite release as current AICOM supervisor or Patrols v2 evidence. Use Towns/camps/capture for the historical release patrol scope.
Miksuu b8389e748243 and origin/perf/quick-wins 0076040f Both lack checked maintained-root AICOM supervisor/produce files and keep raw-spawning the old missing-FSM AI supply-truck worker; direct Miksuu uses Init_Server.sqf:36,381-383, while perf uses Chernarus :36,376-378 and Vanilla :36,381-383. Recheck exact branch files before merging AI/runtime changes; route old-branch patrol and supply-truck claims through owner matrices.
origin/feat/ai-commander c20ce153 Branch-only AI commander revival attempt. It adds Chernarus supervisor/workers/order execution and a Chernarus-only UpdateSupplyTruck nil guard, while maintained Vanilla remains old-shape for that supply-truck edge. Treat as branch-review evidence, not stable/release truth; smoke dedicated/JIP/Vanilla before calling AI commander revived.

AI Delegation

WFBE_C_AI_DELEGATION controls delegation:

  • 0: disabled
  • 1: client-side AI creation/delegation
  • 2: headless client

Source anchors: Rsc/Parameters.hpp:50-53 exposes the mission parameter; Common/Init/Init_CommonConstants.sqf:93-100 defines the default delegation mode and client-FPS thresholds. initJIPCompatible.sqf:155 forces HC mode for the fork, while initJIPCompatible.sqf:164-170 downgrades HC mode to disabled when the detected OA build lacks HC support.

Server functions Server_DelegateAITownHeadless.sqf, Server_DelegateAIStaticDefenceHeadless.sqf and Server_FNC_Delegation.sqf are the core delegation hooks. Client handlers Client_DelegateAI.sqf, Client_DelegateTownAI.sqf and Client_DelegateAIStaticDefence.sqf receive delegated work through Client/PVFunctions/HandleSpecial.sqf:13-15.

Page ownership: this atlas owns AI/performance runtime orientation and source routing. The implementation patch shape, work-record model, disconnect policy and DR-21/DR-42 decisions live in Headless delegation and failover. Older upstream branch evidence for typed HC routing, side-less PVF filtering, wrong-name errors and generated mission-slot drift lives in HC upstream history and lessons.

Confirmed finding cross-links: Deep-review findings DR-21 covers HC disconnect/no failover, DR-42 covers static-defense HC one-way delegation / missing update-back, and DR-45 covers town-AI vehicle despawn deleting vehicles with player passengers. Treat those as the canonical finding records and use the linked playbooks for patch shape. For AI commander/autonomous logistics revival decisions, use AI commander autonomy audit.

Terminology warning: current docs use "HC" for headless-client delegation, but the source also contains a separate Arma high-command UI path. Client/FSM/updateavailableactions.fsm:47 initializes _hc_enabled = false, and the only HCSetGroup add path is gated by that flag at :115-117; no current source assignment was found that flips it true. Cleanup still removes high-command groups when commander state changes (Client/FSM/updateclient.sqf:204,228). Do not confuse this inert high-command UI ownership path with live headless-client AI creation/delegation.

HC timing caveat: docs/source HEAD@55cb55e2170f keeps the old simple HC bootstrap (Headless/Init/Init_HC.sqf:12 sleep, :15 connected-HC notify). Current stable/B74.1 and current B74.2 still sleep for 20 seconds at Headless/Init/Init_HC.sqf:14, then run the bounded reseat-to-civilian poll, park the HC body in the deadspawn ring, re-announce on mission-restart re-grabs, and send ["RequestSpecial", ["connected-hc", player]] at :122 or :129. The server sets serverInitFull = true later at current-stable Chernarus Server/Init/Init_Server.sqf:824 / Vanilla :818 and current-B74.2 source Chernarus :837, so HC registration is not protected by a real full-server barrier. Treat HC startup bugs as lifecycle issues too; the canonical wait-chain view is Lifecycle wait-chain.

Boyle's second-pass autonomy review clarified the split between real AI plumbing and missing autonomy:

Area Source status Notes
AI commander constants/state Branch-scoped. Docs/source has constants/state/funds and a reset-only wfbe_aicom_running path, while current stable/B74-shaped refs add a maintained-root side supervisor. Do not use docs/source-only state as proof of current stable behavior, and do not use current-stable supervisor presence as release-complete smoke evidence.
AI commander upgrade worker Branch-scoped. Docs/source compiles WFBE_SE_FNC_AI_Com_Upgrade at Server/Init/Init_Server.sqf:48, but the checked docs/source maintained roots still have no visible AICOM scheduler. Current stable/B74-shaped refs compile the worker at Chernarus Init_Server.sqf:62 / Vanilla :56 and the supervisor calls it at AI_Commander.sqf:288. Patch-status claims must name the target branch. Old docs/Miksuu/perf worker debt and current B74-shaped scheduler behavior are different states.
AI buy worker Branch-scoped. Docs/source/Miksuu/perf compile AIBuyUnit but have no checked maintained-root Spawn AIBuyUnit caller. Current stable/B74-shaped refs call it from AI_Commander_Produce.sqf:320 for AI-team production. This is not player-buy authority; the player buy flow remains client-local unless a separate server-owned purchase path is proven.
AI commander run flag Branch-scoped. Docs/source only resets wfbe_aicom_running in init/commander handoff paths. Current stable/B74-shaped refs set it as the full-command latch at AI_Commander.sqf:161 and clear it at :339 / Vanilla :338. wfbe_aicom_running means "full-command AICOM active", not simply "a commander brain exists"; detailed wording lives in AI commander autonomy audit.
Team wfbe_autonomous flag Partial order-state flag. Common_SetTeamAutonomous.sqf:8 only replicates state; source-visible consumers are command-menu toggles, commander-loss cleanup and AI respawn order-reset logic. Do not treat this variable name as proof of live independent team command. Detailed wording lives in AI commander autonomy audit.

Canonical revival/readiness detail lives in AI commander autonomy audit, including the mission-parameter/fallback-default distinction, the current stable/B74-shaped supervisor route, the broken UpdateSupplyTruck / missing supplytruck.fsm path, and historical branch-only origin/feat/ai-commander head c20ce153 context. Earlier 4dba060e evidence is a historical sub-piece of that branch, not the current head.

Commander Team Order Variables

The command menu has three different order-like surfaces, and they should not be collapsed into one working system:

Surface Current proof Development implication
Team properties Live PVF path. The client sends RequestTeamUpdate from GUI_Menu_Command.sqf:425-428; the server handler applies behavior/combat/formation/speed to selected groups or the side teams at Server/PVFunctions/RequestTeamUpdate.sqf:3-25. This is a real server-side effect, but still a high-trust registered handler that needs sender/role validation before public-server hardening.
Map orders (towns, MOVE, PATROL, DEFENSE) The command menu writes replicated group variables via SetTeamMoveMode / SetTeamMovePos (GUI_Menu_Command.sqf:252-306; setter writes at Common_SetTeamMoveMode.sqf:8, Common_SetTeamMovePos.sqf:8). Static source search found no general server loop that consumes wfbe_teammode + wfbe_teamgoto and dispatches AIMoveTo / AIPatrol / AITownPatrol; reads are UI display and AI-respawn reset (AI_SquadRespawn.sqf:105-109, AI_AdvancedRespawn.sqf:120-124). Treat commander map-order execution as unproven until Arma smoke or a dynamic caller proves it. Do not use these variables as evidence of a server-owned order queue.
Command tasks The SetTask client PVF is registered and implemented (Init_PublicVariables.sqf:33; Client/PVFunctions/SetTask.sqf:1-35), but the command menu send calls are commented at GUI_Menu_Command.sqf:335-337,343. Visible/dormant UI. Revive or hide deliberately; do not document task assignment as working.

The waypoint helpers themselves are real, but their static callers are support/resistance paths: paratrooper/para-ammo/para-vehicle support calls AIMoveTo, and resistance can call AIWPAdd / AIPatrol (Server/Support/Support_Paratroopers.sqf:92,122; Server/Support/Support_ParaAmmo.sqf:38,96; Server/Support/Support_ParaVehicles.sqf:39,78; Server/AI/AI_Resistance.sqf:14-16). That proves the helper family, not the commander map-order executor. Resistance also bypasses the west/east CanUpdateTeam/UpdateTeam gate (Server/AI/AI_Resistance.sqf:7-16), so keep resistance behavior separate from commander-team autonomy when writing docs or code.

Legacy AI order notes from the 2026-06-04 scout:

  • Server/AI/AI_TLWPHandler.sqs:9-31 still exists and teleports stragglers toward a team leader, but no static Chernarus caller or compile reference was found. Treat it as a legacy/orphan candidate unless a dynamic caller is proven.
  • Server/AI/Orders/AI_WPAdd.sqf:35-36 can apply waypoint scripts/statements, but current static callers pass empty script/statement values (AI_MoveTo.sqf:21; AI_Patrol.sqf:32,37; AI_TownPatrol.sqf:64,69; AI_Resistance.sqf:14). No current client/network-controlled path to those statement strings was found in this pass.
  • The water-avoidance loops in AI_Patrol.sqf:27 and AI_TownPatrol.sqf:51 are capped at 20 retries on master (while {surfaceIsWater _pos && _wtr < 20} do with _wtr = _wtr + 1 inside) and fall back to the town/destination centre position when still in water after 20 attempts. This is not an open uncapped-loop finding on master; verify any branch that modifies these files before re-opening it.

Town AI

Town AI is centralized through Server/FSM/server_town_ai.sqf. The server starts it once globally when defenders or occupation are enabled at Server/Init/Init_Server.sqf:513-514. Server_GetTownGroups, Server_GetTownGroupsDefender, Server_SpawnTownDefense, and Server_ManageTownDefenses are compiled at Server/Init/Init_Server.sqf:49-60.

Source anchors: docs source server_town_ai.sqf:11-19 loads range, inactivity and delegation settings; :35-51 owns the global loop and performance timing; :157-179 switches between client delegation, HC delegation and server fallback; :205-219 deletes inactive town groups/vehicles. Current stable line-drifts the HC-mode switch to server_town_ai.sqf:242-248, active-side static-defense manning to :262, and inactive vehicle deletion to :299-315.

The town-AI model is spawn/delete and delegation bookkeeping, not engine simulation caching. Preserve the active/delegated vehicle registries and cleanup checks when optimizing this loop; do not remove scans or cache state just because the loop is visible. The patch-ready risk is the incomplete player-occupancy test in docs source server_town_ai.sqf:211-216 / current stable :308-311, not the existence of the scheduled loop itself.

Player AI Watchdog

Client_WatchdogPlayerAI.sqf and Client_RecoverPlayerAI.sqf are client-side resilience systems for AI units in player groups. They check locality, alive state, vehicle validity, movement destination quality and recovery cooldowns.

Depth scout note: the automatic watchdog is intentionally conservative. Current source sets a 120 second recovery cooldown and a 50m minimum destination distance in Client_WatchdogPlayerAI.sqf:69-70, skips units with an intentional STOP order at :203-207, and records Player_AI_Watchdog_Last_Recovery at :308. Client_RecoverPlayerAI.sqf:104-112 uses a much lower 2m threshold for manual recovery, while comments at :12-14 and :224-225 explain that DoNotPlan can still be a usable movement state when expectedDestination exists and is far enough away. Do not "simplify" these paths into one stuck-AI test without Arma smoke.

Performance Audit

The mission writes structured [Performance Audit] RPT lines through PerformanceAudit_Record / PerformanceAudit_Run. The analyzer in Tools/PerformanceAuditAnalyzer converts RPT lines into CSV, Markdown, HTML and Word-friendly reports.

Instrumented areas include:

  • client marker loops: updatetownmarkers, updateteamsmarkers, updatesalvage;
  • client RHUD;
  • combat marker blinking;
  • updateavailableactions;
  • AFK update loop;
  • player AI low gear manager;
  • town AI delegation and fallback views in the analyzer;
  • cleanup/restorer focused reporting.

Runtime Optimizations Already Present

  • RHUD caches controls, text and colors to avoid rewriting unchanged UI every second.
  • Team and town marker loops include local caches and audit counters.
  • Common marker helper loops (Common_MarkerUpdate.sqf and Common_AARadarMarkerUpdate.sqf) also use cached marker state and should remain measurement-led.
  • Delegated town AI avoids some global per-unit init work by passing the non-global creation path through Client_DelegateTownAI.sqf and Common_CreateTownUnits.sqf; this is a current-Wasp optimization over the old embedded delegation path, not a regression.
  • Volumetric clouds are force-disabled because of FPS/stutter cost with skipTime.
  • Day/night sync uses small client-side skipTime steps, server date broadcasts and hard sync only for excessive drift.
  • Anti-stack loops can be disabled by mission parameter for controlled audits.
  • Server cleaners/restorers split cleanup work into dedicated loops.

Server FPS

This gateway only records where server-FPS evidence lives. Detailed publisher shape, branch drift and hosted/listen busy-loop status belong to Server gameplay runtime atlas and Hosted server FPS loop sleep.

Question Owner route
Which target branch has one publisher, two guarded publishers or two old unguarded publishers? Server gameplay runtime atlas, Hosted server FPS loop sleep
Which FPS value feeds RHUD/status surfaces and which publisher lacks an obvious current source consumer? Hosted server FPS loop sleep, Performance opportunity sweep
What smoke proves dedicated publishing and hosted/listen no-spin behavior? Testing workflow, Source fix propagation queue

Performance Caveats

  • Do not compare client and server audit rows as if they measured the same impact.
  • Public-variable storms can cause more harm than local scheduled work.
  • Treat long monitoring rows with sleeps/database waits differently from CPU-heavy loops.

Delegation And Caching Internals

Claude's review sharpened several assumptions about AI performance and HC behavior. Paths are relative to Missions/[55-2hc]warfarev2_073v48co.chernarus/.

Town AI Is Spawned And Deleted

Town AI is not simulation-cached. enableSimulation false is used on invisible town logic entities in mission.sqm, not as the town AI cache. The active mechanism is Server/FSM/server_town_ai.sqf:

  • Spawn: nearby "Man", "Car", "Motorcycle", "Tank", "Air" and "Ship" entities inside 600 * detection_coef wake a town; Air-class entities are included in the scan but filtered by unitsBelowHeight 20, so only aircraft below 20 m altitude activate towns — high-altitude flyovers do not.
  • Despawn: after time - wfbe_inactivity > WFBE_C_TOWNS_UNITS_INACTIVE with no enemies, units and groups are deleted.
  • Confirmed DR-45 risk: the vehicle cleanup in docs source server_town_ai.sqf:191-223, especially :211-216, and current stable server_town_ai.sqf:305-311 iterates wfbe_active_vehicles and deletes each alive vehicle when !(isPlayer leader group _x). It does not check crew, cargo or turret occupants, so a player riding in a town-AI vehicle while not group leader can still be inside a vehicle that gets deleted. This is separate from Server_HandleEmptyVehicle.sqf:26-30, which has its own empty-vehicle wait and is not the source of this bug. See Town AI vehicle safety for the source chain, patch shape and validation gates.

HC Delegation Source Router

There is no setGroupOwner in the mission. HC mode uses remote creation: the server sends delegate-townai, delegate-ai or delegate-ai-static-defence, and the headless/client receiver creates the units locally. Keep detailed patch decisions in Headless delegation and failover; use this table to find the live source path.

Topic Source anchors Canonical patch guide
HC bootstrap and registration Docs source initJIPCompatible.sqf:237-238, Headless/Init/Init_HC.sqf:4-15, Server_HandleSpecial.sqf:117-128; current stable/B74-shaped source Chernarus initJIPCompatible.sqf:291-292, Headless/Init/Init_HC.sqf:94-129, Server_HandleSpecial.sqf:406-431; maintained Vanilla line-drifts the dispatcher to initJIPCompatible.sqf:275-276. Headless delegation and failover
Town AI HC path Current stable server_town_ai.sqf:242-248; Server_DelegateAITownHeadless.sqf:22-56; Client_DelegateTownAI.sqf:29-44; Server_HandleSpecial.sqf:86-115 Headless delegation and failover
Static-defense HC path Current stable Server_OperateTownDefensesUnits.sqf:55-67; Server_HandleDefense.sqf:19-24; Server_DelegateAIStaticDefenceHeadless.sqf:21-28; Client_DelegateAIStaticDefence.sqf:25-39 Headless delegation and failover
Player-client FPS delegation trust updateavailableactions.fsm:121-125; Server_HandleSpecial.sqf:75-83; Server_OnPlayerConnected.sqf:68-70; Server_FNC_Delegation.sqf:153-158 Headless delegation and failover
Arma high-command UI group add path updateavailableactions.fsm:47,115-117; updateclient.sqf:204,228 Inert unless _hc_enabled is deliberately revived.
Disconnect and late-HC behavior Server_OnPlayerDisconnected.sqf:22-29; initJIPCompatible.sqf:155,164-170 Headless delegation and failover

Runtime caveats: HC mode can be forced at initJIPCompatible.sqf:155, then downgraded once during init if the OA build lacks HC support (initJIPCompatible.sqf:164-170). The current mission has no visible failover/rebalancing pass on HC disconnect and no late-HC rebalance pass. DR-21 and DR-42 track those as implementation findings; this atlas only routes readers to the live code.

GetSleepFPS Is Intentional

Common/Functions/Common_GetSleepFPS.sqf:5-9 returns shorter sleeps when FPS drops. In Server/FSM/updateresources.sqf:74-75, that means the economy loop tries to avoid income stalls during lag, at the cost of doing more scheduled work while the server is already stressed. Treat it as a design tradeoff, not an obvious bug.

Continue Reading

Previous: Supply heli PR #1 | Next: HC delegation/failover

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

Sidebar

Clone this wiki locally