re: 936s live run -- no phase advance, and a script lose-branch GAME OVER

Polled the runtime phase mirror every 3s for 936s of hunting flight. It never
left 0, which the static work predicts rather than contradicts: ChangePhase is
only posted once the ordinal exceeds 1, so a phase-1 run never writes it. That
does make the mirror useless as a phase-1 readout -- it reads 0, not 1, and
[ScriptMission+40] needs a debugger.

The run ended in GAME OVER with the player's hull at full 1500, so a script
lose-branch fired rather than the player dying. The pilot log narrows it: the
tracked asset fell from 100.8% to 23.4% with ASSET-HIT events, while the pilot
avoided f101_TCAF_Acropolis 2588 times. 'Escort lost' is a measured candidate,
not a guess -- but the asset ended at 23.4%, not 0, so the threshold (or whether
another unit's loss ended it) is not established.

Two runs now (530s, 936s) and no phase advance observed. Since phase 1 polls
unit_state on ADN110/111/112 and the pilot hunts whatever is nearest rather than
the objective, biasing it at those squadrons is the next step.

Refuted: sub_8226D740 does NOT read the flag file. Its three addi rN,r31,120 are
fields of a local trigger-record buffer passed to sub_8226E220 as out-params;
the phase lives in r26/r29. Offsets 88 and 120 are too common image-wide (2091
and 5228 instructions) to isolate the register files by offset search, so what
reads the flags is still unknown and the set_flag -> END_PHASE chain has a gap.
This commit is contained in:
Sylpheed RE agent
2026-08-25 13:11:52 +00:00
parent 81e9267e31
commit 5b2a719675

View File

@@ -133,3 +133,46 @@ executable, not the data.
36 members, Σ`n` 115 (≈230 in probe units).
* `TCN207`, `TCN208` and `TCS252` may **fail to arrive** in phase 2, because
their routes are misnamed.
## 🟡 2026-08-25 — first long live observation: no phase advance, and a GAME OVER
Flew Stage 02 with an actively hunting pilot for **936 s** while polling the
runtime phase mirror `[*(0x828F35F8) + 236]` every 3 s (`phase_probe.py`).
**The mirror never left 0.** That is what the static work predicts rather than a
contradiction: `CScriptInterpreter::ChangePhase` (opcode 995) is only posted when
the ordinal is **> 1** (the guard in mission-bytecode opcode `0x83`), so a run
that stays in phase 1 never writes the mirror. It does mean the mirror is
**useless as a "which phase am I in" readout for phase 1** — it reads 0, not 1.
`[ScriptMission+40]` is the real counter and needs a debugger.
**The run ended in `GAME OVER`** — and the pilot's hull was still **1500/1500**,
so the player did not die. A **script lose-branch fired**, and the pilot log says
which one is likely: the tracked **asset fell from 100.8 % to 23.4 %**, with
`ASSET-HIT` events logged, while the pilot repeatedly `AVOID`ed
`f101_TCAF_Acropolis` — a friendly capital ship — 2588 times.
So the escort was being destroyed throughout, and the mission failed with the
player untouched. **"Escort lost" is now a measured candidate rather than a
guess**, though the final asset value was 23.4 %, not 0, so the exact threshold
(or whether a different unit's loss ended it) is **not** established.
**So a phase advance still has not been observed.** Two runs now — 530 s and
936 s — neither reached phase 2. Combined with the static reading that phase 1
polls `unit_state` on **ADN110/ADN111/ADN112**, the likeliest explanation is that
those three squadrons were never destroyed; the pilot hunts whatever is nearest,
not the objective. **Next: bias the pilot at those squadrons' craft and re-run.**
## 🔴 Refuted: `sub_8226D740` does not read the flag register file
Chasing what *reads* the 32-entry flag file at `[phase+120]`, the promising hit
was three `addi rN, r31, 120` inside `sub_8226D740`, the per-frame engine→script
trigger edge. **It is not the flag file.** In that function `r31` is a local
**trigger-record buffer** whose fields are handed to `sub_8226E220` as
out-parameters (`+80, +84, +88, +92, +112, +120`), and `lfd f1,120(r31)` reads a
`double` from the record. The phase is in `r26`/`r29`.
Offsets 88 and 120 are far too common (2091 and 5228 instructions image-wide,
mostly stack frames) for an offset search to isolate the register files.
**Who reads the flags is still unknown**, so the chain
`set_flag(8) → … → END_PHASE` has a gap in the middle.