docs/re: mark the 'targeting is automatic' section superseded

It concluded no target-select input exists because no single press cycled a
target; select is A pressed twice. Kept with a correction banner rather than
deleted — a probe that never performs the action will 'prove' the action does
not exist, which is the reusable warning.
This commit is contained in:
claude-re
2026-07-30 20:48:15 +00:00
parent 4821ba7fea
commit 695351dfc4

View File

@@ -13,12 +13,16 @@ Evidence: [`captures/fire-probe-ammo-counters.png`](captures/fire-probe-ammo-cou
| **d-pad** | **Tactical map** overlay (grid with contact blips) — not target cycling | 🟡 | | **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") | | `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 ## ~~Targeting appears to be automatic~~ — WRONG, corrected below
No input was found that cycles a target. The green `TARGET` marker is already present in > **Superseded.** This section concluded targeting was automatic because no input
idle frames with nothing pressed, so the game selects for us — most likely whatever sits > cycled a target. It is wrong: the HUD tutorial states target select is **Ⓐ pressed
nearest the reticle — and a guided missile's lock is then a **time-on-target** mechanic > twice**, and every sweep here tapped once. Kept because the reasoning is a useful
rather than a button. > warning — a probe that never performs the action will "prove" the action does not
> exist. The rest of the section's measurements stand.
No *single* press cycled a target. The green `TARGET` marker is already present in
idle frames with nothing pressed, which I read as the game selecting for us.
That fits the measurements end to end: That fits the measurements end to end:
@@ -29,12 +33,9 @@ That fits the measurements end to end:
- the pilot's own log shows aim error wandering between ~10° and ~40° for most of a - the pilot's own log shows aim error wandering between ~10° and ~40° for most of a
pass. pass.
So the remaining bottleneck is **not** the target choice (escort weighting), **not** the At the time I concluded the bottleneck was aim dwell. Partly right — target
ballistics (now taken from the confirmed `Shell` records), and **not** the input mapping **commitment** did take kills 2 → 9 — but the larger cause was simply that no target was
(measured above). It is that the steering loop never holds the nose on one contact long ever selected, so the guided missiles had nothing to guide to.
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.
## The game's own action list (from the OPTIONS key-config screen) ## The game's own action list (from the OPTIONS key-config screen)