fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the sign-in fix must be applied at launch, not by the navigator

Browse Source 
nav_to_flight.sh contains no run-canary invocation -- it drives an
already-running emulator -- so whether a profile is signed in depends entirely on
how the caller launched it.  Every nav_to_flight run in this session was launched
with a bare run-canary, which is why they froze.  Worth stating plainly because
the script prints "signing in profile B13EBABEBABEBABE", which comes from the
emulator's startup rather than from the script arranging it.

Refuted: "each screen loads its own GP_*.pak", a plausible route to a real screen
identity.  With full file logging the only names that appear are at boot
(sound.p0x, tables.p00, hidden) and nothing new opens as the UI moves between
screens -- the paks are opened once and read by offset, so file I/O carries no
per-screen signal.

Also recorded: one launch this iteration never reached the title -- progress
counter stuck at 0, black screen, guest churn 0.001%.  That is a DIFFERENT
failure from the sign-in freeze, which stalls after the main menu with the
counters already advanced, and it matches the boot flakiness
canary-scripted-input-traps.md already documents.  The counters distinguish
them: sign-in freeze stalls past the title, a bad boot never leaves 0.
This commit is contained in:
Sylpheed RE agent
2026-08-26 19:07:25 +00:00
parent c09107fa8d
commit 0274b29368
1 changed files with 32 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/mission-freeze-signin-dialog.md
View File

@@ -67,3 +67,35 @@ Checking that distinction is what led to the dialog mechanism.
scans are still 0 at screen 10, so the remaining screens are menus (mission
select, briefing, ready room). That is now ordinary navigation work, not a
blocker.
## ⚠️ The fix must be applied at LAUNCH — `nav_to_flight.sh` cannot do it
`nav_to_flight.sh` contains **no** `run-canary` invocation: it drives an
*already-running* emulator. So whether a profile is signed in depends entirely on
how the caller launched it, and every `nav_to_flight` run in this session was
launched with a bare `run-canary --apu=sdl …`.
**That is why those runs froze**, and it is worth stating plainly because the
script prints `signing in profile B13EBABEBABEBABE` — which comes from the
emulator's own startup, not from the script arranging it.
run-canary --apu=sdl --logged_profile_slot_0_xuid=B13EBABEBABEBABE # then nav_to_flight.sh
## 🔴 Refuted: "each screen loads its own `GP_*.pak`"
A plausible way to get a *real* screen identity — watch which pak the game opens
— does not work. With full file logging, the only names that appear are at boot
(`sound.p0x`, `tables.p00`, `hidden`), and nothing new is opened when the UI
moves between screens. The paks are opened **once** and read by offset
thereafter, so file I/O carries no per-screen signal.
## ⚠️ Boots are flaky, independently of this bug
One launch in this iteration never reached the title at all: progress counter
stuck at `0`, screen black (mean `0,0,0`), guest churn **0.001 %**. That is a
*different* failure from the sign-in freeze — which stalls *after* the main menu
with the counters already advanced — and it matches the flakiness
`canary-scripted-input-traps.md` already documents ("(A) at the title is accepted
on roughly half of boots and nothing observable predicts which"). **Distinguish
them by the counters**: sign-in freeze stalls with counters advanced past the
title; a bad boot never leaves 0.