2.9 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.