3.8 KiB
Initial guard population readiness
In native log logs_2026-09-19_06-59-35, the last site group was authored at 07:00:21.170, the mission entered prison at 07:00:21.266, and the patrol fixture required a living outpost actor at 07:00:22.216. The old preparation checked the group entity's faction but never its members.
Installed vanilla SCR_AIGroup.EOnInit (line 2578) requests the configured slot count through RequestSpawn (2684), which delegates to native ChimeraAIWorld.EnqueueSpawnRequest. Installed source describes capped, frame-time-aware dispatch at 2 Hz. ExpandOneMember (2725) creates one soldier per successful dispatch; SpawnGroupMember may also wait for streamed navigation tiles, with a 30-attempt fallback. Therefore a valid group entity/faction does not establish physical squad readiness. The source does not establish the exact native queue throughput in this run; native diagnostics must measure it. The successor AI addon contains no site-population call in HQ registration; Core does not depend on it to spawn guards.
The successor now records each chosen group's public m_aUnitPrefabSlots.Count() once during initial creation. Empty/manual-only profiles fail clearly. Preparation waits up to 90 seconds for exactly that many distinct physical controlled entities, all conscious with the configured enemy faction, and native IsExpandComplete(). Stock insertion proceeds while guards are pending and retains its separate 15-second deadline. Count changes are logged, and a timeout reports the requested/physical/conscious counts, native completion state, navigation-tile status and dormant counts before ordinary rollback. A missing group, invalid count or foreign faction fails without waiting indefinitely.
The successor never calls SpawnUnits, SpawnMembers, ExpandOneMember or RequestSpawn to retry this population. Once the site service is READY, the existing early return prevents this check from running again. Casualties and depleted groups are not restored. A stopped or failed PENDING preparation explicitly purges only its owned groups' initial native requests before rollback; vanilla DespawnMembers otherwise returns early when a group is empty, before its own queue purge.
The patrol fixture performs its authoring/route checks once, then allows up to 15 seconds for the existing group actors to be observable. It asserts six distinct physical conscious guards for each current Everon patrol profile before observing movement. It creates no replacement soldiers. Its outer Core fixture budget must include the initial 90-second preparation plus this wait and the existing 180-second route deadline; integration uses 330 seconds for patrols only.
Source hashes are in guard-source-hashes.json. The source-policy regression covers incomplete groups, missing consciousness/native completion, excess members, invalid profiles and strict timeout failure. Native queue timing, full group arrival, navigation traversal, startup-failure cleanup and no refill after casualties still require engine runs.
Native run native-2026-09-19-070919 observes all six original squads completing six distinct conscious actors before PRISON. The full patrol fixture passes 295 combined assertions with zero engine or script errors. Count-change logs establish asynchronous initial population without another spawn request. Timeout/cancellation logic is source-checked; this successful run does not exercise engine cancellation of a queued failed preparation.
Native cancellation now passes in 073601: 68 assertions, no engine/script errors. Empty and partial groups remain stable through a fifteen-second observation while the uncancelled control fills. Owned rollback deletes all captured actors/groups, and the original mission groups remain unchanged.