From 482086583560fb2811a103b4892cc4b491c95b5a Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 18:24:48 +0000 Subject: [PATCH] re: S1 -- the Ready Room probe is a no-go, and not for the reason the question expected One iteration, as the mission gates it, and no Ready Room work started. The two criteria it named both pass. It is NOT 3D: the corpus already holds a capture of the running screen and it is a flat six-item menu in the same visual language as the title. And unrecoverable paths do not mean unrenderable screens -- content enumeration finds 60 builds in the 1106 entries. What kills it is something the question did not ask. GP_READY_ROOM.pak does not appear to hold the Ready Room's own menu at all. Two signals agree: the four largest builds composite to briefing panels -- a planet readout, unit markers, direction arrows -- and, much harder, the 902 bundles declare 317 distinct element names of which NONE matches any of the six labels on the screen (takeoff, brief, hangar, pilot, option, mission, ready all return nothing). The pak is the briefing / tactical-map content behind the BRIEFINGS item. If this is ever picked up, the first job is finding where the menu lives -- GP_BUNK.pak is the obvious place -- not naming this pak's keys. The probe also reaches back into something already delivered: kind == 0x3002 finds ZERO buttons across all 902 bundles here, while GP_TITLE has 16. 0x3002 is one member of a 0x3000 family with sub-bits, and this pak uses 0x3000/0x3004/0x300c/0x3008. Nothing in the milestone changes -- every screen in scope is GP_TITLE -- but the handoff now says not to ship that equality as a general button test. --- docs/port/HANDOFF.md | 10 ++++- docs/port/MISSION.md | 2 +- docs/re/INDEX.md | 1 + docs/re/REFUTED.md | 9 ++++ docs/re/ready-room-probe.md | 90 +++++++++++++++++++++++++++++++++++++ 5 files changed, 109 insertions(+), 3 deletions(-) create mode 100644 docs/re/ready-room-probe.md diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 0dccc7ab..077218c4 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -37,7 +37,7 @@ authored version can be deleted. | Q8 | menu audio bindings | โ” open | cue table complete, event binding is not | | Q9 | video binding + playback rules | ๐ŸŸก partial | `ADV.wmv` is the boot intro; new-game intro unidentified | | Q10 | music-bank sub-wave roles (intro+loop?) | โœ… answered | **two stems of one performance, played together** โ€” sample-synchronous, equal duration, 32/32 banks. **Concatenating is wrong.** Not a seamless loop either โ€” [`structures/bgm-two-stems.md`](../re/structures/bgm-two-stems.md) | -| S1 | Ready Room go/no-go | โ” open | probe not run | +| S1 | Ready Room go/no-go | โœ… **no-go** | it is 2D and enumerates fine (60 builds), but `GP_READY_ROOM.pak` holds **briefing/tactical-map** content, not the six-button Ready Room menu โ€” [`ready-room-probe.md`](../re/ready-room-probe.md) | ## Already settled โ€” the port can rely on these today @@ -55,7 +55,13 @@ authored version can be deleted. `GP_TUTORIAL`, `GP_OPTIONS`, `GP_MISSION_SELECT` are the likely destinations by name โ€” an inference, not a measurement). * **Buttons are identifiable as data.** Element kind `0x3002` = button, `0x0` = - decoration, `0x10` = primitive. โœ… decoded. + decoration, `0x10` = primitive. โœ… decoded **for the title-side screens**. + โš ๏ธ `0x3002` is one member of a `0x3000` family with sub-bits, and it is not the + only button kind on the disc: `GP_READY_ROOM`'s 902 bundles contain **zero** + `0x3002` and use `0x3000` / `0x3004` / `0x300c` / `0x3008` instead. Nothing in + this milestone changes โ€” every screen in scope is `GP_TITLE` โ€” but do not ship + `kind == 0x3002` as a general button test. + (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.) * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is โœ… correct for a vertical menu and is **not** a decoded neighbour graph โ€” the disc's real navigation structure is unknown, and `opt ` is *not* a focus link diff --git a/docs/port/MISSION.md b/docs/port/MISSION.md index 073a2b9a..5b56e693 100644 --- a/docs/port/MISSION.md +++ b/docs/port/MISSION.md @@ -75,7 +75,7 @@ alongside it. | **Q8** | **Menu audio.** Which BGM per screen; which cue on move / confirm / back / error. The cue table is complete; the event binding is not | Cue names bound to events, with how you established each | | **Q9** | **Video binding.** Which movie is the boot intro vs the new-game intro; whether playback is skippable and what ends it | Named movies plus the playback rules | | **Q10** | **What are a music bank's sub-waves?** `BGM_001.slb` is three sub-waves โ€” 10 KB, 4.47 MB, 4.67 MB โ€” and we currently **concatenate them blindly** into one 347 s track. Two near-equal halves could be intro + loop, or two variations, or two halves of one piece. A menu that loops its music needs to know which | The role of each sub-wave, established for at least the menu BGM. "Concatenate" is a decision, not a default โ€” right now it is a default nobody chose | -| **S1** | **Ready Room probe.** *Gated* โ€” one iteration, then stop | A written go/no-go (see below) | +| **S1** | ~~**Ready Room probe.**~~ **DONE 2026-08-28 โ€” [no-go](../re/ready-room-probe.md).** It is 2D and enumerates fine, but the pak is briefing/tactical-map content, not the Ready Room menu | โœ… go/no-go written | ## Known unknowns โ€” say so, do not fill them in diff --git a/docs/re/INDEX.md b/docs/re/INDEX.md index 7148af91..cd058b7d 100644 --- a/docs/re/INDEX.md +++ b/docs/re/INDEX.md @@ -152,6 +152,7 @@ files, which is how the same ground got covered twice. | [`ui-quad-class-foothold.md`](ui-quad-class-foothold.md) | The guest's UI quad class โ€” a foothold found from the capture's vertex layout | ๐ŸŸก PROBABLE for the identification below (it is a static read, but | | [`menu-navigation-semantics.md`](menu-navigation-semantics.md) | The title menu โ€” how it moves, and where each button goes | โœ… measured: wraps both ends, โ’ท restores focus, โฌ…โžก inert; 4 of 5 destinations driven. ๐ŸŸก GamePart id is a name match, โ” `NEW GAME` untested | | [`screen-transitions.md`](screen-transitions.md) | Between two screens โ€” a fade through black, and where its timing lives | โœ… the fade quad's keyframe group is decoded (disc-wide: per-pak all-or-nothing; `GP_TITLE` = the 6 screens, not the 6 overlays); the ~0.4 s fade-OUT is measured, not on the disc | +| [`ready-room-probe.md`](ready-room-probe.md) | S1 โ€” the Ready Room probe: no-go, and not for the reason expected | โœ… it is 2D and enumerates (60 builds), but the pak is briefing/tactical-map content; and `kind == 0x3002` finds 0 buttons there | | [`ui-title-build-map.md`](ui-title-build-map.md) | Which `GP_TITLE` build is which screen state | โœ… CONFIRMED for title / `PRESS โ’ถ` / main menu / `EXTRAS` against live captures; the archive is 8 screens ร— EN/JP, and "6/8/9 are submenus" is withdrawn | | [`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md) | The title screen's paint order, measured from the guest's draw submissions | โœ… CONFIRMED โ€” the order in which the running game paints the title | | [`upstream-baseline.md`](upstream-baseline.md) | A stock-upstream baseline runs Stage 02 crash-free | โœ… CONFIRMED โ€” upstream canary_experimental + only the pad | diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index f29e7201..9c707118 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -35,6 +35,15 @@ neighbourhood, not just the line. ## Screens, classes and RTTI +* "`GP_READY_ROOM.pak` holds the Ready Room screen" โ†’ its 317 distinct element + names contain **none** of the six visible labels; it is the briefing / + tactical-map content behind the `BRIEFINGS` item. + [`ready-room-probe.md`](ready-room-probe.md) +* "the Ready Room might be 3D with a UI overlay" โ†’ it is **2D**; the pak carries + zero 3D containers. +* "element kind `0x3002` is *the* button kind" โ†’ title-side only. All 902 + `GP_READY_ROOM` bundles have **zero** `0x3002`; that pak uses `0x3000`, + `0x3004`, `0x300c`, `0x3008`. `0x3002` is one member of a `0x3000` family. * "the transition between menu screens is a cut" โ†’ it is a **fade through black**; a 0.5 Hz screenshot burst simply samples too slowly to see it. [`screen-transitions.md`](screen-transitions.md) diff --git a/docs/re/ready-room-probe.md b/docs/re/ready-room-probe.md new file mode 100644 index 00000000..bd099919 --- /dev/null +++ b/docs/re/ready-room-probe.md @@ -0,0 +1,90 @@ +# S1 โ€” the Ready Room probe: **no-go**, and not for the reason expected + +**Status:** one iteration, as [MISSION ยงS1](../port/MISSION.md) specifies. This is +the written go/no-go. No Ready Room work has been started. + +## Recommendation: no-go + +Not because it is 3D โ€” **it is not** โ€” and not because the names are +unrecoverable. Because the probe found that **`GP_READY_ROOM.pak` does not appear +to contain the Ready Room's own menu screen at all**, so the question the mission +framed ("only 6 of 1 106 names resolve, is that a week or a quarter?") is aimed at +the wrong target. And it is outside the five-screen milestone regardless. + +## What the probe measured + +### โœ… It is 2D. This is not a 3D room with a UI overlay. + +The corpus already holds a framebuffer capture of the running screen, +[`captures/ready-room-extra-mode.png`](captures/ready-room-extra-mode.png): a flat +menu โ€” a `READY ROOM` wordmark, six labelled items (`TAKE OFF`, `BRIEFINGS`, +`HANGAR`, `PILOT LOG`, `OPTIONS`, `MISSION CHANGE`), a focus ring, and an +`โ’ถ : OK / โ’ท : Mission change` footer โ€” in exactly the visual language of the +title menus. There is no model viewport. The pak's own entry list carries **zero +3D containers** (no `XPR2`, no `XBG7`). + +So the mission's own no-go-by-definition criterion is **not** met. That part is a +go. + +### โœ… Enumeration by content works โ€” 60 builds + +`sylpheed-cli screen list` finds **60 screen builds**. The 1 106 entries break +down as **902 RATC bundles, 192 IDXD objects, 6 `ttf`, 6 `LSTA`**. The worry that +unresolvable *paths* would mean unrenderable *screens* is unfounded here. + +### ๐Ÿ”ด But none of it is the Ready Room menu + +Two independent signals, and they agree. + +**Rendered composites are briefing panels.** Four of the 60 builds โ€” the largest +and most element-rich (18, 26, 44 and 9 elements) โ€” composite to a planet +information panel, unit markers and direction arrows: +[`ready-room-pak-builds.png`](captures/ready-room-probe/ready-room-pak-builds.png). +Tactical-map material, not a six-item menu. โš ๏ธ **4 of 60 sampled** โ€” this alone +does not close it. + +**The name census does close it much harder.** The 902 bundles declare **317 +distinct element names**, all under a `pb*` prefix family: +`pbfriendly` (330), `pbacropolis` (168), `pbrhino` (48), `pbsub` (204), +`pbtab` (48), `pbcm` (132)โ€ฆ Searching all 317 for any of the six visible labels โ€” +`takeoff`, `take_off`, `brief`, `hangar`, `pilot`, `option`, `mission`, `ready` โ€” +returns **nothing**. The only `main` hits are `pbmain_btn1..3.t32`, +`pbmain_window.t32` and their `_eff` glows, which appear in 9- and 4-element +*fragments*, not a screen, and are declared **kind 0** (decoration). + +Read together: this pak is the **briefing / tactical-map** content that sits +*behind* the Ready Room's `BRIEFINGS` item, and the Ready Room's own menu lives +somewhere else. Note the GamePart table has both `10 GP_BUNK` and +`11 GP_READY_ROOM` ([`challenge-mission-gate.md`](challenge-mission-gate.md) ยง3), +and `GP_BUNK.pak` is a separate archive that was not examined here. + +### ๐Ÿ”ด And a caveat that reaches back into the delivered corpus + +**`kind == 0x3002` finds zero buttons in this pak.** All 902 bundles, 0 hits โ€” +while `GP_TITLE` has 16. What `GP_READY_ROOM` uses instead: + +| kind | count | +|---|---| +| `0x3000` | 491 | +| `0x3004` | 406 | +| `0x300c` | 135 | +| `0x3008` | 60 | +| `0x3001` | 6 | +| `0x3002` | **0** | + +So `0x3002` is one member of a `0x3000` **family** with sub-bits, and "element +kind `0x3002` is a button" โ€” a โœ… row in [`HANDOFF.md`](../port/HANDOFF.md) โ€” is +sound for the title screens and **must not be applied as an equality test +elsewhere**. For the five-screen milestone nothing changes; for anything beyond +it, test the family. + +*(The kind field is the 4th `u32` of the 60-byte declaration entry, at `+40`. +Calibrated on `GP_TITLE` build 6, where it reads `0x3002` for exactly the three +`EXTRAS` buttons and `0x0` for the decorations.)* + +## If it is ever picked up + +The first job is **not** naming this pak's keys. It is finding where the Ready +Room's six-button screen actually lives โ€” `GP_BUNK.pak` is the obvious first +place to look, and the same content-based `screen list` / name-census pass costs +one iteration there.