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

re: decode kind bit 0 as "has a parent" -- 0x3003 IS 0x3002, parented

Browse Source 
The port is blocked on what 0x3003 is, having only 0x3002 in its menu-item
rule. The two differ in bit 0 alone. Disc-wide over every .pak: kind&1 ==
has_parent agrees on 15493 elements with 0 counterexamples -- 192/192 for
0x3003, 778/778 for 0x3002, and the same for every other kind. The flag is
exactly redundant with the +32 parent field.

So the bit that differs carries no role information: 0x3003 is a 0x3002
button record that is parented. That replaces the port's circumstantial case
with the field, which is what they asked for rather than a widened rule.

Flags what this does NOT license: it is not a decode of "is a menu item",
and 0x73002/0x73003 (160 elements) carry an undecoded 0x70000 that any
mask-based rule silently decides about.

Adds examples/kind_bit0_census.rs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-03 19:19:44 +00:00
parent a8b58dfdb1
commit 040008244f
2 changed files with 112 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
docs/re/ui-kind-bit0-is-has-parent.md Normal file
View File

@@ -0,0 +1,60 @@
# ✅ `kind` bit 0 is **"has a parent"** — so `0x3003` *is* `0x3002`
**Question:** the port has a menu-item rule keyed on `kind == 0x3002`, and the
OPTIONS rows are `0x3003`. What is `0x3003`?
**What the human looks at:** the OPTIONS rows move. Pass = the five settings rows
respond like main-menu rows.
**What this does NOT cover:** bits `0x2`, `0x8`, `0x10`, and the `0x70000` bits —
none of those are decoded here.
**Instrument:** ⟨disc⟩, every `.pak` in `dat/`.
Reproduce: `cargo run -p sylpheed-formats --example kind_bit0_census`.
## Decoded
`0x3002` and `0x3003` differ in **bit 0 alone**, and bit 0 is the parent flag:
```
kind&1 == has_parent : agree 15493 DISAGREE 0
```
| kind | n | with parent | without |
|---|---|---|---|
| `0x0000` | 7459 | 0 | 7459 |
| `0x0001` | 1093 | **1093** | 0 |
| `0x0004` | 2964 | 0 | 2964 |
| `0x0005` | 282 | **282** | 0 |
| `0x3002` | 778 | 0 | 778 |
| **`0x3003`** | **192** | **192** | **0** |
| `0x73002` | 64 | 0 | 64 |
| `0x73003` | 96 | **96** | 0 |
Every kind with bit 0 set is parented in **every** instance; every kind without
it is unparented in every instance. The flag is **exactly redundant** with the
`+32` parent field, across 15 493 elements and every bundle on the disc.
**So `0x3003` is a `0x3002` button record that happens to be parented.** The bit
that differs carries no role information at all.
## What this does and does not license
It removes the *reason* to treat the OPTIONS rows differently: they are the same
record class as the main-menu buttons, distinguished only by parenting. The port
was right not to widen a kind rule on circumstantial grounds — this replaces the
circumstance with the field.
⚠️ It does **not** decode "is a menu item". `0x3002`/`0x3003` is a record class;
that the class is what menus are built from is still the port's existing reading,
now applied consistently rather than extended.
⚠️ **`0x73002` and `0x73003` exist too** — 160 elements with the same low bits and
an undecoded `0x70000` above them. Any mask-based rule decides about those
whether or not its author meant to. I have not looked at what the high bits mean.
## Reach of the negative
Bit 0 is decoded. Bits `0x2`, `0x8`, `0x10` and `0x70000` are not; the corpus
elsewhere has `0x4` (template instance) and `0x10` (pivot-sized), and warns
separately that `kind & 0x2` is **not** the blend field.