Include the current addon, terrain integrations, tools, regression tests and recorded development evidence.
4.2 KiB
Physical group readiness and optional carried intel
ERR_IntelService.RegisterGroup rolls once for each living non-player actor actually present at notification. It intentionally does not create group members or replace a document after pickup, drop or death. Its per-actor m_Rolled set and per-request accepted-spawn latch remain unchanged.
The two production group-registration paths have different initialization timing. Core ERR_SiteService.Activate already publishes groups only after complete physical preparation. Mortar preparation previously published its new native group before asynchronous crew expansion, so late members could miss the optional intel roll even at a 100% setting.
Mortar preparation now owns the group and registers/reserves it directly with HQ immediately. ERR_MortarReadiness.Poll publishes the normal mode group event exactly once, after native expansion, the original four crew, inventory callbacks and all 27 shells have been verified. Its ready latch precedes publication; subsequent polls return without publishing again. Stopped, failed or incomplete preparation does not publish. The mode's ordinary HQ registration is harmless here because HQ deduplicates the existing group. Intel remains optional and does not gate mission or support readiness; full inventories can still refuse an extra folder through its existing bounded assignment path.
tests/test_intel_registration.py executes the actual Intel registration/tick methods, HQ registration method, and the readiness method's existing early guards plus final qualified handoff with native boundaries represented by adapters. It verifies initially empty groups, later materialized members, duplicate readiness/registration, accepted asynchronous inventory operations, folder removal, death before/after assignment, original negative rolls and no duplicate HQ unit. Source-order checks require publication after the native readiness validations. Adjacent mortar transaction, activity-completion, refresh and report-ledger regressions also pass.
This is source/policy coverage. It does not establish native inventory completion, remote simultaneous carriers, or multiplayer discovery replication for this revision. The existing Chat mortar-inventory fixture now observes this handoff after its actual battery-readiness gate and before its existing shell-depletion mutation. A Workbench-only Intel accessor reports whether each exact actor belongs to the existing one-roll set. Chat requires four distinct actual crew identities and a positive latch observation for each, without changing carrying chance, registering again, rolling again, or forcing documents. This works for both positive and negative carrying decisions. Intel has no AI-addon type references and keeps its standalone dependency scope. These new assertions remain native-unverified until the next run. Successful inventory insertion is a separate outcome: capacity refusal must remain visible rather than be counted as successful carriage.
Repeated intel with larger camp populations (2026-10-12)
New generic carried folders choose among locations the team has not fully identified. Assignment selects randomly among the least-assigned eligible sites, keeping per-round counts even after a document is recovered or retired. This spreads a larger AI population across available targets and lets later generated sites receive assignments. Explicit mission documents retain their target, and previously sealed folders are never retargeted; they can still become outdated before pickup.
The team-wide duplicate-topic and fully-exhausted explanations each broadcast at most once per round, retaining the shared five-second burst limit and the separate useful-discovery queue. Additional redundant folders are still spent once by the existing recovery ledger.
The production sealing test covers 570 assignments across 57 unfinished locations, later site availability, already-identified exclusions, rough clues, fixed authored targets and repeated inventory scans. Feedback tests cover repeated notices over 100 later scans, useful discoveries, transport deduplication and a fresh round. Adjacent registration, reroll and mine-intel recovery tests pass. These are policy tests with engine boundaries substituted; in-game acceptance remains pending.