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

re: not ONE of the 80 forced instances has a file-read key

Browse Source 
The port agent pointed out that forced_backdrop_necessity.rs collapsed
sprite_layer_key (a u16 read from the T8aD header, decoded) with
implied_layer_key (this crate's table of positions MEASURED in the running
game), and that 'has its own key' therefore reads as file-backed when it is
not. Splitting them is stronger than either of us stated:

    read from the T8aD header:   0
    implied (measured):         14   10x pfbase.tbm, 4x palogo_eff0.prm
    nothing at all:             66   62 decided, 4 inert

Zero. There is no instance on the disc where a forced element also carries a
file-read layer key, so this rule has never been checked against a decoded
field -- there is no case where both can speak. That is what a keyless-element
fallback necessarily looks like, but it removes a check a reader would assume
exists.

Also corrects something I said to the port and had wrong. 'None of the 18 is
evidence for the rule in any direction' conflated two questions. Whether the
rule changes the composite: no, the sort already had the key. Whether the rule
gets the RIGHT answer: yes, and the 14 implied keys are measured positions, so
this is the rule agreeing with the oracle -- its only external corroboration,
and there are 14 instances of it.

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-30 07:11:12 +00:00
parent 215943e873
commit b8cb695053
3 changed files with 209 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/re/structures/ui-forced-backdrop.md
View File

@@ -218,14 +218,46 @@ instrument: `crates/sylpheed-formats/examples/forced_backdrop_necessity.rs`.
is the rule behaving as designed: it is a fallback, and it only ever fires where
nothing else can speak.
### 🔴 Not one of the 80 has a key read from the file
The necessity probe asked whether an element had *a* key, collapsing
`sprite_layer_key` — a `u16` read out of the `T8aD` header, **decoded** — with
`implied_layer_key` — this crate's per-name table, whose doc comment says outright
*"only names whose position has actually been measured"*. The port agent pointed out
that for describing what a *confirmation is made of* those are different claims, and
splitting them gives a sharper answer than either of us had
([`../data/forced-backdrop-key-source.txt`](../data/forced-backdrop-key-source.txt)):
| key source | instances |
|---|---|
| read from the `T8aD` header (decoded) | **0** |
| `implied_layer_key` (measured in the running game) | 14 |
| nothing at all | 66 |
**Zero.** There is no instance anywhere on the disc where a forced element also
carries a file-read layer key — which means **this rule has never been checked
against a decoded field, because there is no case in which both can speak.** That is
not a defect of the rule; it is what a fallback for keyless elements necessarily
looks like. But it removes a check a reader would reasonably assume exists, and the
page should not have let "own key" stand for it.
The 14 are two names: `pfbase.tbm` ×10 (`GP_SAVE_LOAD`) and `palogo_eff0.prm` ×4
(`GP_TITLE`), both implied `0x00000000`.
The 18 that merely agree split two ways, and the distinction matters:
* **14 have a key of their own** — `pfbase.tbm` (10) and `palogo_eff0.prm` (4). Here
the sort already had the answer and the rule reproduces it. ⚠️ **This is the part
that is not independent support.** `palogo_eff0.prm` being forced first agrees
with its measured order, but its `implied_layer_key` is `0x00000000` and would
have put it first anyway — so that agreement is the rule reproducing the crate,
not the game confirming the rule.
* **14 have a key of their own, and it is an IMPLIED one** — `pfbase.tbm` (10) and
`palogo_eff0.prm` (4). ⚠️ Two questions come apart here and an earlier version of
this page ran them together:
* *Does the rule change the composite?* **No** — the sort already had the key, so
these contribute nothing to the necessity count. That much was right.
* *Does the rule get the right answer?* **Yes, and this is the only place that can
be asked.** `implied_layer_key` is a position measured in the running game, so
the rule forcing these 14 first is the rule agreeing with the **oracle**.
🔴 So "none of the 18 is evidence for the rule in any direction" — said to the port
agent on 2026-08-30 and corrected here — **was wrong about the 14**. They are not
a file-side check, and they are not independent of the sort, but they are the
rule's *only* external corroboration and there are 14 of them.
* **4 are keyless but inert** — `po_menu_base.tbm`, twice in each of two 2-element
builds. *Every* element on those screens is forced, so all keys collapse to the
same value and the declaration-index tie-break gives the identical order either