re: GP_TITLE holds exactly three button screens, and EXTRAS is the only internal destination

Serves Q6's open question. boot-config-and-gamepart-registry.md records a
count-match for the title part's event numbers -- four menu items load an external
archive, EXTRAS stays inside GP_TITLE -- explicitly as an observation rather than a
decode. Half of it is disc-checkable and now has support.

Every button record in all 16 GP_TITLE entries: ptbtn00 (the plate), ptbtn01..05
(main menu), ptbtn11..13 (EXTRAS). No fourth button screen, so no DIFFICULTY build,
and DIFFICULTY is what NEW GAME opens. The other four destinations have their own
paks -- GP_OPTIONS, GP_SAVE_LOAD, GP_TUTORIAL -- while EXTRAS' two children are
GP_MISSION_SELECT and GP_MOVIE_THEATER, so EXTRAS is internal and its children are
not.

Still NOT a decode of the event numbers: the shape the count-match asserts is real
on the disc, but nothing shows a given event is a given row.

Negative recorded with its reach: DIFFICULTY's build is not located. I searched for
an 8-button-record build on the assumption its four items pair with f variants, as
GP_TITLE's screens do. They may not, so the negative is narrower than 'not found'.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 02:18:06 +00:00
parent 53572029e6
commit 3f46b9cf16
3 changed files with 145 additions and 0 deletions

View File

@@ -0,0 +1,53 @@
# Which main-menu destinations live INSIDE GP_TITLE? ✅ ONLY EXTRAS.
# 2026-08-31. Static, disc-wide over GP_TITLE.pak.
#
# THE QUESTION IT SERVES: boot-config-and-gamepart-registry.md records a
# count-match for the title part's event numbers -- "Ⓑ = event 0, four menu items
# load an external archive, EXTRAS stays inside GP_TITLE" -- and marks it
# explicitly as an observation, NOT a decode, because nothing showed that any
# particular event is a particular menu row. Half of it is disc-checkable: does
# EXTRAS alone live inside GP_TITLE?
#
# ✅ EVERY BUTTON RECORD IN GP_TITLE.pak, all 16 entries
# (examples/gp_title_buttons.rs):
#
# entry 2/3 ptbtn00, ptbtn00f -- the PRESS (A) plate
# entry 5/8 ptbtn01..05 + f variants + ptbtn02b -- MAIN MENU, 5 items
# entry 6/9 ptbtn11..13 + f variants -- EXTRAS, 3 items
#
# Three button screens, and no fourth. There is NO DIFFICULTY build in GP_TITLE,
# and DIFFICULTY is what NEW GAME opens (menu-navigation-semantics.md).
#
# ✅ AND THE OTHER FOUR DESTINATIONS HAVE THEIR OWN ARCHIVES on the disc:
# OPTIONS -> GP_OPTIONS.pak
# LOAD GAME -> GP_SAVE_LOAD.pak
# TUTORIAL -> GP_TUTORIAL.pak
# NEW GAME -> DIFFICULTY, which is NOT in GP_TITLE (see below)
# while EXTRAS' own two items are GP_MISSION_SELECT.pak and GP_MOVIE_THEATER.pak
# -- so EXTRAS is a screen that stays inside GP_TITLE and whose CHILDREN leave it.
#
# => THE STRUCTURAL HALF OF THE COUNT-MATCH HAS DISC SUPPORT: exactly one
# main-menu destination is internal to GP_TITLE, and it is EXTRAS.
#
# ⚠️ THIS IS STILL NOT A DECODE OF THE EVENT NUMBERS. It shows the SHAPE the
# count-match asserts is real on the disc; it does not show that event 3 is a
# particular row, and the page's own warning stands. What changes is that the
# "one event elsewhere, four to LOADING" pattern now matches a disc fact rather
# than only a count.
#
################################################################################
# ❔ NOT LOCATED: where the DIFFICULTY build lives.
#
# Searched every .pak on the disc for a build with EXACTLY 8 button records --
# four items (EASY / NORMAL / HARD / BACK) with `f` focus variants, the shape
# GP_TITLE's own screens use. Found in only five archives, none of them
# plausible: GP_DEBRIEFING_PILOTLOG, GP_DIALOG, GP_GAMEOVER, GP_OPTIONS,
# GP_PAUSE_MENU. Nothing in GP_SYSTEM, GP_SAVE_LOAD, GP_TUTORIAL,
# GP_MISSION_SELECT or GP_MOVIE_THEATER.
#
# ⚠️ REACH, and the assumption that failed is mine: I assumed DIFFICULTY's four
# items are 8 button records because GP_TITLE's screens pair every button with an
# `f`. They may not be -- BACK may not be a button record, the names may not
# contain "btn" at all, or the screen may not parse as a build. So the negative
# is "not an 8-record btn-named build anywhere on the disc", which is narrower
# than "not found".