Validate independent packed addons and complete physical mortar salvos

docs/native-powered-flight.md

@@ -78,3 +78,51 @@ The staged correction keeps native `OnPrepareControls` only as an exact-owned pi
 After native RPM/fuel proof, a new at-most-three-second stage requests 0.05 collective with zero cyclic/anti-torque. Before any climb it requires fresh real apply callbacks and the existing `MainRotorCollective` signal to agree with the nonzero request on distinct fixture ticks spanning at least 500 ms. Missing signals or continued zero values fail; no signal is created or assigned. Engine, drift, height, tilt and callback freshness checks remain active in this stage. The proof does not depend on the optional diagnostics flag. All later physical hover and contact-landing checks remain required. The overall 240-second bound remains unchanged.
 
 Optional diagnostics now observe native input at the start of Apply before this callback's final writes, then capture the final immediate write readback. These two snapshots are explicitly labelled `beforeWrite`/`written`; neither is alone called downstream consumption proof. Existing rotor signals and the mandatory positive gate provide the later observation. The optional file no longer adds a second native OnApply override, preventing hook-chain ordering from obscuring the comparison. This revision has local source/policy checks only until its next native run.
+
+## Actor-local action experiment after 102235
+
+The 10:22:35 run compiles the Apply-callback revision and again passes single-pilot seating, complete footprint and real engine/RPM/fuel checks. Its mandatory positive gate then fails: five distinct observations report requested collective 0.05 but existing rotor signal zero, with 15, 30, 45, 60 and 75 real writes. The next Apply callback sees native input reset to zero. This is no demonstration of consumed flight controls, hover or landing. The rotor signal is an authored animation input, not a documented thrust sensor or guaranteed exact transfer function; its refusal preserves this experiment's limits rather than proving scripting flight impossible.
+
+A separate experimental `-errFlightActionInputs 1` mode is now available. The default retains the failed Apply-context writer for comparison. The experiment uses the supplied, exact pilot-local `ActionManager` in `OnPrepareControls`, before native `super`, following installed `SCR_CharacterControllerComponent_Test.c:9–13`. It requires that manager to equal the actual pilot agent's manager and differ from the global InputManager; the global object is read only for rejection, never mutated. Shared/missing managers fail. Only this owned manager's `HelicopterContext` is briefly activated using the installed duration1 pattern.
+
+The exact configured actions are HelicopterCollectiveIncrease/Decrease, HelicopterCyclicForward/Back, HelicopterCyclicRight/Left and HelicopterAntiTorqueRight/Left. The fixture writes bounded nonnegative directional values and explicitly zeros the opposite action. Signed-to-collective encoding and control gains remain experimental; the config does not document final Direct-mode mapping. The selected mode is immutable during the run: the Apply writer returns immediately in action mode, and the action writer returns immediately in default mode. Both share one demand calculation; the integrator executes once per selected native callback. No engine, brake or autohover actions are injected.
+
+On Stop, only the same owned, unclaimed manager receives zeros for these eight actions. The short context activation expires without further refresh; the duration parameter's units are not claimed. Capture/life/seat/authority checks and the mandatory <=3s positive rotor-signal proof remain unchanged, as do all footprint, fuel, height, tilt, drift, hover and landing bounds. Optional diagnostics distinguish actual virtual-action readbacks from native input at Apply and the existing rotor signal. Action mode observes throttle but does not write it. This branch is source-checked only until native compilation and consumption are observed.
+
+The 104048 actor-manager test compiles but fails before engine start. The 104256 diagnostics show the exact owned manager's context is already active while ActivateContext returns false on four callbacks; requiring the undocumented return value incorrectly prevents all action writes. The revised path checks whether the context is already active, attempts activation only when inactive, and requires the observed active state. It never deactivates a preexisting native context. This corrects the fixture's activation assumption; action readback, native consumption and all physical bounds remain independently required.
+
+The 105226 motion run again takes off and fails at8.00134m drift after reaching6.8385m. Rearward velocity is already reversing before refusal. The next bounded experiment changes only outer-loop velocity damping from0.3 to0.6; position0.08, attitude0.8, angular damping0.3, cyclic0.15 and all physical limits remain unchanged. A simplified acceleration model suggests less overshoot, but native lag must be tested. Measured acceleration follows the fuselage-up estimate much more closely than the transformed static rotor axis in these samples; no hardcoded/native-axis trim is justified from that diagnostic alone.
+
+An installed-API/source review after105709 finds a concrete heading feedback bug: IEntity.GetAngles returns rotations aboutX/Y/Z, while GetYawPitchRoll returns named yaw/pitch/roll order. The fixture incorrectly read GetAngles()[0] as yaw in both capture and feedback. Both now use GetYawPitchRoll()[0], retaining action signs and all gains/bounds from the0.6 damping experiment. Vanilla SCR_HelicopterCinematicFlyComponent also uses GetAngles()[1] for yaw. Read-only desired-yaw/actual-yaw-pitch-roll telemetry accompanies the correction; native stabilization still must pass.
+
+The heading correction holds observed yaw near its1.45-degree target in the next native run, confirming that pitch was the wrong feedback field. Pitch still oscillates with native angular rate reaching0.14rad/s and saturated cyclic demand. The next single-gain experiment raises pitch/roll angular-rate damping0.3→1.2, preserving the0.6 outer velocity term, position/attitude gains, yaw controller, input caps and all physical limits. This is still test-only tuning; a valid outcome requires native hover and landing, not merely improved snapshots.
+
+## Explicit native-autohover fixture variant
+
+The WORKBENCH-only probe exposes `bool SetAutohoverMode(bool enabled)`. The smoke caller selects `true` immediately after constructing its probe and **before the first `Tick`**; there is no separate probe `Start` method. A false return fails the caller's fixture configuration. Default construction retains the manual mode, including angular damping 1.2. Configuration is frozen once ticking starts, an airframe exists, the fixture binds, or the probe stops/completes. The integrated runner's explicit `--flight-autohover` requires `--project core --smoke powered-flight --flight-action-inputs`; it passes `-errFlightAutohover 1` to that Core fixture. It is off by default.
+
+The API is grounded in installed `HelicopterControllerComponent.GetAutohoverEnabled()` and `SetAutohoverEnabled(bool)`. Vanilla `SCR_HelicopterHoverAction.SetState` calls that setter, and the stock Mi8 includes the action in its autopilot context. `SCR_BaseGameMode.OnPlayerDisconnected` also enables autohover on the server to help stop an occupied helicopter gracefully. Thus the call is a real per-vehicle native feature, not a simulated controller, obsolete helper or global player-input change. Vanilla's scripted `OnPrepareControls` sets collective preferences but does not itself reset autohover.
+
+After the original single pilot is physically in its exact primary seat and all authority/fuel/health gates pass, the selected variant captures the exact controller and its prior autohover state, enables it once, and requires actual getter readback. Failed enabling is not retried. Subsequent ticks and control callbacks require that same controller and enabled state; losing the setting fails the run rather than silently re-enabling it. Periodic `ERR POWERED AUTOHOVER` telemetry records mode selection, saved state, native state and controller identity.
+
+In this mode only, custom forward/right cyclic demands are explicitly zero. The chosen actor-action or Apply-input path still writes those neutral demands normally, leaving native autohover to supply its own lateral stabilization. Collective/altitude and yaw feedback, engine startup, rotor-signal consumption proof, finite fuel use, timeouts, 8 m drift/height/tilt bounds, actual 7–9 m five-second hover, and physical-contact landing requirements remain unchanged. Autohover must coexist with those controls in a real run; the installed script API does not reveal its gains, activation envelope, altitude behavior, AI ownership details or final input composition. An enabled bit alone cannot pass any flight milestone.
+
+Stop restores the captured autohover state only while the same controller belongs to the same aircraft, the same unclaimed fixture pilot still occupies the selected primary seat, and no player has claimed or boarded it. It does not change a captured, replaced or abandoned controller. Restoration is attempted once and logged; a getter mismatch emits an explicit native smoke failure. No engine shutdown in midair, force/velocity/transform correction, fuel/health write, crew replacement, or production-aircraft change is introduced. As before, failed physical actors remain owned by the fixture for diagnosis/reset.
+
+Offline tests execute the actual configuration/readback/restore methods against explicit controller doubles, including late configuration refusal, default no-write behavior, original true/false settings, rejected native enable/restore, changed ownership/controller, idempotent cleanup and neutral cyclic behavior. These do not compile Enforce or establish native autohover effectiveness. This variant requires its own retained native result before any takeoff/hover/landing claim, and does not qualify production route flying or multiplayer behavior.
+
+
+The first native autohover trial (`112320`) compiled and confirmed the exact owned flag, but failed its unchanged pre-engine minimum-collective gate: the native controller changed the post-application collective to about -0.114 despite an action demand of zero. Its original autohover state was restored. This establishes that the native feature affects collective as well as lateral controls. The next staged variant therefore keeps autohover off through engine startup and the existing positive collective-consumption proof, then enables it immediately before the bounded climb. Native readiness is mandatory through flight and landing; no physical gate is relaxed. This delayed activation remains unverified until a separate native run.
+
+### Bounded signed actor-action experiment after 11:25:02
+
+The archived manual `112502` run retained Direct mode (3), native collective and `MainRotorCollective` zero while climbing about 0.2 m/s; it exceeded the unchanged 18 m ceiling with horizontal drift below 8 m. This is physical evidence that zero did not arrest that climb, not proof of a particular blade-pitch or thrust mapping. The earlier `112320` autohover observation of negative collective used WorldY mode (5), so it does not establish negative Direct action consumption.
+
+Installed `Configs/System/chimeraInputCommon.conf:6152–6201` defines separate `HelicopterCollectiveIncrease` and `HelicopterCollectiveDecrease` actions, each limited to 1, with opposite input directions. The generated `Vehicle/CollectiveMode.c` and `Character/CharacterInputContext.c` expose the mode/input without documenting their transfer function. The fixture's old signed-to-unipolar conversion never exercised the decrease action. Its earlier interpretation of a clamped negative Apply write was superseded by evidence that native processing also overwrote positive Apply writes.
+
+The next staged actor-action variant retains zero during initial preparation and engine startup, and retains the existing positive 0.05 consumption test. Only after that test passes does stage 10 request increase=0/decrease=0.05, with zero cyclic/torque, on the exact owned AI action manager. Within three seconds it requires Direct mode, autohover off, a running engine, fresh callbacks, negative native input and the existing rotor signal agreeing near -0.05 on distinct ticks spanning 500 ms. Signal mismatch or a missing signal fails. Interrupted observation resets the interval. This proof does not depend on optional diagnostics and does not assign a signal.
+
+Only a successful negative test enables signed actor-action demand for flight stages 4–6; the legacy Apply branch retains its old encoding for comparison. Optional native autohover is enabled after both action-path proofs. Feedback gains, initial integrator value, single-aircraft/pilot allocation, overall timeout, footprint, fuel, drift, tilt, altitude, stable-hover and contact-landing requirements are unchanged. Negative signal consumption remains an experimental question until this revision runs natively; even a successful signal test alone proves neither hover nor landing.
+
+
+Native113557 proves the signed-action hypothesis: both input and rotor signal hold -0.05, the same aircraft reaches a five-second 7–9m hover and lands with two seconds of ground stability. It then fails the immediate post-shutdown check. Inspection found stage7 returned neutral collective0 while the real rotors continued coasting; the next variant holds proven minimum pitch -1 during shutdown and records every landing predicate. No stability, geometry, timeout or damage limit changes. The failed run remains retained.