re: kill the duplicate-resource-name hypothesis for the viewer bug, and reconcile 22 vs 16 stages
build_ship_model resolves each placement with find(|m| m.name == p.resource) -- first match wins -- so a repeated resource name inside a container would draw the wrong geometry. It cannot happen: decoding every XBG7 resource in all 22 stage containers gives 4603 resources and ZERO repeated names. Per ship it is tighter still: e106 wants 9 distinct names and decodes exactly 9 models for 11 placements, e105 9 for 9, f105 5 for 6. Two of the three remaining candidates for the user-reported viewer bug are now gone (this and include_external), leaving mirror handling and the exhaust cones, plus the untried visual comparison. The container sweep also reconciles a number I flagged earlier: the disc has 22 stage CONTAINERS -- Stage_S01..S16 plus Stage_S24..S29 -- i.e. 16 story stages plus 6 extra. The save screen's 16 STAGE sprites and the notes' "22 stages" are both right and count different things; neither gets edited to match the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -81,3 +81,35 @@ a resource name repeats, and the exhaust cones. **Next step is a visual**: the
|
|||||||
diagnosis has run out of things it can settle by reading, so the viewer needs to
|
diagnosis has run out of things it can settle by reading, so the viewer needs to
|
||||||
be run against a known-good class (`e106`) and its render compared with
|
be run against a known-good class (`e106`) and its render compared with
|
||||||
`ship_render`'s.
|
`ship_render`'s.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Viewer: the duplicate-resource-name hypothesis is dead too
|
||||||
|
|
||||||
|
**Checked 2026-08-11.** The diagnosis above left three candidates for why capital
|
||||||
|
ships assemble wrong in the viewer: mirror handling, `Xbg7Model::models_named`
|
||||||
|
resolving the wrong sub-model when a resource name repeats, and the exhaust
|
||||||
|
cones. The second is now **refuted**, and comprehensively.
|
||||||
|
|
||||||
|
`build_ship_model` resolves each placement with
|
||||||
|
`base.iter().find(|m| m.name == p.resource)` (`iso_loader.rs:4041`) — first match
|
||||||
|
wins — so a repeated resource name inside a container would silently draw the
|
||||||
|
wrong geometry. It cannot happen: decoding **every** XBG7 resource in **all 22
|
||||||
|
stage containers** gives **4 603 resources and zero repeated names**.
|
||||||
|
|
||||||
|
```
|
||||||
|
Stage_S01 62/62 Stage_S07 323/323 Stage_S13 290/290 Stage_S25 351/351
|
||||||
|
Stage_S02 304/304 Stage_S08 388/388 Stage_S14 22/22 Stage_S26 318/318
|
||||||
|
Stage_S03 214/214 Stage_S09 316/316 Stage_S15 386/386 Stage_S27 321/321
|
||||||
|
Stage_S04 179/179 Stage_S10 7/7 Stage_S16 65/65 Stage_S28 118/118
|
||||||
|
Stage_S05 92/92 Stage_S11 157/157 Stage_S24 162/162 Stage_S29 386/386
|
||||||
|
Stage_S06 266/266 Stage_S12 376/376
|
||||||
|
```
|
||||||
|
|
||||||
|
Per-ship it is tighter still: `e106` wants 9 distinct names and decodes exactly
|
||||||
|
9 models for 11 placements; `e105` 9 for 9; `f105` 5 for 6. Every placement
|
||||||
|
resolves to the one model it names.
|
||||||
|
|
||||||
|
**So two of the three candidates are gone** (this one and `include_external`),
|
||||||
|
leaving **mirror handling** and **the exhaust cones** — and the still-untried
|
||||||
|
visual comparison, which remains the right next step.
|
||||||
|
|||||||
@@ -448,9 +448,11 @@ Three things fall out, none of which needed the emulator:
|
|||||||
shows as `At Standby`), `STATE_STAGE_CLEAR`, `STATE_GAME_CLEAR`.
|
shows as `At Standby`), `STATE_STAGE_CLEAR`, `STATE_GAME_CLEAR`.
|
||||||
- **The screen can label exactly 16 stages**, `STAGE01`…`STAGE16`. That matches
|
- **The screen can label exactly 16 stages**, `STAGE01`…`STAGE16`. That matches
|
||||||
`weapon.tbl`'s `AUTO_SETTINGS` list — `stage01…16` plus `tutorial01…06` and
|
`weapon.tbl`'s `AUTO_SETTINGS` list — `stage01…16` plus `tutorial01…06` and
|
||||||
`challenge01…06` — so **16 is the story-stage count**, and the "22 stages"
|
`challenge01…06` — so **16 is the story-stage count**. ✅ **The "22 stages"
|
||||||
figure used elsewhere in these notes counts a different set (🟡 probably story
|
figure used elsewhere in these notes is now reconciled**: the disc carries 22
|
||||||
plus challenge). Worth reconciling before either number is relied on.
|
stage *containers*, `Stage_S01…S16` **plus `Stage_S24…S29`** — 16 story + 6
|
||||||
|
extra. Both numbers are right; they count different things, and neither should
|
||||||
|
be edited to match the other.
|
||||||
|
|
||||||
The panel's own field names are here too, with their screen positions:
|
The panel's own field names are here too, with their screen positions:
|
||||||
`Points`, `FlightTime` (`%03d:%02d:%02d`), `ClearTimes`, `CompletionRate`,
|
`Points`, `FlightTime` (`%03d:%02d:%02d`), `ClearTimes`, `CompletionRate`,
|
||||||
|
|||||||
Reference in New Issue
Block a user