From 72e24acdfecb8eb178b7102a2e8cd2da82ca18b6 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 20:50:35 +0000 Subject: [PATCH] re: WITHDRAWN -- the phase-1 condition IS polled, at 5 Hz Tracing Stage 02 phase 1 by control flow (following op 12 jumps and the six conditional branches) gives the whole chain: timer5 @ 4.0s -> trigger 0x2D30 (which also does timer_set/timer_resume) -> start_coroutine at 0x2FE8 -> coroutine 0xBB9C, whose body is wait_s(0.2) ; yield -> ... -> 0xF524, the ADN110/111/112 polls that latch set_flag(8). Exactly one of phase 1's 79 coroutine entries reaches 0xF524 under a real control-flow walk, and it is a 0.2s polling loop. So the condition is checked at 5 Hz from 4 seconds into the phase, and my 'the condition coroutine is not polling' explanation -- which I had promoted to real evidence after the poke experiments -- is withdrawn. Two weaker methods gave wrong answers first and are named: linear decode fell through into unrelated code and implicated 30-odd entries; 'nearest preceding entry' implicated the right one only by proximity luck, 0x3988 bytes away. And I matched start_coroutine operands across phases at first, which is meaningless since the operand is relative to [phase+232] -- the same per-phase base trap that broke isl.py's jump targets, hit again three iterations later. The poke results now need a different explanation. The likeliest is that neither poke produced the tested state: +16 is never read by built-in 69, and +4 = 0 takes the early-exit path an UNDEPLOYED unit also takes. Recorded as a hypothesis with the experiment that would settle it. --- docs/re/script-runtime-probe.md | 42 +++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/re/script-runtime-probe.md b/docs/re/script-runtime-probe.md index dd4a36fd..99d65270 100644 --- a/docs/re/script-runtime-probe.md +++ b/docs/re/script-runtime-probe.md @@ -476,3 +476,45 @@ That leaves the third candidate: **the anomalous run's mission never loaded**, and its `IN FLIGHT` was a misdetection. Consistent with what became of it — it was **frozen on a black screen** when checked afterwards. Not proven, but it is now the only surviving explanation rather than one of three. + +## 🔴 WITHDRAWN: "the condition coroutine is not polling" + +That explanation — promoted to "real evidence" after the poke experiments — is +**wrong**. Tracing Stage 02 phase 1 by **control flow** (following op 12 jumps +and the six conditional branches, not linear decode) gives the whole chain: + +``` +timer5 @ 4.0s -> trigger 0x2D30 (timer_set(1200,180); timer_resume; set_flag(0)) + -> start_coroutine at 0x2FE8 + -> coroutine 0xBB9C : wait_s(0.2) ; builtin103 ; yield ; unit_hp_pct(TCN001,…) + -> … -> 0xF524 : unit_state(ADN110/111/112) -> set_flag(8) +``` + +**Exactly one** of phase 1's 79 coroutine entries reaches `0xF524` under a real +control-flow walk, and its body is a **`wait_s(0.2)` loop**. So the condition is +polled at **5 Hz**, from 4 seconds into the phase — the opposite of what I +concluded. + +⚠️ Two weaker methods gave the wrong answer first, and both are worth naming: +*linear decode* fell through into unrelated code and implicated 30-odd entries; +*"nearest preceding entry"* implicated `0xBB9C` only by luck of proximity +(`0x3988` bytes away). Only following branches settles containment. + +⚠️ I also matched `start_coroutine` operands **across phases** at first, which is +meaningless — the operand is relative to `[phase+232]`, which differs per phase. +Same trap that broke `isl.py`'s jump targets, hit again three iterations later. + +### 🟡 So why did the pokes do nothing? A different explanation is needed + +With the polls running at 5 Hz, "nobody was looking" is out. The likeliest +remaining reason is that **neither poke produced the state the predicate tests**: + +* `+16` — built-in 69 never reads it (established at `0x8226ADF0`); +* `+4 = 0` — that takes the handler's **early-exit** path, which is the same + branch an *undeployed* unit takes. The script very likely reads that as "not + here" rather than "destroyed". + +**This is a hypothesis, not a finding.** What would settle it: read what built-in +69 returns for a genuinely destroyed squadron versus a zeroed handle — the run +that caught `ADN111` dying naturally at 433 s is the reference, and its record is +the thing to compare against.