fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: built-in 15 targets a GROUP, and +192 is a MIN over its members

Browse Source 
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
This commit is contained in:
Sylpheed RE agent
2026-08-26 01:10:17 +00:00
parent 3dc3fbadb8
commit 5693a1e373
1 changed files with 50 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
docs/re/structures/isl-builtins.md
View File

@@ -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