From 9352e079bf57ce7f3d0e98f065ee86ab722e0787 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 13:11:52 +0000 Subject: [PATCH] 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. --- docs/re/mission-phase-membership.md | 43 +++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/re/mission-phase-membership.md b/docs/re/mission-phase-membership.md index dccb4d6..847bcf4 100644 --- a/docs/re/mission-phase-membership.md +++ b/docs/re/mission-phase-membership.md @@ -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.