GP_DIALOG has exactly 140 entries against the table's 70 records, a 2:1 ratio that
would make the unbound join an ordering question. It does not hold: adjacent
pairing gives identical element-name sets on 2 of 65 pairs, halves pairing on 0.
GP_TITLE's language pairs share element sets exactly, so identical sets are the
signature there; in GP_DIALOG almost nothing matches.
Residual and unexplained: the only two adjacent pairs that DO match are entries 0/1
and 2/3, and 2/3 is the DIFFICULTY build.
A reading I am not asserting: dialog text may be baked into language-specific
sprites, which would explain the 63 by construction but leaves the 2 needing their
own explanation. Not tested.
The join stays unbound; positional ordering is now ruled out, which narrows where
to look next.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
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
Closes a negative of mine whose failed assumption I had named: I searched for an
8-record btn-named build in an archive of its own, assuming DIFFICULTY's four items
pair with f variants the way GP_TITLE's screens do. It has its own prefix and is
not a GamePart screen at all.
Three independent routes agree. The image lists DLG_SELECT_DIFFICULTY among the
DLG_* dialog names at 0x820A41BB, and GP_DIFFICULTY appears zero times. GP_DIALOG
entries 2/3 are the only builds there with pcbtn00..03 -- four buttons at design
rows 259/329/399/469, spacing 70, an EN/JP pair. And my capture of the running
screen puts its four rows within 4 px of those, with spacing 70.5/69.5/70.0 against
the disc's 70/70/70.
Reach stated: the entries are identified by button count and geometry, not by a
binding from the DLG_ name to a pak entry. No such binding was found.
Also notes the consequence for Q6's count-match: NEW GAME opens a DIALOG from an
external archive, which still matches the count but is not the same category as
OPTIONS or TUTORIAL opening a GamePart.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
