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

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>`.