From 7e9d1437c0cee76d93b14822a8f4b83e29e73fa7 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 08:55:41 +0000 Subject: [PATCH] re: effects split into two families by digit-width; ptc_pack.xpr holds one 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. --- docs/re/BACKLOG.md | 30 +++++++++++++++ .../structures/unit-substructure-records.md | 37 +++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 9cabdf10..3536d12c 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -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. diff --git a/docs/re/structures/unit-substructure-records.md b/docs/re/structures/unit-substructure-records.md index 28345b05..8657844a 100644 --- a/docs/re/structures/unit-substructure-records.md +++ b/docs/re/structures/unit-substructure-records.md @@ -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.