From 1396447dad6aea2e1e763c2116481733471b8b69 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Thu, 13 Aug 2026 10:20:00 +0000 Subject: [PATCH] re(xbg7): a Stage-05 capture validates the pad fix out of sample, and shows how containers load MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ran ship_capture_close.sh in story stage 05 (reachable now via the save's stage field) instead of stage 02: 3 logs, ~11 200 draws. - Out-of-sample check of the pad-scoring fix: 124 of 124 index runs identical to the GPU's, 2 769 index elements, 0 differing — on draws the fix was not derived from (the stage-02 capture gave 93/93). - A mission keeps SEVERAL stage containers resident: 65 drawn buffers place in Stage_S02.xpr at 0x17FE3FF4 (the shared TCAF/ADAN fleet) and 5 in Stage_S05.xpr at its own constant 0x1927B7F4 (the f101 ACROPOLIS, this mission's escort) — the first capture-truth rows for a container other than Stage_S02. Both sets have exact index counts and exact coverage. - Why: f105_bdy_01 lives in 13 of the 22 stage containers and not in Stage_S05 at all, so the resident set follows the mission's unit roster, not the stage number. Consequence for the residual misses: a different story stage is not a different container. Aiming a capture at a specific container is a static question (resource names per container x the stage's EnumUnit roster). Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01NptfmpjdpNCKEez6d2xvA9 --- docs/re/structures/xbg7-mesh.md | 42 +++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md index e20e893d..30d54b98 100644 --- a/docs/re/structures/xbg7-mesh.md +++ b/docs/re/structures/xbg7-mesh.md @@ -1508,3 +1508,45 @@ decode `_rou_f402_dead` to a *clean but wrong* block, so several degenerate-free candidates exist and file order picks badly. The majority span would separate them — but "flag, don't silently rewrite geometry on a vote" still stands, so this needs the box-identity data, or a capture of a stage that draws it. + +### A capture from a DIFFERENT mission — out-of-sample validation, and how containers get loaded (2026-08-13) + +With the stage now selectable from a hand-edited save +([savegame notes](savegame-format.md#-solved-52-is-the-stage-and-the-save-picks-the-mission-2026-08-13)), +`ship_capture_close.sh` was run in **story stage 05** (`Lebendorf_far`, the Gallia +asteroid field) instead of stage 02 — three logs, ~11 200 draws, target +`UN_f105_TCAF_Cruiser` closed to 1 375 units. + +**The pad fix validates out of sample.** These draws had no part in deriving it: + +``` +index runs compared: 124 identical · 0 differing · 4 no decoded resource +2 769 index elements checked against the GPU +``` + +So 124/124 index runs from a mission the fix never saw agree byte for byte, on top +of the 93/93 from the stage-02 capture. + +**A mission has SEVERAL stage containers resident, and the drawn buffers split +between them.** Scoring the same logs against two containers: + +| container | its own load constant | drawn buffers placed | what they are | +|---|---|---|---| +| `Stage_S02.xpr` | `0x17FE3FF4` (same as the stage-02 run) | **65** | the shared TCAF/ADAN fleet — `f105_*`, `e105_*`, `e106_*`, `f106_*`, `_rou_*` | +| `Stage_S05.xpr` | `0x1927B7F4` | **5** | the **f101 ACROPOLIS** (`bdy_01/02/03`, `eng_01`, `wep_01`) — the mission's escort | + +Both sets have exact index counts and exact pool coverage, so both placements are +real. The split is explained by content, not by guesswork: `f105_bdy_01` is in +**13 of the 22** stage containers and **not in `Stage_S05.xpr` at all**, while the +f101 parts the engine drew match S05's own copy. So the resident set follows the +**mission's unit roster** — every mission that fields the common fleet pulls the +container that holds it (`Stage_S02.xpr`, the largest at 57 MB), while its own +container supplies what is unique to it. + +**Consequence for the remaining 82–85 misses:** flying a different *story* stage +is not the same as reaching a different *container*. To cover a specific container +one has to pick a mission whose roster contains units that live **only** there — +which is a static question (resource names per container × the stage's +`EnumUnit_SNN` roster), not another capture run. That is the cheap way to aim the +next capture, and the first-ever truth rows for a non-`Stage_S02` container (the +five f101 rows above) show the method works the moment the roster does.