e64965b3f9
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.
91 lines
4.2 KiB
Markdown
91 lines
4.2 KiB
Markdown
# 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.
|