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.