Risk-4 investigation (before wiring WAVE 8) found my earlier 'keystone unblocks 4 things' claim was wrong. Verified from the binary: - 0xBD3 SubsystemMessageManager = a damage/explosion consolidation hub (ConsolidateAndSendDamage, weaponExplosions), cached to Mech[0x10d]=0x434, mislabeled 'controlsMapper' in our recon (the live drive squats there; the real mapper is roster slot 0 via SetMappingSubsystem). - The valve MoveValve guard (FUN_004ac9c8 ->owner+0x190+0x274) AND the Myomers gate (FUN_004ad7d4 ->owner+0x190+0x260) read a DIFFERENT object at mech+0x190 (!= 0x434). So 0xBD3 does NOT gate the valve/Myomers/MessageBoard; mech+0x190 (unidentified, no decompiled writer yet) is the real keystone for those gauge-adjacent routes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.1 KiB
6.1 KiB
id, title, status, source_sections, related_topics
| id | title | status | source_sections | related_topics | |||||
|---|---|---|---|---|---|---|---|---|---|
| open-questions | Open Questions — deferred systems, unknowns, get-from-Nick | living | CLAUDE.md §9; docs/HARD_PROBLEMS.md; per-subsystem deferral notes |
|
Open Questions
Known unknowns + deliberately-deferred systems. For each: what's known, what's missing, what would resolve it, status. Deferred ≠ broken — most are marked-and-guarded stand-ins with the authentic path scoped.
From Nick (external — gating for some paths)
- [GATING] The BT game SOURCE CODE — the missing implementation
.cpp(mech, subsystems, mapper, HUD, app; see source-completeness). Without it, Route A (recompile original) is impossible; we reconstruct from the binary instead. Likely on a backup/dev drive. Status: OPEN. - Confirmation the PodPC image is the complete content master. (Low priority — the runtime
BTL4.RESalready has 8 maps + the full mech anim set.) Status: OPEN. - Pod specifics for Phase 8: the 7-monitor driver setup, the RIO cockpit I/O protocol, current Win10+wrapper pod config. Status: OPEN.
Deferred subsystems / feeds (authentic path scoped, marked in code)
- 0xBD3 SubsystemMessageManager (WAVE 8) — a per-mech damage/explosion consolidation hub
(
ConsolidateAndSendDamagePerformance @0049b784,weaponExplosionsqueue,CommonDamageInformation; messmgr.hpp). ctorFUN_0049bca4(vtable 0x50b954, installs a Performance → ticks). The factory caches it toMech[0x10d]= byte 0x434. What wiring it needs: an untangle — our reconstruction MISLABELEDMech[0x10d]ascontrolsMapperandmech4's live drive reads it as the mapper, so the real messmgr can't land there until the drive is re-pointed to the true mapper (roster slot 0, installed bySetMappingSubsystem/MakeViewpointEntity; aMechRIOMapper). Payoff = authentic damage/explosion consolidation (a COMBAT-fidelity improvement) + fixing the mapper/messmgr conflation. ⚠ CORRECTION (verified 2026-07): 0xBD3 does NOT gate the valve/Myomers/MessageBoard — those read a DIFFERENT object atmech+0x190(bothFUN_004ac9c8the valve guard→+0x274andFUN_004ad7d4the Myomers gate→+0x260derefowner+0x190, which ≠ the 0x434 messmgr cache). The earlier "0xBD3 gates 4 things" note was wrong. - ⭐
mech+0x190gate object (UNIDENTIFIED — the REAL keystone for the gauge-adjacent routes) — a per-mech status/damage-state object read by the valveMoveValveguard (owner+0x190→+0x274) AND the MyomersOwnerAdvancedDamagegate (owner+0x190→+0x260). No decompiled writer found formech+0x190yet (likely a base-ctor registration or an offset not yet traced). Identifying + reconstructing it is what actually unblocks the condenser valve CONTROL route, the Myomers advanced-damage coupling, and (via its message queue) plausibly the MessageBoard/control-mode routes. What resolves it: trace themech+0x190writer (grep other parts / disas the mech ctor + base ctors) → identify the class → reconstruct + wire. - StatusMessagePool (NULL stub, btstubs.cpp:62) — the per-player status-message queue.
BTPlayer+0x1dc is never populated → MessageBoard is empty (authentic for bring-up). What
resolves it: wire the pool + decode
AddStatusMessage @0042e580+ thePlayer__StatusMessagerecord ({messageId@+0xc, nameEntity@+0x10}). - Gyroscope (0xBC4) — layout + joint-I/O reconstructed, but the ctor field-init + the two integrators (IntegrateEyeJoint @004b2ec0 / IntegrateBody @004b30ec) are incomplete → writes NaN to the root joint. Reverted to a stub. A full subsystem-sim reconstruction (bigger than Torso).
- MechControlsMapper look/eyepoint commit — reconstructed but its offsets collide with declared
members; arbitrate before enabling (no port consumer yet). The fire-trigger-through-mapper is
still the
gBTWeaponTriggerbring-up. - Myomers authentic coupling — the structural un-stub is INERT (mover feed + heat-gen no-op).
Real coupling needs the 0xBD3 advanced-damage gate +
MoverAttachrouting into the LIVE JointedMover (must be reconciled with the gait cutover first). - SeekVoltageGraph — 4 Seek* attrs unpublished (a cluster-child, not config-called; non-blocking).
Locomotion / combat polish (non-gating)
- Authentic per-mech TURN-RATE constant (currently a bring-up constant rate).
- Body-callback gimp handlers (states 16-19, targets 0x70b2/0x7161 undecoded → fall back to stand);
airborne callbacks (
FUN_004a6344/FUN_004a7970). - Wall-block-vs-climb tuning; collision DAMAGE application (computed, not applied in bring-up).
- Death: reconstruct
DeathShutdown(RPVTV::DeathShutdownanalog) + collapse anim + destroyed skin. The wreck-stays behavior we ship is faithful; do NOT issue DestroyEntityMessage on death.
Multiplayer (Phase 7 / P6)
- Cross-pod COMBAT (target a replicant + route damage to the owning master).
- Replicant GAIT animation (replicants don't animate joints yet — derive from replicated velocity).
- The pod-LAN config (real IPs, bare-IP pilot entries). The WinSock2 TCP stack (L4NET.CPP) is reconstructed + smoke-tested on one box (two instances share a world, movement replicates).
Rendering follow-ups (non-blocking)
- Replacement-LOD selection for NON-additive multi-LOD models (needs the board's hot-spot/
reference-point semantics; leads:
s_dplobject.lod_ranges[16]/lod_hot_spot, 0x2047/0x2048). - Day/night MATERIAL path priority (BMF/IMG) — infrastructure done, gated
BT_MATPRI(over-applies to shared terrain mats); needs the terrain-material model understood. - RGBA4444 alpha (TREE.BSL cutout) decoded but not alpha-tested outside punch batches; VTX/TGA paths.
Content build sub-project (low priority)
- Lab/other-build maps (
des/burnt/frstrm) are source-only (.mapin CONTENT/BT/MAPS/); would need compiling into a RES via the DOSbtl4tool.exe. The 8 RES maps cover testing.
Key Relationships
- Feeds from: every subsystem/render topic (their deferral notes collect here).
- Gating master: source-completeness (the missing BT source).