fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the dialog id to pak-entry join is not positional -- hypothesis refuted

Browse Source 
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
This commit is contained in:
sylph-decoder
2026-08-31 02:54:46 +00:00
parent 2d42ad2581
commit 2dba970c29
3 changed files with 109 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/re/data/difficulty-is-a-dialog.txt
View File

@@ -112,3 +112,36 @@
# ⚠️ 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.
################################################################################
# ❌ REFUTED: the id -> pak-entry join is NOT positional. 2026-08-31.
#
# GP_DIALOG.pak has exactly **140 entries** and the dialog table has exactly **70
# records** — a 2:1 ratio that looks like one EN/JP pair per dialog, which would
# make the unbound join an ordering question rather than a search. Tested, and it
# does not hold:
#
# ADJACENT pairing (2k, 2k+1) identical element-name sets: 2 of 65
# HALVES pairing (i, i+70) identical element-name sets: 0 of 65
# (5 pairs unreadable — entries that do not parse as builds)
#
# GP_TITLE's language pairs share their element sets exactly (except 4/7, the
# title art), so identical sets are the signature of a pair there. In GP_DIALOG
# almost nothing matches, so **the 2:1 ratio is not established as a language
# pairing** and no positional rule connects id 2000 to entries 2/3.
#
# 📌 RESIDUAL OBSERVATION, recorded because it is odd rather than because it is
# understood: the only two adjacent pairs with identical element sets are
# **entries 0/1 and 2/3** — and 2/3 is the DIFFICULTY build. Whatever makes those
# two structurally uniform in an archive where 63 of 65 pairs are not, this does
# not explain.
#
# ⚠️ A plausible reading I am NOT asserting: dialog text may be baked into
# language-specific sprites, which would make EN/JP entries differ in element
# names by construction. That is consistent with the 63, and it is one
# measurement away from being tested — but it is not tested here, and the 2 that
# DO match would then need their own explanation.
#
# => The join stays unbound. Table gives name -> id; disc gives a unique build;
# the tie is uniqueness plus the oracle capture. Positional ordering is now
# ruled out as the missing pointer, which narrows where to look next.