From 71adafe7f7b1eba0544ffe59f5d43353945d4003 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Wed, 12 Aug 2026 21:49:48 +0000 Subject: [PATCH] re: the definition constructor zero-fills -- defaults are derived after parsing sub_8233FAF8 (0x8233faf8) writes vtable 0x820af844 -- the class dumped from a live mission -- and every one of its 32 stores writes zero, out past +872. So defaults are NOT constructor immediates, which was the hypothesis this tick set out to test. Since a defaulted Size_Y nevertheless reads back non-zero at runtime (always equal to Size_X), the value must be derived by a post-parse fixup -- the same shape as the inheritance rule derived statically from sibling records. Two candidate derivation sites (0x82217e18, 0x823081e8) are recorded as leads only: the first is a conditional assignment rather than a copy, and offsets 48/52 are generic enough to belong to unrelated structures. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/live-unit-definitions.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs/re/live-unit-definitions.md b/docs/re/live-unit-definitions.md index fa206d9..9f5df47 100644 --- a/docs/re/live-unit-definitions.md +++ b/docs/re/live-unit-definitions.md @@ -232,3 +232,27 @@ rather than one field per flight. (The `vtables`, `classes` and `methods` tables are empty in this DB build, as `CLAUDE.md` warns, so the class has to be reached through the call graph.) + +## The constructor zero-fills, so the defaults are derived, not stored + +Walking the call graph found the class: `sub_8233FAF8` (`0x8233faf8`) writes the +vtable **`0x820af844`** — the very objects dumped above — into `0(r30)` and then +initialises the instance. Every one of its 32 stores writes **zero** +(`stw r29, …` with `r29 = 0`), out to `+872` and beyond, interleaved with +string-member constructor calls. + +That kills the natural next hypothesis: **the defaults are not immediates in the +constructor.** The object starts at zero, `Idxd_Parse` writes only the fields the +text contains, and yet a defaulted `Size_Y` reads back as a *non-zero* value at +runtime (200 for the Destroyer, 700 for the `f105` Cruiser — always `Size_X`). + +So a defaulted value must be **derived after parsing**, which is exactly the shape +of the `Size_Y` inherits `Size_X` rule this project derived statically from sibling +records. Finding that fixup pass is what would yield the rest of the family. + +Two candidate sites turned up by searching for a load of `+0x30` feeding a store +to `+0x34` — `0x82217e18` (in `sub_82217A90`) and `0x823081e8` — but neither is +confirmed: the first is a *conditional* assignment (it compares `+0x30` against a +register and picks between two values before storing to `+0x34`), not a plain +copy, and offsets 48/52 are generic enough that both could belong to unrelated +structures. Recorded as leads, not findings.