From 0c930f203a477e25a0e640c3d779a3b4b3fdc8b1 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 17:11:16 +0000 Subject: [PATCH] re: corrected poke also does nothing -- and the method lacks a positive control rec+4 = 0 (the early-exit path built-in 69 actually tests) sticks for 60s with all three squadrons poked, and neither the phase nor +16 changes. +16 stayed 2 while the handle it derives from read zero. Leading explanation: the phase-1 condition coroutine is not polling. Both pokes persist untouched and nothing recomputes anything, which fits the polls at 0xF524 living in a coroutine that only runs when a trigger starts it (built-in 1, fed from [phase+272]). But the honest problem is bigger: two pokes have now produced no observable effect and I cannot tell 'the game ignored the write' from 'the write never reached the game'. The stick test only proves the value persisted in the shared-memory FILE, not that Canary's guest sees it. That control should have come first, so both null results are downgraded to INCONCLUSIVE rather than evidence about the condition. Next: poke something with a visible effect (player hull, a HUD counter) and confirm it on screen before trusting any further null result. What still stands from these runs is only what was observed rather than poked -- the arrivals, ADN111's destruction, and the mission-over branch. --- 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 34f9164..3c7ee79 100644 --- a/docs/re/script-runtime-probe.md +++ b/docs/re/script-runtime-probe.md @@ -280,3 +280,45 @@ made a small index look like a live object. guess, given the values), and how to make the condition actually re-evaluate. Firing the trigger — built-in 100 pushes onto `[phase+272]` — is the next thing to look at. + +## 🔴 The corrected poke (`rec+4 = 0`) also does nothing — and I have no positive control + +Built-in 69 reads `rec+4`, not `rec+16` (see +[isl-builtins](structures/isl-builtins.md)), so the corrected simulation of +"this squadron is gone" is `rec+4 = 0`, which takes the handler's documented +early exit. Ran it with all three squadrons active: + +``` +STICK TEST on ADN110 +4: was=26 wrote=0 after2s=0 -> STICKS +poked all 3 + [+5s .. +60s] phase=1 finished=0 states={ADN110:2, ADN111:2, ADN112:2} +``` + +**No phase end, and `+16` never changed either** — it stayed 2 for a full minute +while the handle it is supposedly derived from read zero. + +### 🟡 The leading explanation: the condition coroutine is not running + +Both pokes persist untouched, and nothing recomputes `+16`. If the phase-1 +condition were polling `unit_state` on these squadrons each frame, one of these +writes should have provoked *something*. The consistent reading is that the +polls at `0xF524` live in a coroutine that **only runs when a trigger starts +it** (built-in 1 `start_coroutine`, fed from the queue at `[phase+272]`), so +changing unit state without firing the trigger changes data nobody is reading. + +### 🔴 The gap in this method: no positive control + +Two pokes have now produced no observable effect, and **I cannot distinguish +"the game ignored the write" from "the write never reached the game"**. The +stick test only proves the value persisted *in the shared-memory file* — it does +not prove Canary's guest sees it. + +That is a real hole, and it should have been closed before drawing conclusions +from a null result. **The control to run first: poke something with a visible +effect** — the player's hull, or a HUD counter — and confirm the change appears +on screen. Until that passes, every "poking X did nothing" here is unfalsifiable +rather than informative, and the two null results above must be read as +*inconclusive*, not as evidence about the condition. + +**What still stands** from these runs is only what was *observed*, not poked: +the arrival transitions, the destruction of ADN111, and the mission-over branch.