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

re: the object is PlayerParams, and sub_822F9498 is ITS loader -- not the unit loader

Browse Source 
Resolving every string sub_822F9498 references, in code order, gives 90, and they
are exactly the 890e1be4 object's schema in its record order: Misc (5 effect
names), SpecialAttack (+17), TacticalManeuver (+7), SpecialWeapon (+8), Booster
(+50).  It never names Generic, Maneuver, Explosion, Shield or StructureCount, and
the string Maneuver has 0 xrefs.  One call site, from sub_821A6CF0, which is
itself called once and references the literal PlayerParams.

CORRECTION to unit-datasheet-static.md, which calls sub_822F9498 the
unit-definition loader.  It loads one object: the player parameter table.  Its
AA_/AV_ interleave still stands as a struct layout, but the struct is
PlayerParams's Booster record, not each unit's Maneuver.  What loads the 114 unit
Maneuver records is now an open question -- it uses none of these strings.

Ranking all 114 units by how many of Booster's 50 values they reproduce: the top
five are exactly the five _Player units, all at 39/50; the sixth drops to 13/50;
none matches 50/50.  The five players agree with each other on all 50 -- the three
player ships share one flight model.  Booster stands alone on 10 fields; the
eleventh, AA_Yaw_Max, is 65.0 vs 65, formatting not a value (last iteration's
"11 differ" over-counted).

Still open, and sharper: nothing selects Booster.  PlayerParams is loaded once,
unconditionally, no branch -- yet the measured flight tracks the unit Maneuver
(1.25/1.20/1.28) and misses Booster badly.  Both cannot govern the same craft; the
next test is a runtime watch.

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 20:48:56 +00:00
parent 92d1a39ce2
commit 6334f36dde
4 changed files with 114 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/BACKLOG.md
View File

@@ -4951,3 +4951,49 @@ taken for ours.
🟡 Not settled: what selects the `Booster` profile; what `adv_yaw`'s non-monotone
curve indexes (unchanged — it needs the reader); why the `0x820A1xxx` block has
no xref at all when its neighbour has 36.
---
## ✅✅🔴 2026-08-27 — the object is `PlayerParams`, and `sub_822F9498` is ITS loader, not the unit loader
Item (a), "what selects the `Booster` profile". It answered a different, bigger
question and **corrected a corpus doc**. Static only; no artefact changed.
✅✅ **Resolving every string `sub_822F9498` references, in code order, gives 90 —
and they are exactly the `890e1be4` object's schema in its record order**: `Misc`
(5 effect names), `SpecialAttack` (+17), `TacticalManeuver` (+7), `SpecialWeapon`
(+8), `Booster` (+50). It **never** names `Generic`, `Maneuver`, `Explosion`,
`Shield` or `StructureCount`; the string `Maneuver` exists once and has **0
xrefs**. One call site, from `sub_821A6CF0` — itself called once, and referencing
the literal **`PlayerParams`**.
🔴 **CORRECTION to `unit-datasheet-static.md`**, which calls `sub_822F9498` "the
unit-definition loader". It loads one object: the player parameter table. Its
`AA_`/`AV_` interleave (`AV_` at `X`, `AA_` at `X+8`, five axes) **still stands as
a struct layout — but the struct is `PlayerParams`'s `Booster` record**, not each
unit's `Maneuver`. Note added in place. ⇒ ❔ **What loads the 114 unit `Maneuver`
records is now an open question** — it uses none of these name strings.
🟡 `PlayerParams` hashed under 7 prefixes × 6 spellings × both hash families (84
combinations) hits the key `0x890E1BE4` **0 times**: the string names the table to
the code, not the pak entry.
⚠️ The loader names **8** `SpecialWeapon` fields; the disc values **7** —
`HPRegenerator_Quantity` is named and never valued.
✅ **Ranking all 114 units by how many of `Booster`'s 50 values they reproduce:
the top five are exactly the five `_Player` units** (`f001_T`, two `f001_T_Tt`,
`f002_W`, `f004_A`), all at **39/50**; the sixth drops to **13/50**; **none
matches 50/50**. And the five players **agree with each other on all 50** — the
three player ships share one flight model. `Booster` stands alone on **10**
fields. ⚠️ Correcting myself: the eleventh, `AA_Yaw_Max`, is `65.0` vs `65` —
formatting, not a value. Last iteration's "11 differ" over-counted.
🟡 **NOT SETTLED, and it is now sharper: nothing selects `Booster`.**
`PlayerParams` is loaded **once, unconditionally** — one call site, one caller, no
branch. Yet `flight-speed-law.md` clocked the player at ~125 / ~420 / ~1 530,
which tracks the unit `Maneuver` 100/350/1 200 at a flat ~1.25 and misses
`Booster`'s 100/612/2 100 badly; the `RT`-held run reached ~1 530, nowhere near
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.