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

re: the sign-in fix holds end-to-end, but no units are loaded yet

Browse Source 
With the emulator launched correctly and the boot verified by the progress
counter first (counter > 0 = title reached; a flaky boot never leaves 0),
nav_to_flight.sh ran the whole sequence -- main menu at 20 s, mask poke, stage
select, briefing skip, ready room, take-off -- where every previous attempt
stalled.

The game is alive at the end of it: screen liveness 2.13% against 0.00% when
frozen, guest churn 0.288-2.932% against 0.000%.  An animating screen and a busy
guest at the point that used to be stone dead.

But no units.  DEF_VTABLE (0x820AF844) has no hits on a direct byte search, with
a working control in the same run: searching for the poked cleared-stage mask
0x0001FFFE finds it at 0x828F40C0, exactly where nav_to_flight wrote it.  So the
search is sound and the vtable is genuinely absent.  Both vtable constants were
also checked against sylpheed.db's vtables table and are real vtables, so they
are not stale.  Three minutes of waiting left DEF/INST at 0/0 with the counter
static at 17.

So the run reaches a live, animating state that is not a mission with spawned
units -- most likely the launch cinematic or a post-take-off screen.  The freeze
is gone; what still separates this from unit spawn is the remaining work.
This commit is contained in:
Sylpheed RE agent
2026-08-26 19:20:24 +00:00
parent 0274b29368
commit 926cee6ba0
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -99,3 +99,38 @@ with the counters already advanced — and it matches the flakiness
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.
## ✅ The fix holds end-to-end — `nav_to_flight.sh` now runs to completion
With the emulator launched correctly, and the **boot verified by the progress
counter before spending time on navigation** (counter > 0 means the title was
reached; a flaky boot never leaves 0), `nav_to_flight.sh 2` ran the whole
sequence — main menu at 20 s, mask poke, stage select, briefing skip, ready room,
take-off — where every previous attempt stalled.
And the game is **alive at the end of it**:
| | frozen (before the fix) | now |
|---|---|---|
| screen liveness | **0.00 %** | **2.13 %** |
| guest churn | 0.000 % (19 B of 8 MB) | **0.288 – 2.932 %** |
An animating screen and a busy guest, at the point that used to be stone dead.
## ❔ But no units are loaded, and that is measured rather than assumed
`DEF_VTABLE` (`0x820AF844`) has **no hits** on a direct byte search of guest
memory, with a working control in the same run — searching for the poked
cleared-stage mask `0x0001FFFE` finds it at **`0x828F40C0`**, exactly where
`nav_to_flight` wrote it. So the search is sound and the vtable is genuinely
absent. Both constants were also checked against `sylpheed.db`'s `vtables` table
and are real vtables (`ANON_Class_C329B3BE`, `ANON_Class_503A3BED`), so they are
not stale.
Waiting does not change it: three minutes at counter 17 with `DEF/INST = 0 / 0`
throughout.
So the run reaches a **live, animating state that is not a mission with spawned
units** — most likely the launch cinematic or a post-take-off screen. The freeze
is gone; identifying where the sequence actually lands, and what still separates
it from unit spawn, is the remaining work.