a921c1ef9d
main_menu ptbtn04 had goto:null and blocked:'GP_OPTIONS not in this export'. GP_OPTIONS is in the export now, entry 19 is its root, and the walk works: main_menu -> down x3 -> (A) -> the OPTIONS root renders, (B) backs out. A dead button became a real screen. 🔴 Navigation INSIDE it does not work, and that is a decode question. The exporter's detector is kind==0x3002 && !focused; the OPTIONS rows are 0x3003, so role is unknown and buttons[] is empty. Not widened here -- what 0x3003 means is the Decoder's. The circumstantial case is strong and circumstantial is exactly the standard that has cost this project three retractions. A rule of 'has a focus record therefore is a menu item' fits both screens and is still an inference about semantics from structure; not taken. Also recorded: a screen NAME only reaches the port through a full re-export, which re-transcodes both movies -- renaming one screen costs the whole tree. 🔴 And a dangerous mistake: pkill -f 'check-all' matched the CONTAINER ENTRYPOINT, whose command line contains the loop prompt, which mentions check-all. pgrep then reported the job still running after it had stopped, and pkill -9 on that pattern could have killed the session. Match on comm or list with ps and check first -- a pattern that appears in your own instructions does not identify a process.
4.6 KiB
The OPTIONS menu tree exists, renders, and is named
2026-09-03. GP_OPTIONS joined export_archives and produced 14 screen
builds. All 14 render; all 14 are now named.
What they are
| entry | name | English | entry | name | |
|---|---|---|---|---|---|
| 19 | options |
the root — GAME / CONTROL / SOUND / SCREEN SETTINGS, BACK | 21 | options_jp |
|
| 16 | game_settings |
Auto-Save, View Point, Radio Log, Subtitles | 18 | game_settings_jp |
|
| 4 | control_settings |
Control Type, Throttle, sensitivities, Vibration | 8 | control_settings_jp |
|
| 3 | sound_settings |
Music / Movie / Voice / SFX Volume | 5 | sound_settings_jp |
|
| 6 | screen_settings |
Gamma Correction, R/G/B, NEXT PAGE | 9 | screen_settings_jp |
|
| 7 | screen_settings_page2 |
White / Black Level Adjust, PREVIOUS PAGE | 10 | screen_settings_page2_jp |
|
| 20 | control_customize |
per-action key remapping | 22 | control_customize_jp |
A clean EN/JP pair for every screen, which is itself a check: 14 builds, 7 pairs, no leftovers.
How they were identified, and why that is stronger than usual here
By the text the screen renders about itself. Each was exported, drawn by the port at rest, and read: the titles and row labels are legible.
📌 That matters because this project has been bitten three times by
identification via position, size or ordinal — the sweep strips confused by
size, the plate identified by screen position, ptcopyright mistaken for the
plate. A screen that renders the words SOUND SETTINGS above four volume rows is
not that kind of inference.
⚠️ What it still does not establish: which screen the game navigates to
from which. The tree above is read off content, so control_customize being
"reached from CONTROL SETTINGS" is a reading of its own legend
(Ⓨ : Customize on control_settings), not a measured transition. Wiring
anything beyond main_menu → options needs the real navigation.
Not yet done
- Nothing is reachable yet.
main_menuptbtn04still hasgoto: null. po_pad_slider1has no sprite in the export and reports NOT DRAWN.- All 14 are
NEVER COMPAREDbyverify-screen— reported, not asserted; both its allowance and the reference renderer were calibrated onGP_TITLE. - The screens are static: no navigation, no focus movement, no value editing.
✅ OPTIONS is reachable — and navigation inside it is blocked on a kind
main_menu ptbtn04 now has goto: "options". Walked with the menu harness:
main_menu → ⬇⬇⬇ → Ⓐ → the OPTIONS root renders. Ⓑ backs out.
🔴 The rows do not move, and the reason is a decode question
The exporter's button detector is kind == 0x3002 && !focused. The OPTIONS rows
are kind_raw = 0x3003, so role comes out unknown, the export's
buttons[] is empty, and up/down move nothing.
| screen | element | kind | focus record | in buttons[] |
|---|---|---|---|---|
main_menu |
ptbtn01 |
0x3002 |
yes | yes |
extras |
ptbtn11 |
0x3002 |
yes | yes |
options |
po_menu_btn1 |
0x3003 |
yes | no |
What 0x3003 means is not the port's to decide, so the rule was not widened
here. The circumstantial case is strong — five rows, each carrying a focus
record, on a screen whose own text lists five options — and circumstantial is
precisely the standard that has cost this project three separate retractions.
Asked of the Decoder.
⚠️ A tempting alternative rule is "an element with a focus record is a menu item", which fits both screens. It is still an inference about semantics from structure, and it would silently reclassify elements on every screen in the export. Not taken.
The workflow cost this exposed, worth knowing before repeating it
A screen name is authored data, but it only reaches the port through a full re-export — which re-transcodes both movies. Renaming one screen costs the whole tree. Not worth fixing today; worth knowing before anyone plans a naming pass.
🔴 And a genuinely dangerous mistake, recorded because it nearly cost the session
Killing a background check with pkill -f "check-all" matched the container's
own entrypoint, whose command line contains the loop prompt — and that prompt
mentions check-all. pgrep duly reported the process as still running after it
had stopped, and a pkill -9 on that pattern could have killed the session
itself.
Match a process by its actual comm, or list with ps and check, before
sending a signal. A pattern that appears in your own instructions is not a
pattern that identifies a process.