From 3dc3fbadb8d89a239c8cd3e2ad3ad65522b0d4f8 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 01:03:06 +0000
Subject: [PATCH] re: built-in 15's write side verified; its consumer NOT
 found, filters recorded

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
---
 docs/re/structures/isl-builtins.md | 35 +++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/docs/re/structures/isl-builtins.md b/docs/re/structures/isl-builtins.md
index 1572a9b..915f859 100644
--- a/docs/re/structures/isl-builtins.md
+++ b/docs/re/structures/isl-builtins.md
@@ -174,9 +174,38 @@ gets **0 every time**, so "immobile things get a meaningless value" does not
 explain the turrets either.
 
 So: ✅ a craft-class-dependent scalar in speed's range and with speed's ordering;
-❌ not `set_speed` as a plain reading. **Left unnamed.** The handler writes
-`[unit+196]`, initialised from `[unit+192]` at spawn — reading its consumer is
-what would settle it.
+❌ not `set_speed` as a plain reading. **Left unnamed.**
+
+#### ✅ The write side, read directly
+
+`0x8232C7CC` in the unit message pump switches on `[msg+36]` three ways:
+
+| mode | effect |
+|---|---|
+| 1 | `[unit+196] = [unit+192]` — restore the unit's stored default |
+| 2 | `[unit+196] = [r27+13912]` — a global constant |
+| 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, 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
+
+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 same `N(rM)` trap this file already warns about.
+* Narrowing to functions that touch **both** `+192` and `+196` still leaves
+  **50**. The pair is not distinctive either.
+* `crates/sylpheed-formats/data/unit_definition_layout.txt` names offsets 192 and
+  196 as `AV_PitchMinus_Max` / `AV_PitchMinus_Min` — **but that is the unit
+  *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.
 
 ### ✅ Four built-ins are TUTORIAL-ONLY — 85 sites, every one in S18–S23