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

re: the proven offsets ARE candidates -- these mis-anchors are selection failures

Browse Source 
debug_vertex_run_starts exposes the anchor scan's candidate list: Stage_S01 has
15710 stride-24 starts and all three capture-proven offsets (0x3c55d8 twin,
0x40e418 bridge, 0x44a32c eng_02_l) are among them. anchor_pool_mesh takes the
first that validates, so an earlier lookalike wins. Scoped to the current
decoder's e106 cases; does not overturn the residual-51 finding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 02:11:41 +00:00
parent 26f1bdf6fd
commit 76a433f75c
4 changed files with 65 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/captures/stage-s01-capture-truth-offsets.txt
View File

@@ -1,15 +1,15 @@
file offset vcount claimed by our decode our resources with that vcount
0x38788 181 — NOBODY — none
0x4b8b8 93 — NOBODY — none
0xb6574 41 — NOBODY n042_bdy_m e007_bdy_01 @ -0x24864
0xdbbac 77 — NOBODY — none _rou_e010_break @ -0x5050
0x133da0 76 — NOBODY e303_wep_01_m, n041_bdy_l _rou_e010_break @ -0x407bc
0x162840 60 — NOBODY — none _rou_e010_break @ -0x6f25c
0x3b3ee8 119 e106_bdy_01_l(119), e106_bdy_02_l(119) e106_bdy_01_l, e106_bdy_02_l e106_bdy_01_l @ -0x0
0x3c55d8 119 — NOBODY e106_bdy_01_l, e106_bdy_02_l e106_bdy_01_m @ -0x104e8
0x3dd2c4 146 e106_bdy_03_l(146) e106_bdy_03_l e106_bdy_03_l @ -0x0
0x40763c 179 e106_bdy_04_l(179) e106_bdy_04_l e106_bdy_04_l @ -0x0
0x40e418 51 — NOBODY e106_brg_01_b_02, e106_brg_01_l e106_brg_01_b_02 @ -0x5d0
0x444ccc 58 e106_eng_01_l(58) e106_eng_01_l e106_eng_01_l @ -0x0
0x44a32c 44 — NOBODY e106_eng_02_l e106_eng_02 @ -0x35b8
0x45705c 82 e106_wep_02_01_l(82) e106_wep_02_01_l e106_wep_02_01_l @ -0x0
file offset vcount candidate claimed by our decode our resources with that vcount
0x38788 181 NO — NOBODY — none
0x4b8b8 93 NO — NOBODY — none
0xb6574 41 NO — NOBODY n042_bdy_m e007_bdy_01 @ -0x24864
0xdbbac 77 NO — NOBODY — none _rou_e010_break @ -0x5050
0x133da0 76 NO — NOBODY e303_wep_01_m, n041_bdy_l _rou_e010_break @ -0x407bc
0x162840 60 NO — NOBODY — none _rou_e010_break @ -0x6f25c
0x3b3ee8 119 yes e106_bdy_01_l(119), e106_bdy_02_l(119) e106_bdy_01_l, e106_bdy_02_l e106_bdy_01_l @ -0x0
0x3c55d8 119 yes — NOBODY e106_bdy_01_l, e106_bdy_02_l e106_bdy_01_m @ -0x104e8
0x3dd2c4 146 yes e106_bdy_03_l(146) e106_bdy_03_l e106_bdy_03_l @ -0x0
0x40763c 179 yes e106_bdy_04_l(179) e106_bdy_04_l e106_bdy_04_l @ -0x0
0x40e418 51 yes — NOBODY e106_brg_01_b_02, e106_brg_01_l e106_brg_01_b_02 @ -0x5d0
0x444ccc 58 yes e106_eng_01_l(58) e106_eng_01_l e106_eng_01_l @ -0x0
0x44a32c 44 yes — NOBODY e106_eng_02_l e106_eng_02 @ -0x35b8
0x45705c 82 yes e106_wep_02_01_l(82) e106_wep_02_01_l e106_wep_02_01_l @ -0x0

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

@@ -653,6 +653,27 @@ could not: `0x3b3ee8` stays with whichever twin we already decode there, and the
other twin must move to `0x3c55d8`. The invariant is checkable without a capture
— *mirrored twins must decode to X-reflected buffers, never identical ones*.
**4. Root cause, for these three: selection, not the run scan.**
`mesh::debug_vertex_run_starts` exposes the candidate list the anchor scan works
from. `Stage_S01` yields **15 710** stride-24 candidate starts, and **all three
capture-proven offsets are in it** — `0x3c55d8` (the mirrored twin), `0x40e418`
(the drawn bridge buffer) and `0x44a32c` (`eng_02_l`). The scan sees the right
offsets; `anchor_pool_mesh` walks the list in ascending order and takes the first
that validates, so an earlier lookalike wins — our bridge resources sit `0x5d0`
before the buffer the engine drew.
This is scoped: it says the *current* decoder's e106 mis-anchors are selection
failures. It does not overturn the earlier finding that the residual 51 *under
the withdrawn neighbourhood fix* had no validating candidate at all — a different
population, and the two can both be true.
What the twins suggest as the fix: selection is **per-resource and greedy**, so
two resources can and do claim one buffer while a validating buffer sits unused.
An assignment that is distinct by construction — each candidate used at most once
— resolves the twin case by shape rather than by heuristic. Whether the proven
offsets actually validate for their resources is the next thing to test; if they
do, distinctness alone is the fix.
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.