re: every bound effect vs every declared effect; a Shift-JIS dev placeholder

The Explosion substructure's field list was already in the corpus, so the open
part was whether the effect names RESOLVE. Declared x used, sweeping 34 binder
field names (*FxModel*, *EffectName, Effect_*, ShellModel, CoverModel,
SilhouetteModel) against every name declared by a LOD_Effect_<n> or
GameModel_<n> field anywhere on the disc:

                 declared   not declared
  used              172          58
  not used          318           -

490 declared, 230 used. Top binders: Effect_Paralyze 2874, ShellModel 996,
HitFxModel 738, JetFxModel_000 408, MuzzleFlashFxModel_Loop 384.

The 58-cell is almost one field. 53 of the 58 are bound by SilhouetteModel
alone and are all rou_f###_wep* names - the arsenal item silhouettes already
documented in arsenal-item-weapon-chain. They are undeclared because they are
the wrong KIND: each resolves as its own standalone package, rou_f001_wep_01.xpr
and friends, never as a LOD-table entry. Nothing is missing; the sweep was
reading an asset-file name as though it were an effect name. That leaves four
genuinely undeclared effects - eff_e0044, eff_f0002, eff_f0002_barn, eff_h308 -
none of which resolves as a record or field name either.

One "effect name" in that cell is not a name at all. Bound by Effect_Explosion
and Effect_Flare, 72 occurrences = 12 users, its bytes are 95 B6 8E 9A 97 F1 -
Shift-JIS for the word "character string". A developer's placeholder. This
exposes a reader defect worth fixing before these strings reach a port:
unitgroup.py hands the value back as Latin-1 mojibake, so an IDXD string field
can carry Shift-JIS and our decode does not know it.

Following the silhouettes into the ISO tree turned up a convention that IS real:
59 of the 166 .xpr packages end _hangar.xpr, and 59 of 59 have a bare twin of
the same stem. The direct contrast to yesterday's refutation, where _all/_child
was 1 of 166 with a single stem. Suffix conventions in this corpus are worth
testing precisely because they are not all real.

Controls reproduced from the previous iteration: eff_n0071 is declared and used
6x (= one user under the per-pak-copy rule); eff_e0033 is declared and used 0x,
sitting in the 318-cell. That cell is expected rather than alarming - the
EnumLODSet/EnumGameModel family is overwhelmingly equipment, which no unit
datasheet binds.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 08:05:28 +00:00
parent 25b5f60ea1
commit 44bdbad2d6
2 changed files with 93 additions and 0 deletions

View File

@@ -6586,3 +6586,35 @@ the shipped `_test` table omits while the game still binds it elsewhere.
`Effect_Paralyze` (2 874), `HitFxModel` (738), `ShellModel` (516),
`JetFxModel_00N`, `MuzzleFlashFxModel_Loop` — so a value resolving through none
of them is genuinely unreferenced, not missed by a narrow search.
---
## ✅ 2026-08-28 — every bound effect vs every declared effect; a Shift-JIS placeholder
Item (a). The `Explosion` field list was already in
`unit-substructure-records.md`; the untested part was whether the effect names
**resolve**. Declared × used over **34 binder fields**:
| | declared | not declared |
|---|---|---|
| **used** | **172** | **58** |
| **not used** | **318** | — |
🔑 **The 58-cell is almost one field**: 53 are bound by `SilhouetteModel` and
are all `rou_f###_wep*` arsenal silhouettes ([[arsenal-item-weapon-chain]]) —
undeclared because they are **the wrong KIND**, each resolving as its own
package (`rou_f001_wep_01.xpr`), never as a LOD entry. Four effects are
genuinely undeclared: `eff_e0044`, `eff_f0002`, `eff_f0002_barn`, `eff_h308`.
🔑 **`文字列` is a dev placeholder.** One "effect name" is Shift-JIS
`95 B6 8E 9A 97 F1` = *"character string"*, bound by `Effect_Explosion` /
`Effect_Flare` 72× = 12 users. ⚠️ **Reader defect**: `unitgroup.py` returns it
as Latin-1 mojibake — IDXD string fields can be Shift-JIS.
**`_hangar` IS a convention — 59 of 166 `.xpr`, 59/59 with a bare twin.**
The direct contrast to yesterday's `_all`/`_child` refutation (1 of 166). Suffix
conventions here are worth testing precisely because they are not all real.
⚠️ Controls reproduced: `eff_n0071` declared + used 6× (= one user);
`eff_e0033` declared + used 0×. The 318-cell is expected — the LOD family is
overwhelmingly *equipment*, which no unit datasheet binds.

View File

@@ -190,3 +190,64 @@ same record family without being counted. Consistent across both, n=2, so
above**: a 6-bit mount mask. Which sector each bit means is still open.
* The 6 `no field` comparisons are one unit whose `StructureCount` omits every
count.
## ✅ Every effect a datasheet binds, against every effect the LOD tables declare
The `Explosion` substructure's field list is already above; what was untested is
whether its `ExplosionFxModel` — and the whole effect-binder family — actually
*resolves*. Run as a declared × used partition, sweeping **34 binder field
names** (`*FxModel*`, `*EffectName`, `Effect_*`, `ShellModel`, `CoverModel`,
`SilhouetteModel`) against every name declared by a `LOD_Effect_<n>` or
`GameModel_<n>` field anywhere on the disc:
| | declared | not declared |
|---|---|---|
| **used** | **172** | **58** |
| **not used** | **318** | — |
490 declared, 230 used. The top binders are `Effect_Paralyze` (2 874 values),
`ShellModel` (996), `HitFxModel` (738), `JetFxModel_000` (408),
`MuzzleFlashFxModel_Loop` (384).
🔑 **The 58-cell is almost one field.** 53 of the 58 are bound by
**`SilhouetteModel`** alone, and all 53 are `rou_f###_wep*` names — the arsenal
item silhouettes already documented in [[arsenal-item-weapon-chain]]. They are
undeclared because they are **the wrong kind**: each resolves as its own
standalone package, e.g. `rou_f001_wep_01.xpr`, and never as a LOD-table entry.
Nothing is missing — the sweep was reading an asset-file name as if it were an
effect name.
That leaves **four genuinely undeclared effects**`eff_e0044`
(`ExplosionFxModel`), `eff_f0002` + `eff_f0002_barn` (`JetFxModel_00N` /
`AfterBurnerFxModel_00N`) and `eff_h308` (`HitFxModel`) — plus one placeholder
(below). None of the four resolves as a record name or a field name either.
⚠️ Controls, both from the previous iteration and both reproduced: `eff_n0071`
is **declared and used 6×** (= one user, per the per-pak-copy rule);
`eff_e0033` is **declared and used 0×**, i.e. it sits in the 318-cell. The 318
is expected rather than alarming — the `EnumLODSet`/`EnumGameModel` family is
overwhelmingly *equipment*, so most of what it declares no unit datasheet binds.
### 🔑 A Shift-JIS dev placeholder: `文字列`
One "effect name" in the 58-cell is not a name at all. Bound by
`Effect_Explosion` and `Effect_Flare`, **72 occurrences = 12 users**, its bytes
are `95 B6 8E 9A 97 F1` — Shift-JIS for **`文字列`**, literally *"character
string"*. It is the placeholder a developer left in the field.
⚠️ **Reader defect this exposes:** `tools/re-capture/unitgroup.py` hands the
value back as Latin-1 mojibake (`¶ñ`), so an IDXD string field can carry
**Shift-JIS** and our decode does not know it. Worth fixing before any of these
strings reach a port; harmless for name-matching, because every other value in
the corpus is ASCII.
### ✅ `_hangar` *is* a package-naming convention — 59 of 166, zero partials
Following the silhouettes into the ISO tree: **59 of the 166 `.xpr` packages end
`_hangar.xpr`, and 59 of 59 have a bare twin** of the same stem. So a model
shown in the hangar ships as a second package beside the in-flight one.
This is the direct contrast to the previous iteration's refutation — `_all` /
`_child` was **1** of 166 with one stem and is not a convention; `_hangar` is
**59** of 166 with zero partials and is. Suffix conventions in this corpus are
worth testing precisely because they are not all real.