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

re: the faction law generalises - 564 of 564, four fields, all six paks

Browse Source 
The previous commit measured _e/_f on one pak and only through the effect
binders. Widening the sweep to EVERY string field of every unit object in ALL
SIX GP_MAIN_GAME_* paks:

                value _e   value _f
  UN_e###          198          0
  UN_f###            0        366

564 of 564 agree and the mismatch residual is empty. The law is not confined to
one field either - it holds separately, at 100%, in each of four:

  LowerHPFxModel            252 of 252
  ShieldHitEffectName       210 of 210
  ShieldRecoverEffectName    84 of 84
  ExplosionFxModel           18 of 18

The two shield fields were not in the earlier measurement at all, so the law
reaches further than the *FxModel family that suggested it.

Scope stated exactly, because "general" would overclaim: this is a law about
EFFECTS, not about assets in general. The sweep covered every field, and every
_e/_f-suffixed value a unit binds turns out to live in those four effect fields.
No model, motion or SE value carries the suffix at all, so the faction pairing is
NOT shown for those kinds - there was simply nothing to test.

UN_n### (TTRL) binds no _e/_f value in any of the six paks: 12 objects, = 2
users, with nothing on either side. That confirms over the whole population what
was only a single-pak observation before.

Also corrects the ID grammar and reconciles a count. The earlier section reported
42 + 26 + 2 = 70 unit objects using a regex that required UN_<letter>###_<FACTION>_;
the looser UN_<letter>###_ finds 71. The extra one is UN_e910_core_ADAN_GeneratorCore,
which inserts a sub-kind token BEFORE the faction tag. So the grammar is
UN_<letter>###_[<subkind>_]<FACTION>_<name>, and both counts were right for their
own pattern.

All seventeen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 09:44:20 +00:00
parent 122a05735d
commit 3c8a30aefb
2 changed files with 74 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/re/structures/unit-substructure-records.md
View File

@@ -402,3 +402,46 @@ records.
their geometry lives; the `.xpr` route is exhausted for them and the parsed pak
payloads hold references, not meshes. Worth stating plainly: this iteration
identified the family and its naming law, not the missing package.
### ✅ The faction law holds across all six paks and four fields — 564 of 564
The previous section measured `_e`/`_f` on one pak and only through the effect
binders. Widening to **every string field** of every unit object in **all six**
`GP_MAIN_GAME_*` paks:
| | value `_e` | value `_f` |
|---|---|---|
| **`UN_e###`** | **198** | 0 |
| **`UN_f###`** | 0 | **366** |
**564 of 564 agree; the mismatch residual is empty.** And the law is not confined
to one field — it holds separately, at 100%, in each of four:
| field | agree |
|---|---|
| `LowerHPFxModel` | 252 of 252 |
| `ShieldHitEffectName` | 210 of 210 |
| `ShieldRecoverEffectName` | 84 of 84 |
| `ExplosionFxModel` | 18 of 18 |
Two of those — `ShieldHitEffectName` and `ShieldRecoverEffectName` — were not in
the earlier measurement at all, so the law reaches further than the `*FxModel`
family that suggested it.
⚠️ **But state the scope exactly: this is a law about *effects*, not about assets
in general.** The sweep covered every field, and *every* `_e`/`_f`-suffixed value
a unit binds turns out to live in those four effect fields. No model, motion or
SE value carries the suffix at all — so the faction pairing is **not** shown for
those kinds; there was simply nothing to test. "General across fields" here means
general across the fields that use it.
✅ **`UN_n###` (TTRL) binds no `_e`/`_f` value in any of the six paks** — 12
objects (= 2 users) with nothing on either side, confirming the earlier
single-pak observation over the whole population.
⚠️ **A correction to the ID grammar, and a reconciliation.** The earlier section
counted 42 + 26 + 2 = 70 unit objects using a regex that required
`UN_<letter>###_<FACTION>_`; the looser `UN_<letter>###_` finds **71**. The one
extra is **`UN_e910_core_ADAN_GeneratorCore`**, which inserts a sub-kind token
*before* the faction tag. So the ID grammar is `UN_<letter>###_[<subkind>_]<FACTION>_<name>`,
and both counts were right for their own pattern.