# Optional native flight input observations

Run the existing Core powered-flight case with `--flight-input-diagnostics` to
append `-errFlightInputDiag 1`. Without that flag the new observations stay off.
All code is WORKBENCH-only and uses the existing exact owned pilot/aircraft
authority checks. It does not change controls, AI ownership, input bindings,
settings, collective mode, rotor signals or the flight outcome.

The fixture owns one native `OnApplyControls` hook which calls vanilla first, then
its exact-pilot `ApplyPilot` method. The optional observer overrides that probe
method: it snapshots the native context before this callback's final writes,
calls the normal implementation once, and captures immediate readback only if
that call actually wrote. It does not add another native hook or integrate the
controller a second time. Preparation is observed separately by the fixture.
Existing two-second telemetry gains at most 120 batches of three lines:
sequence/age, before-write and written inputs, and native rotor signals plus
autohover and collective mode.

`writtenFRA` and `beforeWriteFRA` contain cyclic-forward, cyclic-aside and
anti-torque in that order. `beforeWriteSequence` identifies the most recent
previous write when the next native Apply callback began; the final written
sequence normally advances afterward. These observations reveal native changes
between callbacks, but neither snapshot by itself proves downstream force
application. A callback count of zero or age -1 means no observation. There are
no pass/fail assertions or control writes in this optional diagnostic file.
The flight fixture's mandatory, flag-independent positive rotor-signal gate is
described in [the flight experiment](native-powered-flight.md).

Installed source confirms:

* `SCR_CharacterControllerComponent.OnApplyControls(IEntity owner, float timeSlice)`
  at `scripts/Game/Character/SCR_CharacterControllerComponent.c:579`, matching
  the native declaration at `generated/Components/CharacterControllerComponent.c:474`.
* `BaseVehicleControllerComponent.GetSignalsManager()` and helicopter
  `GetAutohoverEnabled()`/`GetCollectiveMode()` are real getters.
* `SignalsManagerComponent.FindSignal` returns -1 when absent;
  `GetSignalValue` returns0 on an invalid index, so the helper checks the index
  and prints `missing` instead. No signal is added or assigned.
* Stock `Mi8_base.et:878–891` connects native `MainRotorCollective`,
  `MainRotorCyclicForward`, `MainRotorCyclicAside`, and `TailRotorCollective`
  signals to its rotor animation variables. Those exact names are observed.

These signals are stronger downstream observations than an immediate input
setter/getter equality. They still do not establish a documented numeric mapping
from input to physical thrust, guarantee same-frame simulation ordering, or prove
the simulation applied the expected force. The native APIs do not document that
mapping or callback ordering sufficiently for those claims. Existing actual
motion, RPM, fuel and contact assertions remain necessary. An autohover=true
sample discloses another active controller; the diagnostic never toggles it.

Four local source/runner checks pass without launching the engine or audio.
The earlier observer compiled and exposed real input overwrites in 100422/101342; the revised before-write/final-write observer awaits its next source-bound native run. A native
failure must remain a failure; these observations neither filter errors nor
convert missing signals into zeros or successful flight evidence.

With experimental `-errFlightActionInputs 1`, the observer also wraps the fixture's
owned `PreparePilotActions` once. The written collective/FRA snapshot is the
actual directional ActionManager readback; throttle is only a contemporaneous
native observation, not an injected throttle action. The before-write snapshot
still comes from native Apply and therefore shows the derived context after
normal collection. Diagnostic code adds no action or control writes. The base
fixture's selected writer and mandatory proof do not depend on this flag.