Claude (auto-RE)
ca500c171e
Tier 3 matched a part to its hardpoint by trailing index, so `e105_brg` compared "01" == "" against GN_Bridge_01 and fell through silently. The runtime capture is what exposed it: the game draws the bridge and places it at [0, 70, -1850] rel e105_bdy_01, and assemble_ship emitted nothing there. With no index to match on, take the lowest-numbered frame of the category. Diffing assemble_ship part counts across every container: 34 (stage, ship) entries gain parts — e102 +2 (bridge and engine), e104 +1, e105 +1, Stages 02-29. ship_audit is unchanged, so nothing regressed, and the capture now agrees to dT 0.03 / dR 0.000. Also fixes the diff itself: correlate_frames compared static against a rotation sampled from the first block, which can belong to another INSTANCE of the class. Scoped to the position-agreeing cluster, e105_eng_01 goes 1.711 -> 0.000 and both e106 nacelles to 0.000. The one remaining rotation delta (e106_wep_02_01, 0.134) is a turret whose rotation varies by 0.182 between blocks that agree on its position — the runtime disagrees with itself more than with the assembler. The new rotVar column makes that distinction visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.3 KiB
RE backlog
Open items that are not being worked right now. Each entry says what is wrong or
unknown, what evidence exists, and what the first step would be. Move an item into
INDEX.md (with a structures/…md or a parser + test) once it is actually settled.
Capital ships assemble wrong in the viewer
Reported: 2026-07-30, by the user. Status: 🔎 diagnosed 2026-08-10 — the
format layer is exonerated. Runtime captures of three classes (f105, e105,
e106) at controlled range reproduce assemble_ship to ≤0.43 units in translation
and to 0.000 in rotation for every part that does not move; see
ship-placement-capture-generalisation.md
§4. So look at the viewer: first that it passes include_external = true
(iso_loader.rs:4012 — with false an e106 loses its bridge and both nacelles,
5 parts instead of 11), then its own transform stack.
One real format-side bug was found on the way and is fixed: index-less parts
(e105_brg) never matched their GN_Bridge_01 hardpoint, so 34 (stage, ship) entries
— e102, e104, e105 across Stages 02–29 — assembled without a bridge. The other
apparent exception (e105_eng_01 rotation) was an aggregation artefact and is 0.000.
The original report and its reasoning follow.
The reborn viewer builds capital ships from the split XBG7 parts via
sylpheed-formats::ship::assemble_ship, and they come out wrong — parts in the
wrong place / wrong orientation.
Why this is a real finding and not a known limitation: the RE write-up
ship-placement-runtime-capture.md declares
static assembly ✅ exact as of 2026-07-26 — 9-channel joint tables
[TX TY TZ RY RX RZ SX SY SZ], Euler Ry·Rx·Rz, with
ship::tests::static_assembly_matches_runtime_capture asserting static == runtime
capture (T < 1.0, R < 0.02). So either the viewer is not using that path, or the
claim generalises worse than the test suggests.
The likely gap: that test is one ship — the e106 destroyer, 8 parts plus
two nacelles, two turrets and the hull mirror. Nothing pins the other classes.
Rules that were derived from e106 and could easily be e106-specific:
- the engine cluster rig mounted at
GN_Engine_01(two mirrored nacelles + centre); - "X-reflect the shared-geometry twin whose lateral offset opposes the geometry's dominant side" — a heuristic, not a decoded flag;
- cross-id turret instancing (×2).
First step (the oracle already exists): re-run the runtime capture on a different
capital ship and diff static vs captured, exactly as e106 was done — F10 in the
capture-ship-placement build of xenia-canary-native dumps the ship shader's
c0..c2 WorldViewProjection rows per part; WV_ref⁻¹ · WV_p is the ship-space rigid
transform, which is ground truth. Pick a class whose rig differs from e106
(different engine count, a ship with no sld, a carrier). Then extend
static_assembly_matches_runtime_capture into a per-ship table so a regression in one
class cannot hide behind e106 passing.
Also worth ruling out first, cheaply: that the viewer's own transform stack (scale,
handedness, node-instance recursion) is not re-breaking a correct assembly — compare
the viewer's placement against assemble_ship's output directly before blaming the
format layer.