3dc3fbadb8
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