f7cc0bd283
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
2.3 KiB
✅ 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.