arcattackandClaude Opus 4.8 48ed3a8b73 gauges: register + wire the map (radar) -- the tactical display renders
MapDisplay (the radar/threat-map gauge, btl4rdr.cpp) was fully reconstructed
(ctor + Execute + DrawViewWedge/DrawStatic/DrawMoving/DrawNames) but never
registered and its data attributes never published.  Wire it up end-to-end:

DATA (the attributes the map binds):
* Mech table extended to the full 0x15..0x38 (was the 0x21 prefix): add
  RadarRange@0x2f -> radarRange, RadarLinearPosition@0x30 -> radarLinearPosition
  (Point3D* -> &localOrigin.linearPosition), RadarAngularPosition@0x31 ->
  radarAngularPosition (Quaternion* -> &localOrigin.angularPosition), DuckState
  @0x37 -> duckState; the rest bind the shared attrPad (kept dense so Find can't
  strcmp a gap).  New members set in the Mech ctor; radarRange defaults to 500
  (SetTargetRange is still stubbed) so nearby contacts are on-scale.  The map's
  position/angle attributes resolve to Point3D**/Quaternion** (AttributePointer
  is int Simulation::*, so the ATTRIBUTE_ENTRY reinterpret binds pointer members
  fine -- verified live: posPtr/anglePtr resolve).
* Sensor (named "Avionics") publishes RadarPercent/SelfTest/BadVoltage: define
  Sensor::AttributePointers[] + build the previously-empty Sensor::AttributeIndex
  chained to PoweredSubsystem::GetAttributeIndex() (= HeatSink's dense index).

WIDGET (the registration glue -- NOT in the assert-anchored decomp, so
reconstructed from the config + ctor):
* MapDisplay::methodDescription (config "map") + MapDisplay::Make.  The
  offset_position keyword "center"/"bottom" is typed as a STRING and converted
  in Make, avoiding a ModeManager named-constant registration.  Registered in
  BTL4MethodDescription[] (btl4grnd.cpp now includes btl4rdr.hpp).

Three crash fixes exposed once the map ran (each a pre-existing stub the map is
the first consumer of):
* Sensor radarPercent went hugely negative (RadarBaseline - HeatMasterEnergy(),
  where the inherited heatEnergy is un-normalized in the not-byte-exact heat-leaf
  branch) -> the radar reported non-operational.  Guard: treat an out-of-[0,1]
  heat term as no penalty (marked bring-up; real overheat penalty needs the heat
  normalization).
* ResolveOperatorEntity was a stub returning NULL -> EntityPosition(NULL) crashed
  CalculateBounds.  Fixed to the renderer linked-entity + application viewpoint
  fallback (same as HeadingPointer).
* MapName::ExtractFromEntity didn't guard a NULL entity (the binary's Verify(False)
  iterator-mismatch path compiles out at DEBUG_LEVEL 0) -> EntityPosition(NULL).
  Guarded.

Verified live (BT_DEV_GAUGES): the radar now draws the view wedge (the mech's
180-deg FOV cone) and completes the full wedge/static/moving/names cycle with
operating=1, cap=1, scale=500, position/angle resolved, 0 crashes.  Combat un-
regressed (TARGET DESTROYED after 8 hits), heap-clean under BT_HEAPCHECK.
Permanent gated diagnostic: BT_MAP_LOG traces the phase/draw pipeline.  Contacts
show 0 (the spatial-query entity classification is a follow-up); DuckState now
resolves for the duck button too.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-06 21:16:29 -05:00

BattleTech 4.11 (bt411)

A standalone Windows port of Virtual World Entertainment's arcade BattleTech (Tesla platform, release 4.10, ~199596), reconstructed on the shared RP411 Windows engine. The game boots, renders, and runs a single-player drive → animate → target → fire → damage → destroy loop across all 8 maps, with two-instance multiplayer entity replication working.

This repo is a clean, self-contained extraction of the BattleTech-specific work from the larger reverse-engineering workspace — engine + game + content + build, with nothing from Red Planet or the raw archive dumps. It builds and runs out of the box.

License: the game content (content/) and the original binary are proprietary to Virtual World / the pod owner. This repository is private; do not redistribute.


Layout

CMakeLists.txt      one build: munga_engine lib + bt410_l4 game lib + btl4.exe
engine/
  MUNGA/            shared 2007 sim/render engine (149 .cpp + headers)
  MUNGA_L4/         Win32/D3D9 HAL + renderer + asset loaders (43 .cpp), incl.
                    our BT work: bgfload / L4D3D / L4VIDEO + the image codec
  shim/             minimal ATL shim (USES_CONVERSION/W2A)
  lib/              OpenAL32 / libsndfile import libs + runtime DLLs
game/
  reconstructed/    the reconstructed BT game logic (mech, subsystems, HUD, app)
  original/BT,BT_L4 surviving original BT source + all BT headers
  fwd/              header shims forwarding <NAME.hpp> -> the engine's NAME.h
  btl4main.cpp      WinMain launcher / entry point
content/            runtime data: BTL4.RES, VIDEO/, GAUGE/, AUDIO/, *.EGG, BTDPL.INI
docs/               format specs (BGF, assets) + reconstruction ledgers
reference/
  decomp/           raw Ghidra pseudocode — source-of-truth for ongoing recon
  ghidra_scripts/   the headless decomp exporter
tools/              btconsole.py (MP console emulator), map/resource scanners
run/                run.cmd helper
CLAUDE.md           full project context / progressive knowledge base

Prerequisites

  • Visual Studio 2019 BuildTools (MSVC v142, x86). The Community install on the original dev box was broken, hence the explicit BuildTools instance in the configure line below; adjust to your install.
  • CMake ≥ 3.20.
  • Legacy DirectX SDK (June 2010) — the engine uses d3dx9/dinput/dxerr, removed from the modern Windows SDK. Default path C:/Program Files (x86)/Microsoft DirectX SDK (June 2010); override with -DDXSDK=<path>. (The installer may throw a harmless S1023 error — dismiss it; the SDK headers/libs install before the failing redist step.)

OpenAL/libsndfile import libs + DLLs are vendored under engine/lib/; the DLLs are copied next to the exe automatically at build time.

Build (32-bit / Win32)

cmake -S . -B build -G "Visual Studio 16 2019" -A Win32 ^
      -DCMAKE_GENERATOR_INSTANCE="C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools"
cmake --build build --config Debug

Must be Win32 — the DirectX SDK link libs are Lib/x86. The link uses /FORCE: the 1995 headers define free functions/globals without inline/extern, so identical symbols appear in many translation units (~124 LNK2005); /FORCE:MULTIPLE keeps the first. UNRESOLVED tolerates a dead offline-tool factory in mech3.cpp that is never called at runtime. (Cleanup task: move those definitions to single TUs + neutralize the dead factory, then drop /FORCE.)

Run

run\run.cmd            REM boots DEV.EGG (grass / day)
run\run.cmd DBASE.EGG  REM any egg in content/

The working directory must be content/ (the engine resolves BTL4.RES, VIDEO\, BTDPL.INI, and eggs relative to cwd); run.cmd handles that. Maps available in BTL4.RES: cavern grass rav polar3 polar4 arena1 arena2 dbase — switch via a copied egg's map= field.

Useful env-var flags (default OFF unless noted)

The authentic stack (gait, collision, real controls) is default-on; set =0 to fall back. Debug/harness flags: BT_FORCE_THROTTLE=1 (auto-walk), BT_SPAWN_ENEMY=1 (spawn a target dummy), BT_FORCE_FIRE=1 (auto-fire), BT_HEAPCHECK=1 (whole-heap validation — slow), BT_BSL=0 (legacy texture decode), BT_LOG=<file>. Interactive: WASD drive, Space/Ctrl fire, X all-stop. See CLAUDE.md for the complete list and the reconstruction history.

Multiplayer (two instances, one box)

instance A:  btl4.exe -egg MP.EGG -net 1501   (BT_LOG=mp_a.log)
instance B:  btl4.exe -net 1601               (BT_LOG=mp_b.log)
console:     python tools/btconsole.py MP.EGG 127.0.0.1:1501 127.0.0.1:1601

-net <port> enables networked mode; the console emulator delivers the mission egg and the launch command. Entity + movement replication works; cross-pod combat is in progress.

Status & continuing the work

The engine, renderer, audio, HAL, build, locomotion, collision, damage, and render fidelity are done; per-subsystem reconstruction (gyro integrator, projectile/missile weapons) and MP combat are the active fronts. docs/ holds the format specs and reconstruction ledgers; reference/decomp/ holds the raw pseudocode that every reconstruction is verified against. CLAUDE.md is the durable, progressive project context — read it first.

S
Description
No description provided
Readme
77 MiB
Languages
C++ 50.5%
C 37.3%
1C Enterprise 10.4%
Python 1.3%
Shell 0.1%