fabi/Syplheed-Reborn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re(flight): the afterburner is not on A/B/X/LB/LS/RS — bounded negative, with a cheap HUD oracle

Browse Source 
The definition describes the burner (AB_ConsumeShield_Begin 50, AB_ConsumeShield 10,
AB_AV_* turn caps well below normal) but names no input, and carries no AB velocity
field.

Three probes, all negative for A, B, X, LB (plus LS/RS on the first):
- ab_probe.py: hold RT for a max-speed baseline, then each candidate — speed stayed
  inside the baseline's own noise band every time.
- ab_state_probe.py: sample a window of the player object during each hold and
  report any float that falls — nothing fell.
- HUD oracle needing no offsets: count green pixels of the SHIELD bar on a freshly
  spawned craft. AB_ConsumeShield_Begin 50 should take a visible bite; the bar read
  156/156/156/157/157 across baseline and all four buttons.

So the burner needs a chord, an input this pad cannot reach, or belongs to another
craft/the AI. Recorded so the obvious buttons are not re-probed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NptfmpjdpNCKEez6d2xvA9
This commit is contained in:
Claude (auto-RE)
2026-08-13 15:51:32 +00:00
parent 86fcfcc8b0
commit fb1405b13f
3 changed files with 149 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/flight-speed-law.md
View File

@@ -100,3 +100,34 @@ pitching — but the yaw fields may equally belong to the AI or to an input this
has not driven.
Raw samples: [`captures/turn-law-pitch-phases.csv`](captures/turn-law-pitch-phases.csv).
---
# The afterburner is not on the obvious buttons — a bounded negative
The definition describes the burner without naming its input: `AB_ConsumeShield_Begin`
**50**, `AB_ConsumeShield` **10**, and a set of `AB_AV_*` turn caps far below the
normal ones (roll 40 vs 125–200 °/s, pitch-up 30 vs 70–150). Notably there is **no
`AB_*Velocity`**, so the burner may not raise the speed target at all.
Two independent probes, both negative for `A`, `B`, `X`, `LB` (and `LS`/`RS` on the
first):
* [`tools/re-capture/ab_probe.py`](../../tools/re-capture/ab_probe.py) — hold `RT`
for a max-speed baseline, then hold each candidate: speed stayed inside the
baseline's own noise band (1 200–1 580 units/s) for every one.
* [`tools/re-capture/ab_state_probe.py`](../../tools/re-capture/ab_state_probe.py) —
sample a window of the player object while each candidate is held and report any
float that falls during the hold: **nothing fell**.
* And the cheapest oracle of the three, needing no offsets at all: **count the green
pixels of the HUD's SHIELD bar** before and after each hold, on a freshly spawned
craft with a full shield. `AB_ConsumeShield_Begin 50` should take a visible bite;
the bar read **156, 156, 156, 157, 157** across baseline and all four buttons.
So the burner is **not a simple hold on `A`/`B`/`X`/`LB`/`LS`/`RS`**. What remains:
a chord (something plus `RT`), an input this pad cannot reach, a craft variant that
has it, or fields that belong to the AI rather than the player. Worth knowing before
anyone re-probes the obvious buttons.
(`RB` is the nose gun, `Y` the missile mount and the d-pad the tactical map — see
[flight controls](flight-controls-runtime.md) — so those were not held here.)