ab8f5307ff
Probed rather than assumed: hold each pad input and photograph the HUD ammo counters. RB = nose gun (NOSE BM 6000->5956 in 4 s, ~11 rounds/s, HEAT rises), Y = main mount (MAIN MPM 300->299), d-pad = tactical map overlay, and LB/X/B/A/LS/RS move neither counter. No target-cycle input exists. The green TARGET marker is already up with nothing pressed, so the game selects for us and a guided missile's lock is a time-on-target mechanic, not a button. That closes the lethality question: it is not target choice (escort weighting), not ballistics (now from the confirmed Shell records), and not the mapping — the steering loop simply never holds the nose on one contact long enough to lock. Aim dwell is the next lever. Also records two things the reimplementation needs: two weapons with separate ammo pools and HUD counters, and a HEAT bar that fills while the gun fires (cap and cool-down not yet measured).
47 lines
2.6 KiB
Markdown
47 lines
2.6 KiB
Markdown
# In-flight control mapping — measured, not assumed
|
|
|
|
**Status:** ✅ for the weapon bindings (ammo counters move), 🟡 for the rest (HUD
|
|
observation only). Probes: `tools/re-capture/fire_probe.sh` (hold each input, photograph
|
|
the ammo counters) and `lock_probe.sh` (tap each, watch the reticle). Stage 02, in flight.
|
|
Evidence: [`captures/fire-probe-ammo-counters.png`](captures/fire-probe-ammo-counters.png).
|
|
|
|
| input | effect | confidence |
|
|
|---|---|---|
|
|
| **`RB`** | **Nose gun.** `NOSE BM` 06000 → 05956 in a 4 s hold ≈ **11 rounds/s**; `HEAT` bar rises | ✅ |
|
|
| **`Y`** | **Main mount** (missiles). `MAIN MPM` 00300 → 00299 per tap | ✅ |
|
|
| **`RT` / `LT`** | Throttle up / brake, a *persistent* setting (488 → 1510 → 174 u/s) | ✅ (earlier session) |
|
|
| **d-pad** | **Tactical map** overlay (grid with contact blips) — not target cycling | 🟡 |
|
|
| `LB`, `X`, `B`, `A`, `LS`, `RS` | No change to either ammo counter | ✅ (as "not a weapon") |
|
|
|
|
## Targeting appears to be automatic, and that is the lethality problem
|
|
|
|
No input was found that cycles a target. The green `TARGET` marker is already present in
|
|
idle frames with nothing pressed, so the game selects for us — most likely whatever sits
|
|
nearest the reticle — and a guided missile's lock is then a **time-on-target** mechanic
|
|
rather than a button.
|
|
|
|
That fits the measurements end to end:
|
|
|
|
- the guns fire fine (11 rounds/s) but the kill counters read `0000` after five gun-only
|
|
runs → **we shoot and miss**;
|
|
- guided missiles (`Missile_P`, Power 200, `GuidanceType` 5) got the first kills,
|
|
`WARPLANES 0002`, but only **2 per 98 launches**;
|
|
- the pilot's own log shows aim error wandering between ~10° and ~40° for most of a
|
|
pass.
|
|
|
|
So the remaining bottleneck is **not** the target choice (escort weighting), **not** the
|
|
ballistics (now taken from the confirmed `Shell` records), and **not** the input mapping
|
|
(measured above). It is that the steering loop never holds the nose on one contact long
|
|
enough to complete a lock. The next thing worth doing is making aim *dwell* — and the
|
|
cheapest oracle for whether a lock ever completes is the reticle itself, or finding the
|
|
lock timer in the player object with the same anchoring trick used for hull.
|
|
|
|
## Notes for the reimplementation
|
|
|
|
- Two independent weapons with separate ammo pools and separate HUD counters:
|
|
`NOSE BM` (gun, 6000) and `MAIN MPM` (missiles, 300).
|
|
- The gun has a **HEAT** bar that fills while firing — a sustained-fire limit the
|
|
reimplementation needs; its cap and cool-down rate are not measured yet.
|
|
- The tactical map is a full-screen overlay bound to the d-pad and does not pause flight
|
|
(the craft kept taking fire with it open).
|