re: the unit loader was already in the corpus (sub_82341A20), and 0-xref does not mean no reader

Item "what loads the 114 unit Maneuver records" -- the corpus already answers it,
and I should have found that before framing it as new.  My own error, corrected:
I claimed live-unit-definitions.md did not exist.  It does, at docs/re/, not under
structures/.  Looking in one directory is not looking.

sub_82341A20 is the unit-definition loader, documented in unit-struct-runtime.md
with a checked-in 177-line layout at
crates/sylpheed-formats/data/unit_definition_layout.txt.  Verified independently:
3969 instructions, 227 of its 236 "addi rX, r30, -N" displacements resolve to
strings -- the unit schema in order, Generic, UncertainName, IsDestructible,
NamePlate, Size_X/Y/Z ...  Maneuver sits at exactly 0x82088F94 - 13404.

Record keys are tag_hash, confirmed on the data side: the Maneuver record's key is
0x43FAA517 = tag_hash("Maneuver"), not name_hash (0x63A248D7), x114 records.

That explains the 0-xref phenomenon and softens my own verdict from last
iteration.  Maneuver's string has 0 xrefs AND a known reader: the loader takes its
address as a register-passed base plus a displacement, which no static xref can
see.  So the AnalogRevice/Tweak verdict goes from RED to AMBER -- a
base-plus-displacement sweep over the 2283 functions forming the 0x820A high half
reaches it 0 times, but run against the unit block as a control the same sweep
recovers only 5 references and misses sub_82341A20 itself.  The measurement
stands; "the reader is unreachable" does not.

Also fixed: player-tuning-tables.md credited live-unit-definitions.md with
documenting sub_822F9498.  It documents sub_82341A20, a different function.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Claude (auto)
2026-08-27 21:02:58 +00:00
parent 909408f00d
commit 5400f5e7b5
3 changed files with 60 additions and 6 deletions

View File

@@ -4997,3 +4997,45 @@ which tracks the unit `Maneuver` 100/350/1 200 at a flat ~1.25 and misses
2 100. **Both tables cannot govern the same craft.** Cheapest next test is a
runtime one (NEEDS-HUMAN): watch which constant set reaches the live flight
struct, and re-measure with the afterburner held.
---
## ✅⚠️ 2026-08-27 — the unit loader was already in the corpus (`sub_82341A20`), and 0-xref ≠ no reader
Item (a), "what loads the 114 unit `Maneuver` records". **The corpus already
answers it and I should have found that before framing it as new.**
⚠️ **My own error, corrected:** I claimed `live-unit-definitions.md` did not
exist. It does — at `docs/re/live-unit-definitions.md`, not under `structures/`.
Looking in one directory is not looking.
**`sub_82341A20` is the unit-definition loader**, documented in
`unit-struct-runtime.md` ("Cross-validated against the loader itself,
2026-08-13") with a checked-in 177-line layout at
`crates/sylpheed-formats/data/unit_definition_layout.txt` (159 fields, 25/25
agreement with the solver). Verified independently here: 3 969 instructions, and
**227 of its 236 `addi rX, r30, -N` displacements resolve to strings** — the unit
schema in order, `Generic`, `UncertainName`, `IsDestructible`, `NamePlate`,
`Size_X/Y/Z`, … `Maneuver` sits at exactly `0x82088F94 13404`.
**Record keys are `tag_hash`, confirmed on the data side:** the `Maneuver`
record's key is `0x43FAA517` = `tag_hash("Maneuver")`, not `name_hash`
(`0x63A248D7`). ×114 records.
🔑 **And that explains the 0-xref phenomenon — which softens my own verdict from
last iteration.** `Maneuver`'s string has **0 xrefs** *and* a known reader: the
loader takes its address as a **register-passed base plus a displacement**, which
no static xref can see. So a 0-xref block is not evidence of no reader.
🟡 **Verdict on the `AnalogRevice_*`/`Tweak` block softened 🔴 → 🟡.** A
base-plus-displacement sweep over the 2 283 functions that form the `0x820A` high
half reaches it **0** times — but run against the unit block as a **control**,
the same sweep recovers only **5** references and **misses `sub_82341A20`
itself**. The measurement stands; "the reader is unreachable" does not. Recorded
in `player-tuning-tables.md`; runtime watch still the cheap way in.
⚠️ Also fixed there: the doc credited `live-unit-definitions.md` with documenting
`sub_822F9498`. It documents `sub_82341A20` — a different function.
🟡 Not settled: which table governs the measured player speeds (unchanged); a
base-tracking sweep strong enough to follow register-passed bases was not built.