Read directly at 0x8232C7CC, the unit message pump switches on [msg+36]:
mode 1 [unit+196] = [unit+192] restore the unit's stored default
mode 2 [unit+196] = [r27+13912] a global constant
mode 3 [unit+196] = [msg+40] the value the script passed
So the field has a per-unit default at +192 and a distinguished global value.
The shipped scripts only ever use mode 3 -- slot 8 is the double tag in
1961/1961 call sites -- so the two defaulting modes are dead in this build.
The consumer I did not find, and the failed approaches are recorded so the
next attempt does not repeat them:
* searching the flight/AI range for 196(rN) gives 170 hits, almost all on
unrelated structs -- the N(rM) trap this file already warns about;
* narrowing to functions touching BOTH +192 and +196 still leaves 50;
* unit_definition_layout.txt names offsets 192/196 as AV_PitchMinus_Max/Min,
but that is the unit DEFINITION object (vtable 0x820af844), not the spawned
entity built-in 15 writes to. It does not apply, and taking it would have
been an easy wrong turn -- angular-velocity names would have "explained"
the turret anomaly while being about a different struct entirely.
What would settle it is pinning the spawned-entity struct first, then reading
+196's consumers within it.
Built-in 15 stays unnamed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
a140ad6894