Section 4 claimed the mission-kind field at obj+144 "is initialised to 0 in the
constructor sub_821783D8, alongside +148 = 0, +132 = 2, +136/+140 = -1". That
linked two code regions on nothing more than both touching +144/+148, and an
in-flight snapshot refutes it:
sub_821783D8 initialises the STATIC at 0x828F3EC0 -- its first act is
InitializeCriticalSection(obj, 256) -- and in the snapshot that object holds
0x000B1C8B at +144 and a float at +592. Not a kind, not flags. So the object that
owns the kind field is UNIDENTIFIED. Scanning the snapshot for it (kind in
{0,3,5,6} at +144, stage 10 at +148, pointers at +0/+52/+604) returns only
matches inside the executable's own static data; the value 10 at +148 is far too
common to discriminate.
The switch itself stands -- it is direct disassembly at two independent sites
(0x82184df0, 0x82185ed0) plus two grouping tests. Only the attribution was wrong,
and the wrong half is the half I inferred rather than read.
Confirmed on screen instead: launching a story stage from MISSION SELECT reaches
a READY ROOM carrying an "EXTRA" watermark -- the EXTRA config section, kind 3,
visible in the UI. Independent evidence the field means what section 4 says even
though its owning object is not pinned.
Claude (auto-RE)
a79a1da183