5693a1e373
The spawn routine sub_8232B538 settles what the field is without needing its consumer: 8232B5B0 lfs f0, 25184(r11) -> 0x820B6260 = 3.4028235e38 (FLT_MAX) 8232B5B4 stfs f0, 192(r30) seed +192 with FLT_MAX 8232B674 lfs f13, 164(r3) each member's own value 8232B688 fsel f0, f11, f0, f13 f0 = min(f0, f13) 8232B68C stfs f0, 192(r30) 8232BA28 stfs f0, 196(r30) +196 starts equal to +192 The FLT_MAX seed is what makes it unambiguous: +192 is the MINIMUM of [member+164] over the members. So built-in 15's target is a GROUP, not an individual unit -- this file and my own earlier notes both called it a unit. sub_82348830 hands back a per-member object and the reduction runs over all of them. A minimum over members is how a formation limit works: the group goes as fast as its slowest ship. On that reading +192 is the natural cap and +196 the effective one. And a CAP explains the turrets where a commanded speed could not -- capping a static object at 400 is a no-op, so a designer can set it uniformly from a template without consequence, and the asteroid's invariant 0 fits the same reading. Recorded as unproven: mode 2's constant is [r27 + 13912] where r27 comes from a runtime pointer at 0x8232C718, not a static base, so it cannot be resolved from the image. If it is FLT_MAX then mode 2 is literally "uncapped" and the three modes are set / uncap / restore. Tidy, and not shown. The consumer is still not found. Also recorded: the image has NO RTTI at all (0 of 1150 vtables), so class names are synthetic and the two constructors writing vtable 0x820AF030 are 28 and 30 instructions touching neither field. Bounding the group struct is the remaining prerequisite. Built-in 15 stays unnamed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE