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 1265512880
commit aa478d9444
2 changed files with 74 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/BACKLOG.md
View File

@@ -6763,3 +6763,34 @@ one is a field name.
⚠️ **Still unlocated as assets** — knowing the family and its naming law does not
say where the geometry lives. The `.xpr` route is exhausted and the parsed pak
payloads hold references, not meshes. ❔ Open: which package (if any) ships them.
---
## ✅ 2026-08-28 — the faction law generalises: 564 of 564, four fields, six paks
Item (a). The previous entry measured `_e`/`_f` on one pak through the effect
binders only. 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; the mismatch residual is empty.** It holds separately at 100% in
four fields — `LowerHPFxModel` 252, **`ShieldHitEffectName` 210**,
**`ShieldRecoverEffectName` 84**, `ExplosionFxModel` 18. The two shield fields
are new to the law, so it reaches past the `*FxModel` family that suggested it.
⚠️ **Scope stated exactly**: this is a law about *effects*, not assets generally.
Every `_e`/`_f`-suffixed value a unit binds lives in those four effect fields —
no model, motion or SE value carries the suffix, so the pairing is **not** shown
for those kinds; there was nothing to test.
✅ **`UN_n###` (TTRL) binds no `_e`/`_f` in any of the six paks** — 12 objects
(= 2 users), confirming the single-pak observation over the whole population.
⚠️ **ID-grammar correction + reconciliation**: the earlier 42+26+2 = 70 used a
regex requiring `UN_<l>###_<FACTION>_`; the looser form finds **71**. The extra
is **`UN_e910_core_ADAN_GeneratorCore`**, which inserts a sub-kind before the
faction tag. Grammar is `UN_<l>###_[<subkind>_]<FACTION>_<name>`.

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.