Files
BT411/players
Joe DiPrimaandClaude Opus 5 1777d5a62e one log per day, and every log says who it sent it -- rotation was eating the crash stacks
Conn Man crashed twice in an Owens on 2026-07-27, kept playing, and by the time
we asked for his logs they no longer existed.  Not a mystery: every launcher did

    if exist content\X.old.log del content\X.old.log
    if exist content\X.log     ren content\X.log X.old.log

which keeps TWO generations.  He relaunched more than twice, so his own bat
deleted both crash sessions.  The player who crashes is exactly the player who
relaunches immediately, so the retention window was aimed at the wrong case.

THE LOG.  BT_LOG set still means "use this path verbatim" -- that contract is
load-bearing (mp_a.log/mp_b.log for 2-node runs from one cwd, btoperator's
operator_N.log, every scratchpad/mp_*.sh that greps the file it named) and is
untouched.  Only when BT_LOG is UNSET does the exe now name the file itself:
content\<stem>_YYYYMMDD.log, appended, one per day, no rotation window to fall
out of.  The stem (solo/join/steam/joyconfig) comes from the gates the bat
already sets, so solo still cannot overwrite the MULTIPLAYER log.

Self-named files append UNCONDITIONALLY.  The default open mode is ios::out --
TRUNCATE -- and the operator GUI's exported bats never set BT_LOG_APPEND, so
they were truncating already; leaving append implicit would have let the second
launch of the day erase the morning.

IDENTITY, because these arrive from many players at once and Discord renames
half of them to message.txt (most of the night-5 evidence had to be
re-identified by hand):

    ===== BT411 SESSION  build=4.11.603 (d64d75f+)  machine=...  user=...
          callsign=Conn Man  mode=solo  pid=13192  local=...  log=... =====

Also the session separator inside a per-day file, and it puts build+hash ABOVE
any [crash] block so btl4+0xNNNN offsets stay matchable to a PDB across builds.

SIZE.  Never delete, but stay sendable: past 8 MB the next launch rolls to
<stem>_YYYYMMDD.1.log.  Checked only at open, so a live session is never split.

CONSOLIDATION.  launch_report.txt is gone, folded into lastrun_<stem>.txt (one
launch record: the exe appends its block at first breath, the bat appends the
exit line).  Per-stem because one shared lastrun.txt let a second launcher's
`del` destroy the first launch's block.  Its ABSENCE after a run is now the
#41 "never reached WinMain" probe -- the old "if not exist X.log" test cannot
work against a per-day file, which survives earlier launches, and would have
reported every healthy run as blocked by antivirus.  marshal.log folded into
the day log too; it keeps its own handle and gained a CRITICAL_SECTION because
it runs on a worker thread while the engine log stream is single-threaded.
play_steam.bat gained a launch bracket it never had -- which is why a Steam
player killed before WinMain previously left no evidence at all.

_putenv_s, not SetEnvironmentVariableA, to pin the resolved name: MSVC's CRT
keeps its own environment copy, so getenv() in-process does NOT see a
SetEnvironmentVariableA write (measured).  btl4console/btl4lobby resolve the
day log via getenv, so with the Win32-only call they silently fell back to
marshal.log and the fold never happened.

logfile.open() is now checked -- a failed open used to rebind cout to a dead
buffer, silently dropping the header, [boot] and any crash stack while
lastrun still claimed log=<name>.

Verified: append across sessions with distinct pids, crash block landing under
its own header, BT_LOG verbatim unmangled, an inherited BT_LOG cleared by the
bats, roll-over at 8 MB, and both forensic verdicts (exe ran / exe blocked).
Console auto-retrieval is unaffected -- it uploads the matchlog, a different
file, and a crashed round never reaches the upload call anyway.

Known gaps, deliberately not in this commit: the setlocal hoist for gate
leakage when two bats share one console (dev-only), and btoperator's exported
bats still lack the lastrun bracket -- do not press Export on a shipped zip.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-28 10:33:07 -05:00
..

BattleTech {VERSION} -- multiplayer client
==========================================

IMPORTANT: FULLY EXTRACT this zip first (right-click - Extract All).
Do NOT run anything from inside the zip.  The .bat files must sit next
to the 'content' and 'build' folders.

UPGRADING from an older version?  Extract the new zip OVER your
existing game folder and say YES TO OVERWRITE.  Do NOT delete the
folder first -- your personal files (content\bindings.txt with your
key/joystick setup, content\volume.cfg with your volume) are not in
the zip and survive an extract-over-top, but a delete wipes them.
If you prefer a clean delete anyway, copy those two files out first
and put them back after.

TO JOIN AN INTERNET GAME:   double-click  join.bat
   -- pick your CALLSIGN and MECH, click JOIN (your choice is sent to
   the operator; waits for the session if it's not up yet)
TO JOIN A LAN GAME:         double-click  join_lan.bat  (operator's LAN;
   same callsign/mech menu)
SINGLE-PLAYER:              double-click  play_solo.bat  -- opens the
   mission menu: pick your mech (all 18), map, experience level,
   colours, weather and mission length, then launch
{STEAM}STEAM INTERNET PLAY:        double-click  play_steam.bat  (EXPERIMENTAL --
{STEAM}   needs the Steam client running; host or join from the menu)

Your seat is assigned automatically; you'll pilot the mech you picked
in the join menu (the operator can override it).
When a round ends your game AUTOMATICALLY rejoins for the next one
(same seat, same mech) -- just wait for the operator's next launch.
Close the window to leave for real.
If the game closes unexpectedly, send the operator TODAY'S log --
content\join_YYYYMMDD.log (the NEWEST one) -- plus content\lastrun_join.txt.

AFTER A MULTIPLAYER SESSION: the game writes a small match report
(content\matchlog_<date>_<time>_<number>.txt) and, on join.bat /
join_lan.bat, UPLOADS IT TO THE OPERATOR BY ITSELF at the end of each
round -- you do not need to send it.  Please send one MANUALLY only if
the game CRASHED mid-round (the upload happens on a clean round end, so
a crash loses it) or if you were playing SOLO or over STEAM (no relay
to upload through).
IF ANYTHING CRASHED OR MISBEHAVED, send BOTH of these -- neither is ever
uploaded, they only exist on your machine:
  content\join_YYYYMMDD.log   today's date; the NEWEST one.  There is now
                              ONE log per day holding every session, so a
                              crash is no longer erased when you relaunch.
                              Each session inside it starts with a line
                              "===== BT411 SESSION ... =====" naming your
                              build and PC, so it still identifies itself
                              if the filename gets changed when you send it.
  content\lastrun_join.txt    tiny; send it EVEN IF there is no log dated
                              today -- that combination is exactly how we
                              tell "the game was blocked before it started"
                              (antivirus, or a missing system file) apart
                              from a normal crash.
If you UPGRADED over an older copy you may still have an old content\join.log
lying around.  Nothing writes to it any more -- ignore it, or delete it, so
you don't send a stale one by mistake.

You start INSIDE the cockpit with the pod's MFD panels composited
around the view (one window).  The red MFD buttons, radar rails and
joystick buttons are all MOUSE-CLICKABLE -- right-click a button to
latch it held.  Press ` (backtick) any time to toggle the external
camera.

CONTROLS (keyboard) -- NEW DEFAULT LAYOUT THIS BUILD:
  The keyboard IS the cockpit button board now: the letter and number
  rows are the MFD button banks laid out where they sit on the panel,
  and FLIGHT LIVES ON THE NUMBER PAD.  Full map: CONTROLS.txt.

  UPGRADING?  Your bindings are MIGRATED to the new board on first
  launch: any keys YOU added or changed are kept (they beat the new
  defaults), and your joystick/HOTAS wizard setup is kept exactly --
  but the old stock keys (W/S throttle, A/D turn, V camera, M mode...)
  are replaced by the layout below.  Your previous file is saved as
  content\bindings.old.txt if you want to copy a favourite line back.

  FLIGHT (number pad -- NUMLOCK ON):
  NumPad 8/2 ........... torso aim up/down     NumPad 7/9 .... left/right pedal
  NumPad 4/6 ........... torso twist           NumPad 5 ...... all stop
  NumPad 0 or Space .... main trigger          NumPad 1/3/. .. pinky/middle/upper
  Shift/Ctrl ........... throttle up/down      Alt ........... reverse thrust
  Left/Down/Right ...... look left/behind/right  Up .......... torso centre
  ` (backtick) ......... cockpit / chase camera
  PgUp / PgDn .......... game volume up/down (saved between sessions)

  THE PANEL ON YOUR KEYS: 1-4/QWER = heat & coolant, 5-8/TYUI =
  engineering, 9-0-minus-equals/OP[] = comm, ASDF/ZXCV = left weapons,
  HJKL/NM,. = right weapons, F1-F12 = the map columns (F1/F2 zoom,
  F4 crouch, F7 CONTROL MODE, F9-F12 Generators A-D).  G and B are
  deliberately unbound -- feel for the gap.  Every button also stays
  mouse-clickable on screen (right-click latches it held).

  NOTE: you SPAWN IN BASIC control mode (the pod's rookie setting) --
  in BASIC the stick steers and the pedals do NOTHING.  Press F7 once
  for MID (pedals steer, stick twists the torso -- the full
  experience).  If 'turning does not work', it is this, not a bug.
  CONTROL MODE (BAS/MID/ADV, the F7 key IN the cockpit) is NOT the
  menu's EXPERIENCE setting (novice/standard/veteran/expert) -- that
  one changes the simulation (heat, damage), not your controls.
  1/2/3/Q/W/E are the six coolant valves and 4 (hold) is the flush.
  CAREFUL with the valves: the detents go 1 - 5 - 50 (max) -
  0 (CLOSED!) - back to 1.  One press past max SHUTS THE LOOP OFF and
  everything on it will overheat -- watch the valve dial on the coolant
  screen.  Boosting one loop starves the others (the supply is shared).
  A weapon gone quiet with ammo left has probably JAMMED (heat makes
  ballistic weapons jam -- authentic!).  Check its panel's ENG DATA page
  for the jam lamp (a cocked round with warning bolts).  The pod's fix
  is the EJECT button on that weapon's ENG DATA page: TAP to eject the
  jammed round (weapon reloads and returns to service), HOLD ~3s to
  jettison the whole bay before it cooks off.  Watch the TEMP strip and
  pace salvos.
  NEW: on a jam or a bay fire, that system's ENG-page buttons now FLASH
  to catch your eye -- the pod's own annunciator, restored.
  NEW AND DANGEROUS: an AMMO BAY FIRE is now genuinely lethal.  You get
  a fire icon by the ammo counter, the flashing buttons, and about TEN
  SECONDS -- then the bay detonates for (rounds x per-round damage),
  which can and will kill you.  HOLD the EJECT button on that weapon to
  dump the bay and put the fire out.  Previously these fires were
  harmless; they are not any more, so treat one as an emergency.
  G (hold) + fire key .. regroup a weapon onto that trigger -- or hold a
     weapon panel's red PROGRAM button with the mouse and tap a fire key;
     the joystick diagram on the panel shows the binding live.

KNOWN ISSUE THIS BUILD -- a weapon that goes dark after you press ENG-page
buttons: the BUS MODE button detaches that weapon from its generator on
its second press, and the automatic re-attach is not working yet.  The
symptom is a weapon whose recharge arc and ready dot are BOTH blank and
which will not fire, while its panel still shows normal data.  THE FIX:
press one of the GENERATOR SELECT buttons (A/B/C/D) on that weapon's
panel and it comes straight back.  Not a lost mech -- just that button.

An Xbox controller works out of the box.  FLIGHT STICKS / HOTAS /
pedals: run joyconfig.bat ONCE -- a wizard asks you to move each
control (stick, twist, throttle, fire buttons), writes the bindings,
and drops you into the solo menu to try them.  Rebind keys in
content\bindings.txt (regenerates with defaults if deleted).

FULL CONTROLS REFERENCE: see CONTROLS.txt next to this file -- every one of
the pod's 72 cockpit buttons, what it does, and which display it sits on.

COCKPIT LAYOUT: content\environ.ini (written on first run, every option
documented in the file itself) sizes the MFDs and the map, moves the map out
of the middle of the road, or breaks each display into its own window.  The
cockpit now scales to ANY window shape without distorting -- drag it, maximise
it, or launch with -fit for borderless full screen.

This build: {VERSION}.  Private -- do not redistribute.
{EXPIRE}Test builds STOP WORKING 14 days after they are made -- if the game
{EXPIRE}says it has expired, just grab the operator's newest zip.