re: three boot-path failures that look like the emulator and are not
Spent a session getting to flight. Each obstacle presents as "the emulator
died" and none of them is.
* --audio prevents boot. run-canary's header already says the flag is not a
cvar in this tree and that an unknown argument blocks in a message box
before logging starts. Measured anyway, because the corpus also holds runs
that passed it and booted: 3 trials each in BOTH orders, 67 565 bytes of log
without the flag and 209 with -- and 209 is run-canary's own banner, not one
line from xenia. Order was reversed on purpose; this corpus has a standing
lesson that an A/B from run order is noise. Eight scripts on branch
auto/idxd-unnamed-keys still pass it; main and this branch are clean, which
reconciles August's successes with today's failures.
* launch_mission.sh's skip_intro deadlocks. It calls the attract loop a
"movie" and refuses to tap, and waited out 600 s of unbroken movie verdicts
before timing out. nav_to_flight.sh, against the same running emulator,
reached the main menu in 12 s and flight in 2 min 20 s by tapping A at the
title. The "wait it out" premise is wrong: the loop does not end.
* "EMULATOR GONE at ~40 s" is this project's own Stop hook killing xenia when
a Claude turn ends. That is recorded further down this same file and I
rediscovered it over three boots because I did not look. Sequential tool
calls within one turn are fine; ending the turn is what kills it.
The world unit is still unmeasured. Flight was reached and the screen
classifier agrees, but entities2.py finds 0 unit definitions -- its committed VA
window does not match this run, the same run-dependent-address problem this file
documents for the OB counter. Next attempt must hunt the range.
This commit is contained in:
@@ -6,6 +6,52 @@ unknown, what evidence exists, and what the first step would be. Move an item in
|
||||
|
||||
---
|
||||
|
||||
## 🧰 The boot path — three failures that look like the emulator and are not (2026-08-26)
|
||||
|
||||
* ✅ **`--audio` prevents boot outright.** `run-canary`'s own header says the flag
|
||||
is not a cvar in this tree, and that an unknown argument makes xenia call
|
||||
`ShowSimpleMessageBox` from `ParseLaunchArguments` *before* logging starts,
|
||||
blocking forever. Measured anyway, because this corpus also holds runs that
|
||||
passed it and booted fine: **3 trials each, in both orders** —
|
||||
|
||||
| | log written |
|
||||
|---|---|
|
||||
| `run-canary --apu=sdl --log_mask=13` | **67 565 bytes** |
|
||||
| `run-canary --audio --apu=sdl --log_mask=13` | **209 bytes** |
|
||||
|
||||
209 bytes is `run-canary`'s own banner and not one line from xenia. The order
|
||||
was reversed deliberately — this corpus already has a lesson that an A/B from
|
||||
run order is noise.
|
||||
🔴 **Eight scripts on branch `auto/idxd-unnamed-keys` still pass it**:
|
||||
`launch_mission.sh`, `boot_menu.sh`, `fly_stage.sh`, `challenge_probe.sh`,
|
||||
`grab_tutorial.sh`, `find_partslot.sh`, `tutorial_capture.sh`, `nav_probe.sh`.
|
||||
`main` and this branch are clean, which reconciles August's successes with
|
||||
today's failures. Left unfixed here: they are another branch's files.
|
||||
|
||||
* 🔴 **`launch_mission.sh`'s `skip_intro` deadlocks on the attract loop.** It
|
||||
classifies the screen as `movie` and declines to tap ("tapping breaks the
|
||||
title"), and waited out **600 s of unbroken `movie` verdicts** before timing
|
||||
out. `nav_to_flight.sh`, against the *same running emulator*, reached the main
|
||||
menu in **12 s** and flight in **2 min 20 s** by tapping A at the title. The
|
||||
"wait it out" premise is wrong — the attract loop does not end on its own.
|
||||
**Use `nav_to_flight.sh` on an already-running canary.**
|
||||
|
||||
* ⚠️ **`EMULATOR GONE at ~40 s` is this project's own Stop hook**, which
|
||||
`kill -9`s every `xenia_canary` when a Claude turn ends. Already recorded
|
||||
further down this file — and rediscovered the hard way over three boots because
|
||||
I did not search for it first. The rule is the one `fly_session.sh`'s header
|
||||
states: **an emulator session must be one task; nothing may depend on surviving
|
||||
between tool calls.** Sequential tool calls *within* one turn are fine; it is
|
||||
ending the turn that kills it.
|
||||
|
||||
❔ **The world-unit measurement is still not made.** Flight was reached and the
|
||||
screen classifier agrees, but `entities2.py self` reports **0 unit definitions** —
|
||||
its committed VA window `0xBD00_0000`–`0xBE00_0000` does not match this run, the
|
||||
same run-dependent-address problem this file documents for the OB counter. The
|
||||
next attempt must hunt the range rather than trust the stored config.
|
||||
|
||||
---
|
||||
|
||||
## ❌ WITHDRAWN (2026-08-26, same day) — the Japanese voice banks are NOT a separate format
|
||||
|
||||
The `sound.pak` census (see
|
||||
|
||||
Reference in New Issue
Block a user