vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Gitea #38 ROOT CAUSE + FIX: mech paint lost on geometry re-load (view toggle / respawn)

Browse Source 
Found from the user's live 2-node demo: a Crimson MadCat went GREY in its own
view after a V (inside/outside) toggle, with NO new [paint] or
MakeMechRenderables line in the log -- so no rebuild, just a re-parse.

ROOT CAUSE: the per-pilot colour/badge/patch is applied by rewriting MATERIAL
NAMES while a BGF parses, and only while the substitution callback is installed
(SetupMaterialSubstitutionList .. TearDown, bgfload.cpp:15-18).
BTL4VideoRenderer::ApplyViewSkeleton re-parses every shown segment BGF on each
view toggle AND on respawn (that is what its fresh graphic-state read is for),
but did so OUTSIDE that bracket -> raw %color% placeholders -> unpainted
materials -> grey.  Nothing caches the geometry (d3d_OBJECT caches only
textures), so every call re-parses.  This is #38's mechanism: 'colors not
preserved on respawn' was never a replication or teardown bug.

FIX: re-install the substitution list around the reload, reusing the serial the
mech was BUILT with -- SetupMaterialSubstitutionList advances the global %serno%
per call, so a naive re-bracket would stamp a different serial and still resolve
the wrong names.  MechRenderTree gains paintSerno (captured before Setup at
build); ApplyViewSkeleton installs/restores around the loop and logs it.

Rig-verified: the crimson MadCat stays crimson (yellow patch intact) across
repeated inside/outside toggles; each toggle now logs '[paint] color=red
serno=0' + '(paint serno 0)'.

ALSO -- corrections to yesterday's #44 name plate from the adversarial pass:
 - kPlateARGB 0xFF808080 -> 0x80FFFFFF.  BMAP.BMF tag 0x0027 is
   dpfB_MATERIAL_OPACITY_TAG [T0 libDPL/dsys/PFBIZTAG.H], NOT a diffuse colour:
   the materials carry NO colour tag at all, so the plate is the unmodulated
   callsign raster at ~50% opacity, not a grey label.  (Two independent
   workflows converged on this.)
 - the plate's K = 1/2.8 is NOT the hotbox's constant (2.8145) -- de-unified.
 - the Lock attribute is HUD attr id 10, an int/Logical*, not a Scalar*.
 - the PNAME pair split is the V half, not U (our per-player texture is one
   128x32 cell, so the port quad samples v 0..1).
 - retracted bgf-format's 'tag 0x0027 likely SPECULAR [T4]'.

KB: new reconstruction-gotchas section on the whole bug class (load-time-only
state must be re-installed on every RE-load, incl. the serno trap).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0166KTsC7ADm7VXEi1HF1jNg
This commit is contained in:
arcattack
2026-07-24 19:06:04 -05:00
co-authored by Claude Opus 5
parent 35c750dc7c
commit 6c3fca2f67
5 changed files with 124 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
engine/MUNGA_L4/L4VIDEO.cpp
+4 -1
View File
@@ -9941,7 +9941,10 @@ void DPLRenderer::LoadNameBitmaps()
// BT: the RETICLE TARGET NAME PLATE's texture (the 1995 PNAMEx.bgf plate art).
// The plate meshes are quads UV-mapped onto a shared BITMAP material -- e.g.
// PNAME1.BGF and PNAME2.BGF both reference `bmap:name12_mtl` and differ only in
// their u-half (verified: the two files differ in 4 UV bytes) -- i.e. the plate
// their V-half (verified: the two files differ in 4 UV bytes -- the V floats;
// U runs 0..1 in both). Our per-player texture is 128x32 = ONE cell, so the
// port's quad samples v 0..1 -- porting the literal PNAMEn.BGF UVs onto it
// would render half a callsign. I.e. the plate
// shows the player's CALLSIGN raster, which on our side is exactly this
// per-player 128x32 name texture (4:1, the plate quad's 1.0 x 0.25 aspect).
// These load for EVERY mission from StartImplementation, so a cockpit session