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:
@@ -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)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user