Files

T

CydandClaude Fable 5 c2b0a371ba BT410 5.3.90: the gait player is real -- SequenceController::Advance was the Fail() stub under the legs

Asked what was next for the rebuild, went to measure it, and found I had told
the operator the wrong thing one turn earlier.

THE CORRECTION.  I said mech2.cpp (the gait state machine) was the next
package.  It sits on top of SequenceController's playback methods, and all
three of those -- SelectSequence, Advance, Reset -- were Fail() stubs.  Advance
is the function that actually walks a clip's keyframes and writes each
animated joint.  mech2 without it would have called straight into a Fail.  So
the dependency runs:

    Mech::AdvanceLegAnimation      mech2.cpp -- the STATE MACHINE, still absent
      -> SequenceController::Advance   THIS -- keyframes -> joint writes
        -> Joint::SetHinge / SetRotation / SetTranslation
          -> the joint DCS flush fixed in 5.3.88

5.3.88 fixed the bottom link, this fixes the middle, the top is still missing.

WHAT THIS DOES NOT DO: make the legs move.  Nothing calls any of it yet -- no
gait state is ever selected because mech2 is unreconstructed -- so a run looks
identical to yesterday's.  This removes a blocker.  Saying otherwise would be
easy and wrong.

RECONSTRUCTED (compile-verified, BT 50/50, links clean):

  SelectSequence @004277a8 -- find + lock the clip, parse its layout.  The
  fetch is FindResourceDescription and NOT SearchList: the ID arriving here is
  already resolved, and SearchList would treat it as a resource LIST and walk
  the clip bytes as IDs.

  Advance @0042790c -- snap through every keyframe the new time has passed
  (writing authored poses), then interpolate the partial frame.  Returns the
  forward distance covered, which is what the gait feeds into mech motion.

  Reset @004283b8 -- return every animated joint to neutral, so an abandoned
  gait doesn't leave the skeleton frozen on a stale frame.

THE PART THAT CANNOT BE SEEKED.  The pose block is packed BY JOINT TYPE -- 8
bytes hinge, 12 ball, 24 ball+translation -- so the root-translation table
behind it is not reachable by arithmetic on any stored count.  SelectSequence
must walk the entire skeleton summing per-joint sizes to find it.  Which also
means the parse depends on the mech's own skeleton agreeing with the clip: an
unresolvable slot returns NULL and contributes 0, keeping the walk honest
rather than drifting keyframeData onto garbage.

TWO CONTRACTS worth recording before mech2 is written against them:

  move_joints == 0 is NOT "do nothing" -- it advances the clock and
  accumulates distance while leaving the skeleton alone.  That is how the body
  channel measures a stride without fighting the leg channel over the same
  joints.

  The finished callback is RE-ENTRANT BY DESIGN.  At end of clip it picks the
  next state, re-arms this controller through SelectSequence (rewinding it to
  frame 0), and advances the carryover itself -- so its return value is the
  distance that carryover covered, folded straight into Advance's own return.
  mech2's BodyClipFinished has to honour that or the gait double-counts.

NOT CARRIED OVER from the donor: its BT_HIP_LOG diagnostic and audio
footstep-broadcast path, neither of which is 1995 code.  footStepThreshold IS
parsed -- the field is real and authored -- but nothing reads it yet.

AND A CAVEAT ON THE 91% I QUOTED: seqctl.cpp is not in the 50-TU BT census at
all (its code sits below the BT address range the census was built from), and
that figure counts a TU as done if the FILE EXISTS -- 18 files still carry 26
Fail() stubs between them.  The census understates what "playable" needs.

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

2026-08-02 00:36:39 -05:00

BT410 5.3.90: the gait player is real -- SequenceController::Advance was the Fail() stub under the legs

2026-08-02 00:36:39 -05:00

BT_L4

BT410 5.3.88: hinges flush as MATRICES -- the axis was never on the wire, and a DCS remembers how it was last set

2026-07-30 09:25:12 -05:00

MUNGA

BT410 5.3.62: correction -- the fault address was never in our code

2026-07-29 08:22:15 -05:00

MUNGA_L4

BT410 5.3.87: OPERATOR-CONFIRMED -- both artifacts gone on a live mission

2026-07-30 08:19:44 -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 Phase 5.3.7: weapon view-fire gating + build header-stamp hardening

2026-07-21 22:43:38 -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

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

2026-07-19 08:46:05 -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-07-19)

Compile verification is LIVE: ./compile410.sh --sweep (BC4.52 + the authentic OPT.MAK flags; the period compiler is the reviewer). backdate.py mechanizes WinTesla→1995 header back-dating (donors: C:\VWE\BT412\engine\MUNGA\*.h).

item	state
THE WHOLE TREE COMPILES (2026-07-19)	✅ 11/11: all 10 surviving originals + the BTL4APP.CPP pilot build clean under BC4.52 + authentic OPT flags (`./compile410.sh --sweep`)
BT/BTCNSL.HPP + BT/BTSCNRL.HPP	✅ reconstructed — console wire IDs recovered from the binary (Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1]; TeamScore=12 [T4 GUESS — verify]); see BTCNSL.NOTES.md
BT_L4/BTL4APP.CPP (pilot reconstruction)	✅ compiles (18.5KB obj); 12/12 functions, Fail() at recorded line 400
Staged header family (13: mech/mechsub/heat/powersub/mechweap/emitter/mechmppr/btplayer/projtile/missile + btl4mppr/btl4vid)	✅ [T3] interface-proven by every surviving consumer; layouts parked in reserved[] blocks — see STAGED-HEADERS.NOTES.md + MECH-LAYOUT.md
MUNGA backfills (VDATA, ROTATION, VECTOR2D, AUDREND, APP, LAMP, GAUGREND, GAUGE)	✅ compile-proven (BACKFILLS.NOTES.md)

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).