Files

T

CydandClaude Fable 5 77db3290d0 BT410 5.3.138: our ammo explosion may be more lethal than the original -- the cook-off charge re-marked [T2] after the hunt for its source came up empty

Chasing yesterday's [T1] to retire it produced an answer that must not be
papered over.

Two corrections to my own 5.3.137 note first.  FUN_0041db7c is the
engine's Damage CONSTRUCTOR -- it zeroes the amount, seeds the force,
sets the normal to (0,1,0) -- so the bin's +0x1f0 block is a Damage
struct, not an "explosion record", and our cookOffState[12] is that
struct in disguise.  And the resource read I thought filled it belongs to
the GENERATOR ctor: same dword index, different class.  The per-class
offset trap, twice in two days.

The uncomfortable part: across the whole AmmoBin TU that Damage is only
default-constructed and read.  Nothing writes its amount.  The
constructor leaves it zero, so rounds x 0 == 0 -- the shipped game's
cook-off appears to compute ZERO damage.  It destroys the bin, announces
"ammo explosion damaging" for every zone, and delivers nothing.

Three readings survive: the feature is vestigial in 4.10; a writer lives
outside the TU (a table-registered handler is where to look next); or the
multiplier cell is misidentified.

So the landing is re-marked [T2], a deliberate divergence, not [T1]
staging.  With the fed weapon's damage standing in, ours does 500-800
points across the zones and destroys subsystems where the shipped one
does nothing.  That is us being more lethal than the original, which is
exactly the silent gameplay drift this project exists to avoid.  It stays
ON -- an inert mechanic is indistinguishable from an unfinished one and
would hide the question -- but it is now flagged in the code, in the
notes, and to the operator, and BT_FORCE_COOKOFF remains the only way to
trigger it without genuine heat failure.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-13 09:05:58 -05:00

BT410 5.3.138: our ammo explosion may be more lethal than the original -- the cook-off charge re-marked [T2] after the hunt for its source came up empty

2026-08-13 09:05:58 -05:00

BT_L4

BT410 5.3.106: MISSION REVIEW LINKS -- the playback app, the winners circle, and the last Fail() in main

2026-08-03 15:54:31 -05:00

MUNGA

BT410 5.3.113: the displays lag because the loop is slow, and the loop was slow because the flags were wrong -- authentic OPT.MAK optimizer set adopted

2026-08-04 01:42:08 -05:00

MUNGA_L4

BT410 5.3.117: the pod talks -- the entire NetNub networked layer reconstructed, and the last runtime stub falls

2026-08-04 10:05:13 -05:00

override

source410: engine COMPLETE (165/165) - link reaches PE emission; deep ledger cut

2026-07-19 11:25:49 -05:00

shim/dpl/vpx

source410: link campaign - entire engine compiles (152/152), first true link,

2026-07-19 08:46:05 -05:00

backdate.py

4.10 reconstruction: BTL4OPT.EXE links clean and BOOTS to the first staged brick

2026-07-19 19:05:53 -05:00

build410.sh

BT410 5.3.113: the displays lag because the loop is slow, and the loop was slow because the flags were wrong -- authentic OPT.MAK optimizer set adopted

2026-08-04 01:42:08 -05:00

compile410.sh

source410: THE WHOLE 4.10 TREE COMPILES - 11/11 under the fleet's BC++ 4.52

2026-07-19 07:58:26 -05:00

layout_probe.cpp

source410: THE WHOLE 4.10 TREE COMPILES - 11/11 under the fleet's BC++ 4.52

2026-07-19 07:58:26 -05:00

README.md

BT410 5.3.107: census checkpoint -- 98% covered, and nine "missing" TUs had survived all along

2026-08-03 15:57:27 -05:00

RENDER-ROADMAP.NOTES.md

BT410 5.3.82: the MFD bleed -- mechanism found (uninitialised translation table)

2026-07-29 21:06:22 -05:00

UNRESOLVED-LEDGER.txt

source410: engine COMPLETE (165/165) - link reaches PE emission; deep ledger cut

2026-07-19 11:25:49 -05:00

README.md

source410 — literal reconstruction of the missing BT 4.10 game source

Everything in this directory is RECONSTRUCTED, not recovered. The authentic surviving source lives in CODE/ and is never mixed with this tree. The goal here is an archival-grade recreation of the d:\tesla_bt\ translation units that exist only inside BTL4OPT.EXE (the shipped 4.10 binary), written in the 1995 VWE house style against the 1995 MUNGA/MUNGA_L4 engine headers that DID survive.

Ground rules

Never copy a reconstructed file into CODE/ — the assembled buildable tree (originals + reconstructions) is produced by a script into a build directory, so provenance stays unambiguous file-by-file.
Every .CPP here has a .NOTES.md sidecar carrying the evidence: the binary address map, decomp references, which sibling sources supplied each idiom, and every judgment call with its tier ([T1] decomp-proven … [T4] style guess). The .CPP itself stays clean 1995 style — no modern annotations inside.
Assert line numbers are constraints. The binary's Fail() sites record the original file+line (BTL4APP.CPP:400 etc.); reconstructed files are shaped so those calls land on their recorded lines. A file that can't meet its line constraints yet says so in the sidecar.
Layout mirrors the original tree: BT/ (bt.lib, 36 TUs) and BT_L4/ (btl4.lib, 13 TUs + BTL4.CPP), matching the surviving BT.MAK/BTL4.MAK.

What drives the work

The per-TU manifest: C:\VWE\BT411\reference\BT410_SOURCE_MANIFEST.md (tool tools/manifest410.py; method log phases/phase-03-bt410-source-manifest.md).
The decomp: C:\VWE\BT411\reference\decomp\all\part_*.c (+ section_dump.txt strings).
The port's semantic reconstructions: C:\VWE\BT411\game\reconstructed\ (WinTesla-hosted; each literal file here re-hosts one back onto the 1995 engine APIs).
Style/idiom exemplars: surviving CODE/BT/*.CPP, CODE/RP/RP_L4/*.CPP, CODE/RP/MUNGA*/** (the 1995 engine source itself).

Status (2026-08-03)

The census is 98% covered (897 of 917 binary-attributed functions): manifest410.py's 50-TU missing-source census now splits RECONSTRUCTED / SURVIVES / MISSING — an audit found NINE census TUs (btmssn, btcnsl, btreg, btteam, bttool, gauss, ppc, btl4arnd, btl4mode) had surviving source in CODE/ all along (attribution noise: the binary file-tags covered only part of each TU's functions). Remaining MISSING:

TU	fns	note
`bt/mech3.cpp`	3	the resource STREAM BUILDERS (authoring-side)
`bt/mech4.cpp`	17	master perf / IntegrateMotion / ReplicantPerformance — large parts already re-hosted in `Mech::Simulate` at STAGED seams (see MECH4.NOTES.md)
`bt/gnrator.cpp`	0	GNRATOR.TCP is an 18-line test fragment; both its methods live in POWERSUB.CPP
`bt_l4/btl4galm.cpp`	0	zero attributed functions; header survives

The honest completion metric is the Fail() stub count: 22 stubs across 15 files (down from 26/18 at the start of the gait arc). SEQCTL.CPP and BTL4.CPP are stub-free.

Playable-systems status: the mech WALKS (two-channel clip gait, all 12 mech2 functions, interior+exterior clip sets), LIMPS from real leg damage (two-stage leg death), TURNS IN PLACE by stepping, walks REAL TERRAIN (the gravity-less ground snap), and collides authentically (frame rejection, knockdown stagger, the collision-damage economy, crushable props, rams). MISSION REVIEW links end to end (BTL4PB + L4SPLR + the review/camera launch in main) — runtime test pending a recorded spool. The engine tree gained L4SPLR.CPP (182 TUs).

Next work package — the mech-family, REVISED (round-3 finding, 2026-07-19): the plan to "reconstruct mech.hpp first" was the wrong order. A full read of the port's mech.hpp shows it is a hybrid (1995 skeleton + Recon proxies + port-only members + relocated fields), and substantial regions of the binary's 0x854-byte Mech object remain UNMAPPED — the port declares "the remaining members up to sizeof==0x854" in its mech2-4 slices. A literal MECH.HPP that precedes those TU reconstructions would be fiction. Corrected order:

MECH.HPP is the CAPSTONE, grown incrementally with each mech-family TU reconstruction (mech.cpp → mech2-4 → subsystem TUs), starting as an interface + known-ordered members with explicit reserved[] filler for unmapped regions (sidecar-tracked), tightened as each TU pins its slice.
The dependent headers (mechsub, mechmppr, btl4mppr, emitter+mechweap, btplayer, projtile, missile) ship WITH their TUs against the staged MECH.HPP.
The blocked originals (BTTOOL, GAUSS, PPC, BTREG) and the BTL4APP pilot compile green as those land — BTREG last (it includes the whole game-header world). Offset oracles for every stage: BT411 CLASSMAP.md, decomp-reference.md §3, and the port headers' static_assert-locked members.

Toolchain — IN HAND (2026-07-19)

Borland C++ 4.52, archived at ../../BORLAND/BC45/, chosen by byte-match: the fleet's own CODE/RP/CW32.LIB is identical to 4.52's (and not 4.5's). BCC32/TLINK32/TLIB/MAKE run natively on Win11. The shipped BTL4OPT.EXE recipe is CODE/BT/OPT.MAK (plain bcc32, -DLBE4;DEBUG_LEVEL=0;DEBUG_STREAM=cout, -5 -a4 -ff -k- -V -Jg -x- -RT- + the full -O set, PCH btopt.csm; link -Tpe -ax with c0x32.obj + dpmi32.lib + cw32.lib = Borland PowerPack DPMI32, not Phar Lap TNT). Compile verification of reconstructed TUs is therefore possible file-by-file; the current blocker for full closure is the 1995 engine header gap (vdata.hpp first — only the drifted WinTesla VDATA.h survives, in BT412/engine). Include order for builds: CODE/BT/* over CODE/RP/*, -DNO_PRECOMPILED_HEADERS until the mech-family headers are reconstructed. Remaining gap: TASM32 (JOYSTICK.ASM only).

Link campaign (build410, 2026-07-19)

source410/build410.sh assembles BTL4OPT.EXE: merged-engine mass compile (152/152 green — the ENTIRE surviving engine compiles), BT TUs (11/11), tlib libs (munga 1.25MB / mungal4 with the prebuilt-1995 objs / bt / btl4), then the authentic tlink32 link rooted by a probe main (build scaffold). First true link run: 52 unresolved externals (UNRESOLVED-LEDGER.txt) = the measured remaining gap. Kill-lists: l4gauge.cpp back-date (14 widget statics), the missing-engine-body back-date wave (~24: rotation, player, team, l4app, explode, dropzone, terrain, cultural, subsystm-statics, netclient...), the prebuilt RANDOM.obj fold, and the staged game-TU statics blocks (MECH.CPP et al. — each TU file opens with its binary-evidenced Derivation/SharedData statics and grows into the full body). Link-lib arbitration: SOS = SOSDBXC+SOSMBXC (the 32-bit Borland-flat variants; SOSMW*=16-bit), WATTCP excluded (it belongs to the 16-bit NetNub TSR — the game talks to it via shared memory), filestrm = the RP-era pair (BT-tree pair is post-4.10 drift; override layer).