fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: built-in 15's write side verified; its consumer NOT found, filters recorded

Browse Source 
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
This commit is contained in:
Sylpheed RE agent
2026-08-26 01:03:06 +00:00
parent a5432a9a3b
commit a140ad6894
1 changed files with 32 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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