From 925006d38f3567f22b7af9cf4f176cb5e7e8ba39 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 07:23:27 +0000 Subject: [PATCH] =?UTF-8?q?re:=20the=20mission=20black-screens=20at=20~4.5?= =?UTF-8?q?=20min=20=E2=80=94=20that=20is=20what=20ends=20every=20run?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A two-segment OB watch made the mechanism visible. Segment 1 ran clean, with the witness reporting zero stalled samples of fifty and OB steady at 4 for 250 seconds. Segment 2, attaching to the same still-alive emulator, got "NOT IN A MISSION (no unit definitions)". The emulator was alive; the mission was gone. The pilot's hull reads 1500 in every line, so the player never died. Its log stops at t=267 s with consecutive byte-identical lines, the freeze signature. And the screen is now entirely black, mean (0,0,0). This is the pre-existing mission-end black-screen freeze already recorded in the corpus, caught in the act. Segment 1's clean witness is not a contradiction, since it sampled to about 250 s and the freeze came at 267. That corrects an earlier claim. mission-arrival-watch.md records the blocker as removed because the emulator survives between calls, which is true, but it was stated as though observation could be extended indefinitely within a turn. The emulator surviving is not the mission surviving. The binding limit is the game's own black-screen at roughly four and a half minutes and no amount of chaining crosses it. The earlier chained run that reached 435 s of cumulative verified-live observation did so across two segments of one mission, which fits: its second segment froze at t=135 s. The consequence is worth stating plainly. Any experiment needing more than about four and a half minutes of one continuous mission is not doable on this build, chained or not, and that includes clearing sixteen marked fighters at two kills per five minutes. The freeze is therefore now the highest-value target in its own right, since fixing it would unblock the arrival question, the phase-advance question and the OB series together. It is also a long-standing known defect rather than anything this work introduced. --- docs/re/BACKLOG.md | 13 +++++++++ docs/re/guest-stalls.md | 47 ++++++++++++++++++++++++++++++ tools/re-capture/obwatch_attach.sh | 19 ++++++++++++ 3 files changed, 79 insertions(+) create mode 100755 tools/re-capture/obwatch_attach.sh diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index df4689dc..fd89f7de 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -670,6 +670,19 @@ search cannot find a *schedule*. no more kills. ❔ **The earlier 4→8→12 rise is NOT reproduced** — both readings were HUD-confirmed, so the rise is not a stable property of the first five minutes; recorded as unreproduced rather than explained away. +* ✅🔴 **(2026-08-25) THE MISSION BLACK-SCREENS AT ~4.5 MIN — that is what ends + every run.** Two-segment OB watch: segment 1 clean (**0/50 stalled**, OB steady + at 4 for 250 s); segment 2 on the same live emulator got **`NOT IN A MISSION`**. + Player never died (**hull 1500 throughout**), pilot log stops at **t=267 s** with + byte-identical lines, screen now **entirely black** (`mean=(0,0,0)`). This is the + known pre-existing mission-end freeze, caught in the act. + 🔴 **Corrects "chained attaches extend the window"** — the emulator surviving is + not the *mission* surviving; ~4.5 min is a hard per-mission bound and chaining + does not cross it. ⇒ **Anything needing >4.5 min of one mission is not doable on + this build**, including clearing 16 marked fighters at ~2 kills/5 min. The + freeze is now the highest-value target: fixing it unblocks arrivals, phase + advance and the OB series at once. ❔ The 4→8→12 OB rise is now unreproduced in + **3 of 4** runs. * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**; it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**. diff --git a/docs/re/guest-stalls.md b/docs/re/guest-stalls.md index 294c68cb..8b79c984 100644 --- a/docs/re/guest-stalls.md +++ b/docs/re/guest-stalls.md @@ -413,3 +413,50 @@ it is the only remaining lever worth pulling if longer windows are needed. Do not treat a single frozen run as evidence of anything. Run, check the witness, discard the frozen ones, and keep the clean runs — about three in four are usable now, which is workable where it previously was not. + +--- + +# ✅ What actually ends these runs: the mission black-screens at ~4.5 min (2026-08-25) + +A two-segment OB watch made the mechanism visible for the first time. + +**Segment 1** ran clean — witness reporting **0 stalled samples of 50**, OB steady +at 4 for 250 s. **Segment 2**, attaching to the same emulator, got: + +``` +NOT IN A MISSION (no unit definitions) +``` + +The emulator was still alive. The *mission* was gone. Looking at why: + +* the pilot's **hull is 1500 in every line** — the player never died; +* the pilot log stops at **t = 267 s** with consecutive byte-identical lines + (`spd=78`, same aim) — the freeze signature; +* the screen is now **entirely black**: `mean=(0.0, 0.0, 0.0)`. + +This is the **pre-existing mission-end black-screen freeze** already recorded in +the corpus, caught in the act. Segment 1's clean witness is not a contradiction: +it sampled to t ≈ 250 s and the freeze came at ≈ 267 s. + +## 🔴 Correction: chained attaches do NOT extend a mission + +[mission-arrival-watch.md](mission-arrival-watch.md) records "BLOCKER REMOVED: +the emulator survives between calls", and that is true — but it was stated as if +observation could be extended indefinitely within a turn. It cannot. **The +emulator surviving is not the mission surviving.** The binding limit is the +game's own black-screen at roughly four and a half minutes, and no amount of +chaining crosses it. + +The earlier chained run that reached 435 s of cumulative verified-live +observation did so across *two* segments of one mission — consistent with this, +since its second segment froze at t = 135 s. + +## What it means for the open questions + +* Any experiment needing more than ~4.5 minutes of one continuous mission is + **not doable** on this build, chained or not. That includes clearing 16 marked + fighters at two kills per five minutes. +* The freeze is now the highest-value target in its own right: fixing it would + unblock the arrival question, the phase-advance question and the OB series at + once. It is also, per the corpus, a long-standing known defect rather than + something this work introduced. diff --git a/tools/re-capture/obwatch_attach.sh b/tools/re-capture/obwatch_attach.sh new file mode 100755 index 00000000..a168c8c1 --- /dev/null +++ b/tools/re-capture/obwatch_attach.sh @@ -0,0 +1,19 @@ +#!/usr/bin/env bash +set -u +export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98 +export PYTHONPATH=/sylph-home/.local/lib/python3.12/site-packages +SD="$(cd "$(dirname "$0")" && pwd)" +pgrep -x xenia_canary >/dev/null || { echo "NO EMULATOR"; exit 1; } +CFG=/tmp/nav-obhud2.json +for try in 1 2 3; do + python3 "$SD/pad.py" set "rt=1" >/dev/null 2>&1 || true; sleep 3 + python3 "$SD/pad.py" clear >/dev/null 2>&1 || true + if python3 "$SD/entities2.py" self 0x130 "$CFG" >/dev/null 2>&1; then + SYLPH_HUNT=1 SYLPH_KILL_TURRETS=1 SYLPH_KEEPOUT=1400 SYLPH_PREFER=e010 \ + nohup python3 "$SD/pilot.py" "$CFG" "${1:-400}" /tmp/obhud2-pilot.log 2>&1 & + P=$!; echo "--- pilot re-attached"; break + fi +done +python3 "$SD/ob_watch.py" "${1:-400}" "${2:-25}" +[ -n "${P:-}" ] && kill "$P" 2>/dev/null +echo "OBHUD ATTACH DONE"