06f9af75ea
Chasing the reach I recorded this morning found the binding it said was missing.
Every DLG_ string in the image is pointed at by one aligned word at a 12-byte
stride: {u32 handler, u32 id, u32 name_ptr}, spanning 0x820A0A2C..0x820A0D68 with
three distinct handlers. Complete -- 70 names, 70 records, none unmatched -- and the
ids are banded and monotonic with a single gap at 24. Read from the image directly.
Refutation attempt on the shared reach, which both agents had recorded: 'another
four-button dialog with the same rows would be indistinguishable'. Scanned every
build in every pak for four buttons within 6 px of 259/329/399/469. Control found
both incumbents; zero rivals exist anywhere on the disc. So the geometric
identification is unique disc-wide, which is stronger than what either of us
claimed.
Still unbound: id 2000 to a pak entry. The tie remains uniqueness plus the oracle
capture, not a pointer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
115 lines
6.0 KiB
Plaintext
115 lines
6.0 KiB
Plaintext
# Where does the DIFFICULTY screen live? ✅ DECODED 2026-08-31.
|
|
# It is a DIALOG -- `DLG_SELECT_DIFFICULTY`, GP_DIALOG.pak entries 2/3.
|
|
#
|
|
# CLOSES A NEGATIVE OF MINE. gp-title-holds-three-button-screens.txt recorded
|
|
# "not an 8-record btn-named build anywhere on the disc", with the failed
|
|
# assumption named as mine: I assumed DIFFICULTY's four items pair with `f` focus
|
|
# variants in an archive of its own, the way GP_TITLE's screens do. Both halves
|
|
# of that were wrong -- it has its own button prefix and it is not a GamePart
|
|
# screen at all.
|
|
#
|
|
################################################################################
|
|
# ROUTE 1 -- THE IMAGE. /image/sylpheed.pe, 3 occurrences of "DIFFICULTY":
|
|
# 0x820A2548 STAGE | DIFFICULTY | TITLE | FADE | BASE_EXTRA ...
|
|
# (a GamePartTask::RegisterToFactory name list)
|
|
# 0x820A3377 RECORD_DIFFICULTY (a results/record field)
|
|
# 0x820A41BB DLG_LEADERBOARD_MENU_NEXT | DLG_SYSTEM_PAUSE |
|
|
# **DLG_SELECT_DIFFICULTY** | DLG_MISSION_OBJECTIVE |
|
|
# DLG_MESSAGE_BOX | DLG_MESSAGE_BOX_YES_NO | ...
|
|
#
|
|
# ✅ The third is the answer: DIFFICULTY is one of the game's DLG_* dialogs.
|
|
# ⚠️ "GP_DIFFICULTY" appears 0 times in the image, which is consistent.
|
|
#
|
|
################################################################################
|
|
# ROUTE 2 -- THE DISC. GP_DIALOG.pak entries 2 and 3 are the only builds in that
|
|
# archive carrying `pcbtn00`..`pcbtn03` -- FOUR buttons, matching
|
|
# EASY / NORMAL / HARD / BACK. Design rows and spacing:
|
|
#
|
|
# entry 2 y 259 / 329 / 399 / 469 spacing 70, 70, 70
|
|
# entry 3 identical (the EN/JP pair, as everywhere else)
|
|
#
|
|
# ✅ CONTROL: the same reader on GP_TITLE entry 5 returns 162/242/322/401/482,
|
|
# spacing 80 -- the rows that archive is independently known to place.
|
|
#
|
|
################################################################################
|
|
# ROUTE 3 -- THE ORACLE. My own capture of the running DIFFICULTY screen
|
|
# (captures/menu-nav/live-difficulty-opens-normal.png), with the disc-grounded
|
|
# calibration capture_y = 64.82 + 0.9919 * design_y:
|
|
#
|
|
# design row predicted measured in the capture residual
|
|
# 259 321.7 323.5 +1.8
|
|
# 329 391.2 394.0 +2.8
|
|
# 399 460.6 463.5 +2.9
|
|
# 469 530.0 533.5 +3.5
|
|
# measured spacing 70.5 / 69.5 / 70.0 against the disc's 70 / 70 / 70
|
|
#
|
|
# Four rows, all under 4 px, with the spacing agreeing exactly. The residual is a
|
|
# uniform ~+2.8 px offset, which is the calibration's own systematic and not a
|
|
# mismatch.
|
|
#
|
|
# => THREE INDEPENDENT ROUTES: the executable names it a dialog, the disc has a
|
|
# four-button dialog build, and the running game draws its rows where that
|
|
# build says they are.
|
|
#
|
|
# 📌 WHY IT MATTERS BEYOND THE LOCATION: DIFFICULTY being a DIALOG explains why
|
|
# NEW GAME's destination is not a screen in GP_TITLE, and it means the "four menu
|
|
# items load an external archive" reading of the event numbers
|
|
# (boot-config-and-gamepart-registry.md's count-match) is looser than it looked --
|
|
# NEW GAME opens a dialog from GP_DIALOG.pak, which is an external archive, but a
|
|
# dialog is not the same kind of thing as OPTIONS or TUTORIAL opening a GamePart.
|
|
# The count still matches; the categories are not uniform.
|
|
#
|
|
# ⚠️ REACH: entries 2/3 are identified by button count and geometry, not by a
|
|
# name binding DLG_SELECT_DIFFICULTY to a pak entry. No such binding was found --
|
|
# the DLG_* names live in a string list, and what maps a name to an archive entry
|
|
# is not decoded. Another 4-button dialog with the same rows would be
|
|
# indistinguishable by this evidence.
|
|
|
|
################################################################################
|
|
# ✅ DECODED 2026-08-31 (later): THE DIALOG TABLE. `DLG_SELECT_DIFFICULTY` = id 2000.
|
|
#
|
|
# Chasing the reach above -- "no binding from the DLG_ name to anything" -- found
|
|
# one. Every DLG_ string in the image is pointed at by exactly one aligned word,
|
|
# at a regular 12-byte stride. The table is:
|
|
#
|
|
# struct { u32 handler; u32 id; u32 name_ptr; } // 12 bytes, big-endian
|
|
#
|
|
# spanning 0x820A0A2C .. 0x820A0D68, three distinct handler values
|
|
# (0x821CFD80, 0x821D05D8, 0x821D0808).
|
|
#
|
|
# ✅ COMPLETE: 70 DLG_ names in the image, 70 records, ZERO names without one.
|
|
# ids are banded and monotonic, with a single gap at 24:
|
|
# 0..23 sign-in, storage, save/load/replay, GO_TITLE, GO_NEXT
|
|
# 25..43 autosave, training, weapon develop, custom keys, menu jumps
|
|
# 98, 99 DLG_MESSAGE_BOX_YES_NO, DLG_MESSAGE_BOX
|
|
# 1000 DLG_MISSION_OBJECTIVE
|
|
# 2000 **DLG_SELECT_DIFFICULTY**
|
|
# 2001..3 SYSTEM_PAUSE, LEADERBOARD_MENU_JUMP, LEADERBOARD_MENU_NEXT
|
|
# 2100..15 DLG_STAGE_TITLE01..16
|
|
# 8000 DLG_RATING_ESRB
|
|
# 9000..2 trial dialogs
|
|
#
|
|
# Read from /image/sylpheed.pe directly -- these are the bytes the console ran,
|
|
# not a database row.
|
|
#
|
|
################################################################################
|
|
# ✅ REFUTATION ATTEMPT ON THE SHARED REACH -- IT SURVIVES, AND IS NOW BOUNDED.
|
|
#
|
|
# Both agents recorded: "another four-button dialog with the same rows would be
|
|
# indistinguishable by this evidence". Tested by scanning EVERY build in EVERY pak
|
|
# for four buttons within 6 px of rows 259/329/399/469
|
|
# (examples/four_button_row_rivals.rs):
|
|
#
|
|
# INCUMBENT GP_DIALOG.pak entry 2 rows [259, 329, 399, 469]
|
|
# INCUMBENT GP_DIALOG.pak entry 3 rows [259, 329, 399, 469]
|
|
# control: 2 incumbents found (want 2) -- PASSED
|
|
# RIVALS ELSEWHERE ON THE DISC: **0**
|
|
#
|
|
# So the hypothetical rival does not exist here. The geometric identification is
|
|
# UNIQUE DISC-WIDE, which is a stronger statement than the one either of us
|
|
# recorded, and it was cheap to get.
|
|
#
|
|
# ⚠️ WHAT IS STILL NOT BOUND: id 2000 -> a pak entry. The table gives name -> id
|
|
# and the disc gives a unique four-button build; nothing found so far connects the
|
|
# two. The tie is uniqueness of geometry plus the oracle capture, not a pointer.
|