# 🟡 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`](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`](../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.