Sylpheed/docs/re/structures/ui-keyframe-unknown-4-8.md

🟡 The keyframe block's +4 and +8 — narrowed, not decoded

Status: 🟡 the space is much narrower than "unexplained", and the reason it cannot be closed here is specific and worth stating. ❔ Not decoded — nothing below is confirmed against the oracle.

+12 is ✅ decoded as a screen-plane rotation in degrees (ui-keyframe-rotation.md). +4 and +8 sit immediately before it, are carried rather than dropped, and one standing reading is that the three together are rotations about three axes — "not tied to an observed rotation".

Census over every UI pak on the disc: 2 859 builds, 90 347 keyframes, parents and nested leaves alike. data/kf-unknown-4-8-census.txt, --example kf_unknown_census.

They do not behave like +12

	+4	+8	+12 (decoded rotation)
distinct values	12	11	157
non-zero keyframes	4 289 (4.75 %)	4 064 (4.50 %)	12 520 (13.86 %)
commonest non-zero	180 ×4 200	180 ×3 288	90 ×1 968

And per sprite-instance, across 14 241 of them — with +12 as the control, since it is a field known to hold a real angle:

	both 0 and ±180 in one build	±180 with no 0	more than 2 distinct values
+4	415	252	7
+8	360	180	99
+12 (control)	155	30	396

🔴 +4 takes more than two values on 7 instances out of 14 241; +12 does so on 396 — 57× more. In practice +4 is a two-state field, and the state is 180. For a screen-plane sprite a 180° rotation about an in-plane axis is a mirror, so the overwhelmingly common use of these fields is a flip.

⚠️ But they are NOT booleans, and one element shows why

GP_TITLE entry 7 has the only interesting case on the disc's title side:

ptlogo3a.t32   +4=-72  +12=-14
               +4=-18  +12=-4
               +4=-4   +12=-1
               +4=-1   +12=0

+4 and +12 decay to zero together, +4 running roughly 4–5× +12 at each keyframe. That is a coupled two-axis settle, not a flag — and it is the strongest support the disc offers for the three-axis reading. The census's other odd values (22, 60, −45, 178, 23) say the same thing more weakly.

✅ So the two readings reconcile: the field is an angle, and its overwhelmingly common use is the 180° special case that mirrors a sprite. A consumer that treats it as a boolean will be right 97 % of the time and wrong on ptlogo3a.

🔴 Why it cannot be closed here — the reach

All six non-zero +4/+8 keyframes in GP_TITLE are in entry 7, the Japanese title:

e7 ptlogo3a.t32                      +4=-72/-18/-4/-1
e7 ptlogo_eff2.rat->ptlogo_eff2.t32  +4=180  (both keyframes)

• title_jp has no oracle capture, so a mirror or a two-axis settle cannot be confirmed against the running game in this container;
• MISSION §7 scopes out "localisation beyond English", so entry 7 is not a question this port has to answer;
• the five English screens that do have captures have +4 = +8 = 0 on every keyframe — they never exercise these fields at all.

⚠️ So this is not "needs more work"; it is untestable against every oracle this project holds, and the only assets that would test it are out of scope. The paks that use the fields heavily — GP_READY_ROOM (4 686), GP_DIALOG (1 058) — are also outside the menu port's scope, and GP_READY_ROOM is separately a recorded no-go.

For the port: the five menu screens are unaffected either way. Carrying the fields rather than dropping them, which sylpheed-formats already does, remains the right handling.