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

re: effects split into two families by digit-width; ptc_pack.xpr holds one

Browse Source 
The open question was how an effect mesh is reached at all, after last
iteration's .xpr byte search was refuted by its own control. The corpus already
held the pointer: xbg7-mesh names ptc_pack.xpr, a 20 MB shared particle package
in hidden/resource3d/. It lists 532 distinct eff_* resources - 527 three-digit,
3 four-digit, 2 unnumbered.

Joining it against the 137 effect names the datasheets actually bind:

                    in ptc_pack   not
  3-digit                71        39
  4-digit                 0        27

Zero of the 27 four-digit names resolve in ptc_pack, and that series is a closed
three-letter set: e (10), f (12), n (5). Since eff_e0033 was found in Base.xpr,
the reading is two effect families - a shared three-digit particle library in
ptc_pack.xpr, and a four-digit series that lives in the per-model and base
packages instead.

The instrument passes its own control this time, which is the difference from
last iteration. The same kind of byte search demonstrably reads names out of
this file - 532 of them - so a zero WITHIN ptc_pack is meaningful in a way the
earlier disc-wide zero was not.

Among the 39 three-digit misses the letters cluster hard - j 22, t 14, m 2, h 1 -
and ptc_pack contains just one j name against 149 m and 81 s, so eff_j### is a
third grouping that is almost entirely elsewhere.

Not closed: 66 of the 137 bound effects still have no located home, eff_n0071
among them. But the route is now real and has a number on it, and the next step
is the eff_j### family and the four-digit series rather than another disc-wide
grep.

All sixteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 08:55:41 +00:00
parent dd542c23a4
commit 7e9d1437c0
2 changed files with 67 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/BACKLOG.md
View File

@@ -6677,3 +6677,33 @@ conclusion follows for `eff_e0044`/`eff_h308`, and the earlier "no mesh" remarks
about `eff_e0058`/`_e0059`/`_e0060` are weaker than written. ❔ **Open: how an
effect mesh is actually reached**, since `eff_n0071` is not a plain name string
in any of the 166 packages.
---
## 🔑 2026-08-28 — effects split into two families by digit-width; `ptc_pack.xpr` holds one
Item (a). The corpus already held the pointer — [[xbg7-mesh]] names
**`ptc_pack.xpr`**, a 20 MB shared particle package listing **532 distinct
`eff_*` resources** (527 three-digit, 3 four-digit, 2 unnumbered).
Joined against the 137 effect names the datasheets bind:
| bound name | in `ptc_pack` | not |
|---|---|---|
| **3-digit** | **71** | 39 |
| **4-digit** | **0** | **27** |
🔑 **Zero partials on the four-digit cell**, and that series is a closed
three-letter set — `e` 10, `f` 12, `n` 5. Since `eff_e0033` was found in
`Base.xpr`, the reading is **two effect families**: a shared three-digit library
in `ptc_pack.xpr`, and a four-digit series living in per-model/base packages.
⚠️ Unlike last iteration's refuted search, **this instrument passes its own
control** — the same kind of byte search demonstrably reads 532 names out of
this file, so a zero *within it* carries weight. The 39 three-digit misses
cluster on `j` (22) and `t` (14); `ptc_pack` holds just one `j` name, so
`eff_j###` is a third grouping elsewhere.
🟡 **Not closed**: 66 of 137 bound effects still have no located home,
`eff_n0071` included. ❔ Next: the `eff_j###` family and the four-digit series —
not another disc-wide grep.

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

@@ -271,3 +271,40 @@ A known-live name the test cannot find means the test has no power here. So:
Whatever ships `eff_n0071` is not a plain name string inside those 166 files,
so effect meshes must be reached some other way. Finding that route is the open
question; until then, only the positive half of this test counts.
### 🔑 Effects live in two families, split by digit-width — `ptc_pack.xpr` holds one
The open question from the last iteration was how an effect mesh is reached at
all. The corpus already had the pointer: [[xbg7-mesh]] mentions **`ptc_pack.xpr`**
and its `eff_*` entries. It is a 20 MB shared particle package in
`hidden/resource3d/`, and it names **532 distinct `eff_*` resources** — 527 of
them with a **three-digit** number, 3 with four digits, 2 unnumbered.
Joining it against the effect names the datasheets actually bind:
| bound name | in `ptc_pack` | not |
|---|---|---|
| **3-digit** (`eff_h308`, `eff_m…`) | **71** | 39 |
| **4-digit** (`eff_e0033`, `eff_n0071`) | **0** | **27** |
🔑 **Zero of the 27 four-digit names resolve in `ptc_pack`, and the four-digit
series is a closed three-letter set** — `e` (10), `f` (12), `n` (5). Meanwhile
`eff_e0033` *was* found in `Base.xpr`. So the disc carries **two effect
families**: a shared three-digit particle library in `ptc_pack.xpr`, and a
four-digit series that lives in the per-model and base packages instead.
⚠️ **The instrument passes its own control this time.** The previous iteration's
`.xpr` byte search was refuted because a known-live name returned nothing. Here
the same kind of search **demonstrably reads names out of this file — 532 of
them** — so a zero *within `ptc_pack`* is meaningful in a way the earlier
disc-wide zero was not. That is the difference between a search that has been
shown to work on the population being searched and one that has not.
Among the 39 three-digit misses the letters cluster hard: `j` 22, `t` 14, `m` 2,
`h` 1 — and `ptc_pack` contains just **one** `j` name against 149 `m` and 81 `s`.
So `eff_j###` is a third grouping that is almost entirely elsewhere.
🟡 This does not yet close the question — 66 of the 137 bound effects still have
no located home, `eff_n0071` among them. But the route is now a real one with a
number on it, and the next step is the `eff_j###` family and the four-digit
series rather than another disc-wide grep.