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

Phase-5 crash localized: control-mapping binding needs subsystem attribute tables

Browse Source 
The Mech ctor fully constructs (33 subsystems / 7 weapons on real TEST.EGG data,
trace-confirmed). The crash is the control-mapping resource binding in
MakeViewpointEntity resolving subsystem attribute IDs via GetAttributePointer --
the subsystems publish none (reuse base AttributeIndex). Documented the precise
phase-5 step-1 scope (per-subsystem AttributeIndex + the ID chain) in MECH.NOTES.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-20 08:58:47 -05:00
co-authored by Claude Fable 5
parent b8f5928887
commit 0248a78840
1 changed files with 22 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
restoration/source410/BT/MECH.NOTES.md
+22
View File
@@ -97,3 +97,25 @@ Phase-5 work, in order:
4. Rendering integration (the DPL renderer bridge) + playable verification.
Everything through the Mech ctor + viewpoint link runs real reconstructed code.
## PHASE-5 CRASH LOCALIZED (2026-07-20)
Trace-confirmed: the Mech ctor FULLY constructs on the real pod TEST.EGG mech --
`subsystemCount=33 weaponCount=7` (BT_MECH_LOG). The crash is AFTER construction,
in BTL4Application::MakeViewpointEntity's "Load the control mappings" block
(btl4app.cpp ~420): it SearchLists the ControlMappingsListResourceType resource
and binds each streamed mapping to a subsystem attribute -- via an AttributeWatcher
-> Simulation::GetAttributePointer(attributeID). The reconstructed subsystems
publish NONE of their real attributes (they reuse the base Subsystem::AttributeIndex),
so the streamed attribute IDs don't resolve.
Phase-5 step 1 = per-subsystem AttributeIndex, and it's a precision task:
- BT411 has the AttributePointers[] tables (mechsub 1, heat/HeatSink 12, powersub 4,
Generator, sensor 3, torso 13, weapons, ...) -- but ATTRIBUTE_ENTRY(class,Name,member)
needs each member NAMED + accessible (several of ours sit in reserved dynamics
pads -- Gyroscope/Torso/HUD -- and must be broken out).
- The attribute-ID enums chain Simulation::NextAttributeID -> Entity -> Mover ->
... -> subsystem, and MUST match the 4.10 binary IDs (the streamed control
mappings reference them by number).
Then: watcher/plug/capability-chain wiring, then the mech2/3/4 per-frame sim
(~9K lines, staged), then rendering. This is the behavioral half.