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

re: the capture is Stage_S02 -- provenance corrected, oracle grows to 46 buffers

Browse Source 
capture_truth_scan places every drawn buffer across all 166 containers by modal
vbase-offset. Stage_S02 wins with 64 matches at one constant against Stage_S01's
16, and the logs carry f101/f105/f106/e105 -- a Stage-02 cast. Stage_S01 looked
consistent because the shared block is duplicated verbatim (twins 0x116F0 apart
in both), so the earlier structural findings hold; only the loaded-container
claim was wrong. The S02 table places 46 buffers, 12 claimed by nobody, and
resolves the six Stage_S01 mystery buffers as e105 parts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 02:59:40 +00:00
parent df7a10749a
commit b58f42e46d
3 changed files with 191 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/structures/xbg7-mesh.md
View File

@@ -781,6 +781,38 @@ capture covering more ships and stages (the same `--truth` method extends to any
container the engine drew from) or a discriminator that does not degrade for
coarse geometry. Both are recorded as the next step rather than guessed at.
**8. Provenance correction — the capture is `Stage_S02`, and the oracle is
4× bigger than reported.** `examples/capture_truth_scan.rs` runs the
offset-locating pass over **every** container in `resource3d` and reports each
one's modal `vbase − offset`. `Stage_S02` places **64** buffer-matches at a
single constant (`0x17FE3FF4`); `Stage_S01`, which sections 1–7 above used,
places only 16. The logs also contain `f101` (the ACROPOLIS escort, 25 448
verts), `f105`/`f106` (TCAF cruiser and destroyer) and `e105` — a Stage-02 cast.
**The loaded container was `Stage_S02`.**
Why `Stage_S01` nevertheless produced a consistent constant: the two containers
carry the shared block **verbatim and contiguously**. The e106 twin buffers sit
at `0x3b3ee8`/`0x3c55d8` in `Stage_S01` and `0x2d1fee8`/`0x2d315d8` in
`Stage_S02` — the same `0x116F0` apart. So the earlier findings are still true
statements about `Stage_S01`'s content (both mirrored buffers are in it, and our
decoder collapses them), and they reproduce in `Stage_S02`; only the claim that
`0x1A94FFF4` was *the loaded container's* base was an artifact.
The `Stage_S02` table
([`captures/stage-s02-capture-truth-offsets.txt`](../captures/stage-s02-capture-truth-offsets.txt))
places **46 drawn buffers**: 34 have a claimant (29 of them a single resource of
exactly the drawn size), **12 are claimed by nobody**. It also resolves the six
mystery buffers of the `Stage_S01` table — 181, 93, 77, 76, 60, 41 vertices —
as **`e105` parts** (`bdy_04_l`, `bdy_05_l`, `brg_l`, `eng_01_l`, `wep_01_l`),
another ship in the same mission, several of which are the same "right size,
wrong place" failure as `eng_02_l`.
❔ **A new defect class to chase**: `_rou_f105_break` — a destruction composite —
claims a run of **twelve consecutive** drawn offsets whose sizes match *other*
ships' LODs (`f105_bdy_01_m`, `f105_bdy_03_m`, `e106_wep_02_01_l`, …). Either the
break model genuinely mirrors those buffers or our decoder is handing a whole
address range to one composite. Not resolved here.
Not settled: `e106_brg_01_b_02` ≡ `e106_brg_01_l` (51 verts). A second 51-vertex
`vbase` exists in the logs but is **not** from this container, and the container
holds three near-identical 51-vertex runs, so the pair has no oracle yet.