From 5693a1e3739b7e9dd5234e314643af0d44bcaf89 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 01:10:17 +0000 Subject: [PATCH] re: built-in 15 targets a GROUP, and +192 is a MIN over its members 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) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/structures/isl-builtins.md | 53 ++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 3 deletions(-) diff --git a/docs/re/structures/isl-builtins.md b/docs/re/structures/isl-builtins.md index 915f859c..fb4c0639 100644 --- a/docs/re/structures/isl-builtins.md +++ b/docs/re/structures/isl-builtins.md @@ -191,7 +191,51 @@ value, and built-in 15 either sets it, restores it, or hands it the constant. 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 never exercised. -#### ❌ The consumer is NOT identified — two filters failed +#### ✅ `+192` is a MIN over the group's members — seeded with `FLT_MAX` + +The spawn routine `sub_8232B538` settles what the field *is*, without needing its +consumer: + +``` +8232B5B0 lfs f0, 25184(r11) ; r11 = 0x820B0000 -> 0x820B6260 = 3.4028235e38 +8232B5B4 stfs f0, 192(r30) ; seed +192 with FLT_MAX + … per member … +8232B674 lfs f13, 164(r3) ; the member's own value +8232B67C lfs f0, 192(r30) +8232B680 fsubs f11, f13, f0 +8232B688 fsel f0, f11, f0, f13 ; f0 = min(f0, f13) +8232B68C stfs f0, 192(r30) + … later … +8232BA10 lfs f0, 192(r30) +8232BA28 stfs f0, 196(r30) ; +196 starts equal to +192 +``` + +The seed being **`FLT_MAX`** is what makes this unambiguous: `+192` is the +**minimum of `[member+164]` across the members**, and `+196` starts there. + +🔑 **So built-in 15's target is a GROUP, not an individual unit** — this file and +my earlier notes both called it a unit. `sub_82348830` hands back a per-member +object and the reduction runs over all of them. + +#### 🟡 That reading survives the turret anomaly + +A minimum over members is exactly how a **formation limit** works: the group can +only go as fast as its slowest ship. On that reading `+192` is the natural cap and +`+196` the effective one, with built-in 15 either lowering it, restoring it +(mode 1), or handing it a global constant (mode 2). + +And a *cap* explains the turrets, where a commanded speed could not. Capping a +static object at 400 is a **no-op** — nothing makes it move — so a designer can +set it uniformly from a unit template without consequence. The asteroid's +invariant `0` is consistent with the same reading. + +❔ I have **not** shown mode 2's constant is `FLT_MAX`. It is +`[r27 + 13912]` where `r27` is loaded from a runtime pointer at `0x8232C718`, not +a static base, so it cannot be resolved from the image alone. If it is `FLT_MAX` +then mode 2 is literally "uncapped" and the three modes are +set / uncap / restore — tidy, and unproven. + +#### ❌ The consumer is still NOT identified — three filters failed Recorded so the next attempt does not repeat them: @@ -204,8 +248,11 @@ Recorded so the next attempt does not repeat them: *definition* object** (vtable `0x820af844`), not the spawned entity built-in 15 writes to. It does not apply here, and it would be an easy wrong turn. -What would settle it is the object's identity: pin the spawned-entity struct -first, then read `+196`'s consumers within it. +The object's identity is now partly pinned — it is a group with a member list, +not a single craft — but the struct is not bounded: the two constructors that +write vtable `0x820AF030` are 28 and 30 instructions and touch neither field, and +the image has **no RTTI at all** (0 of 1150 vtables), so class names are +synthetic. Bounding the group struct is the remaining prerequisite. ### ✅ Four built-ins are TUTORIAL-ONLY — 85 sites, every one in S18–S23