EscapistsReintroduced/docs/initial-extraction-placement.md

Initial extraction placement

Historical parked-helicopter design. The current smoke-signalled rescue validates a pickup point during preparation and allocates aircraft only after the signal; this placement owner is no longer used by normal mission preparation.

This change addresses an observed initial-placement failure, not an unloading or extraction-boundary change. In the 2026-09-19 07:34:23 native attempt, the newly spawned Mi8 was sleeping, engine off, without native landing contact. Three short wheel casts all missed the terrain. A zero velocity reading alone therefore could not establish support.

ERR_ExtractionPlacement belongs to ERR_SiteService during PREPARING. It accepts only that mode's registered, living Mi8. Once native dynamic physics and a valid helicopter simulation exist, it performs exactly one Physics.SetActive(ActiveState.ACTIVE). The native simulation then owns settling. There is no transform, velocity, impulse, engine, fuel, health or collision mutation. No readiness is accepted in the wake frame.

Preparation requires the existing strict AircraftReady predicate, actual fuel and one second of successive observations, with gaps no greater than 1.5 seconds. A failed observation restarts that interval. The first stable qualification must complete strictly before the 30-second deadline; an already READY aircraft can continue to be monitored while guards finish after that deadline. A broken observation after the deadline fails instead of opening a new settling period. Failure to establish readiness within 30 seconds uses the existing site failure/rollback path. Even after readiness first succeeds, subsequent preparation polls still check the aircraft while other initial content finishes. Stop prevents further wake/poll work. No gameplay extraction Begin condition changes; players may later fly, expend fuel, damage or lose the aircraft normally.

Diagnostic readings include all landing pivots and tire-bottom terrain gaps, short-cast support results, native-vs-entity vehicle transforms, physics activation/motion, contact and fuel. The sleeping-wheel fallback thresholds remain unchanged.

The opt-in existing casualty-service ground probe now verifies the production placement's readiness and exactly one initial wake, then reads the real mission aircraft's contact/support. Its separate airborne/tilted/moving negative aircraft remains disposable. The fixture does not wake or reposition the mission aircraft. It is neither a manual player-action test nor remote multiplayer proof.

Primary installed-source references inspected read-only:

• scripts/Game/UserActions/SCR_ToggleHandbrakeAction.c:97: vehicle physics wake uses SetActive(ActiveState.ACTIVE).
• scripts/Game/HitZone/SCR_WheelHitZone.c:223: stock component explicitly wakes sleeping dynamic vehicle physics after changes (using balanced impulses there, which this successor does not copy).
• scripts/Game/generated/Vehicle/VehicleBaseSimulation.c: public IsValid, GetWorldTransform, and landing-gear/wheel HasAnyGroundContact contract.
• scripts/Game/Components/SCR_VehicleSpawner.c: bare prefab spawning does not itself perform an explicit support readiness check.

Local validation: python3 tests/test_extraction_placement_policy.py passes actual extracted production timing policies and focused integration/source contracts. Enforce compilation and actual settling remain unverified until the parent runs the native scenario. No prior failed evidence is relabeled as passing.

SiteService owns ERR_ExtractionPlacement.c; the ground probe inspects its actual one-shot wake and readiness state. tools/check.py includes tests/test_extraction_placement_policy.py. Initial guard cancellation remains separately owned and verified.

Native observations in 074655 confirm one initial wake, actual dynamic settling, all three wheel support traces within millimetres of terrain, native contact, fuel and one-second readiness before spawning. The raised/tilted/moving negatives also pass. The full casualty case fails later on a separate fixture health setup, so this is scoped placement evidence rather than a passing complete run. The diagnostic simulation-transform query returned identity despite the correctly moving entity; it is not used for readiness or support decisions.