moby_anim was the one post-shrub chunk type with a concrete reason to exist: an
instance table would have to scale with the level's moby class count, so
comparing per-type record counts against that count was the obvious test.
It fails, and the way it fails is itself the result: per-type record counts are
level-independent. The same types report the same counts on every level tried:
type_id level0 level1 level2 level3
0x007d7ec438 90 90 90 90
0x00d3d8c4a9 90 90 90 90
0x00429ec43d 77 77 77 77
0x0053c8c4aa 77 77 77 77
0x007626c4a4 50 50 50 50
0x00fb88c462 47 47 47 47
Across all 27 levels there are 77 distinct chunk types, the largest at 2430
records total -- exactly 90 x 27.
What that rules out: nothing in this chunk set is a per-moby-class instance table,
because those counts would vary by level the way the moby class counts do. So
whatever holds moby animation data is either keyed by something other than the
class count, or it is not among these chunk types.
Also visible: the types pair up. 0x007d7ec438 and 0x00d3d8c4a9 both report 90 on
every level; 0x00429ec43d and 0x0053c8c4aa both report 77. Two chunk types
carrying identical, constant record counts on every level is a signature of two
views of the same fixed table rather than two independent tables that happen to
agree.
Still open: the pairings are described but not explained, and no type has been
named. The Moby class-ID enrichment from earlier stands separately -- 9493 hits
against 246.1 expected is real, and the class arrays are contiguous per type, but
that identifies where classes are referenced, not which chunk is moby_anim.
ReaperOfVeriod
b17ec17127