f35a871baa
The next suspect was a role or depth field in the 48-byte element record, so every undecoded word was dumped for all 24 title elements against its paint slot. Clean negative: +0x08, +0x0C, +0x18, +0x1C and +0x2C are zero on 21 of 24 elements, and the three exceptions hold what looks like live animation state. Nothing there orders anything. One confirmation on the way: +0x04 is the declaration entry's `kind`, verified against the file for all 24 — 0x10 on the two .prm elements, 0x4 on the four repeat instances, 0x3000 on the two ptlogoall_eff, zero elsewhere. The record mirrors the file here as the pivot and keyframe count already did. And `kind` does not explain the order either: the paint order interleaves kinds freely. So the ordering is in none of the decoded data — not the declaration entry, not the placement region, not the runtime record. What is left is the loader that appends to +0x30, which is worth reading precisely because the order is deterministic. Stated without promising a static rule exists merely because one could.