arcattackandClaude Opus 5
145bf368c8
Operator report while trying the build: the window said the game had exited
"with an error", yet the game loaded and played fine.
There was no error. The launchers were lying. The front end does NOT stay
resident: btl4console.cpp CreateProcessW()es the mission generation, closes
both handles and ExitProcess(0)s itself. So the bat's child exiting means
"the menu handed off", not "the game closed". All four launchers then
immediately printed
[.. ] btl4.exe exited with code 0
The game has exited. If it closed unexpectedly, send the operator ...
while the game was still loading in the handed-off process. Verified live on
the operator's own session: first process pid 33352 = MENU profile, handed off
to pid 12564 = GLASS profile, which was the one actually running; exit code 0
throughout. Harmless in itself, but it reads as a crash to a playtester and
would have generated false bug reports on a test night.
FIX: after the front-end child exits, poll until no btl4.exe remains, THEN
report. Applied to play_solo / join / join_lan / play_steam.
The #41 launch forensics are preserved: an exe that dies before it can run
leaves no process, so the wait falls straight through and launch_report.txt
still records timing, exit code and whether the log was ever created.
Verified the wait condition both ways against the live session (read-only, no
second instance spawned): btl4.exe present -> WOULD-WAIT; absent -> WOULD-EXIT.
NOTE for future edits: players/ is the SOURCE OF TRUTH (mkdist packages from
there, tools/mkdist.py:78); the root-level copies are gitignored local
conveniences AND were LF-only, while players/ is correctly CRLF. Since this
change adds a `goto` label -- the construct most likely to misbehave in an
LF-only bat -- the root copies have been re-synced byte-identical from
players/ so local runs match the shipped artifact.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
73 lines
3.3 KiB
Batchfile
73 lines
3.3 KiB
Batchfile
@echo off
|
|
rem BT411 -- join the operator's LAN game.
|
|
rem BT_RELAY = the operator PC's LAN IP + console port (auto-discovery was
|
|
rem unreliable on this network, so it is pinned). If the operator's IP changes,
|
|
rem update the address below (find it on the operator PC with `ipconfig`).
|
|
rem Joining over the INTERNET? Use join.bat instead.
|
|
cd /d %~dp0
|
|
rem ONE unified build (2026-07-21): the exe carries every layer; the GLASS
|
|
rem platform env arms the desktop cockpit (clickable MFD buttons, trigger
|
|
rem config, bindings.txt keymap).
|
|
set BT_PLATFORM=glass
|
|
if not exist "build\Release\btl4.exe" goto badpath
|
|
if not exist "content\OPERATOR.EGG" goto badpath
|
|
set BT_RELAY=10.0.0.46:1500
|
|
rem one fresh log per bat run; the menu->game relaunch chain APPENDS
|
|
rem so every generation's lines survive (0-byte logs = killed pre-start)
|
|
if exist content\join.log del content\join.log
|
|
set BT_LOG=join.log
|
|
set BT_LOG_APPEND=1
|
|
set BT_START_INSIDE=1
|
|
set BT_DEV_GAUGES=1
|
|
cd content
|
|
rem JOIN-GAME menu (2026-07-22): pick your CALLSIGN + MECH, click JOIN --
|
|
rem your choice is sent to the operator and lands in the mission roster.
|
|
set BT_FE_JOIN=1
|
|
rem LAUNCH FORENSICS (#41): bracket the exe from outside -- if it dies
|
|
rem before it can write its own log, this report still records when it
|
|
rem ran, how it exited, and whether it ever created its log at all.
|
|
echo [%DATE% %TIME%] launching btl4.exe > launch_report.txt
|
|
..\build\Release\btl4.exe
|
|
set BT_EXITCODE=%ERRORLEVEL%
|
|
echo [%DATE% %TIME%] btl4.exe exited with code %BT_EXITCODE% >> launch_report.txt
|
|
if not exist join.log echo join.log WAS NEVER CREATED: the exe was blocked before it could run (loader failure or antivirus) >> launch_report.txt
|
|
if exist join.log for %%A in (join.log) do echo join.log size: %%~zA bytes >> launch_report.txt
|
|
|
|
rem ------------------------------------------------------------------
|
|
rem HANDOFF WAIT (2026-07-25). The front end does NOT stay resident: it
|
|
rem CreateProcess()es the mission generation and ExitProcess(0)s itself
|
|
rem (btl4console.cpp). So OUR child exiting means "the menu handed off",
|
|
rem NOT "the game closed" -- without this wait the window announced "The
|
|
rem game has exited" while the game was still loading, which reads as a
|
|
rem crash to a playtester. Wait for the handed-off generation(s) to go.
|
|
rem A genuinely dead exe leaves no process and falls straight through, so
|
|
rem the #41 launch forensics above still work.
|
|
rem ------------------------------------------------------------------
|
|
:btwait
|
|
tasklist /FI "IMAGENAME eq btl4.exe" /NH 2>nul | find /I "btl4.exe" >nul
|
|
if not errorlevel 1 (
|
|
timeout /t 2 /nobreak >nul
|
|
goto btwait
|
|
)
|
|
echo.
|
|
echo The game has exited. If you did NOT quit on purpose
|
|
echo (crash, or it never connected), send the operator BOTH files:
|
|
echo content\join.log and content\launch_report.txt
|
|
echo Otherwise the session may not be up yet -- try again.
|
|
pause
|
|
exit /b
|
|
:badpath
|
|
echo.
|
|
echo ==================================================
|
|
echo ERROR: this file is not in the right place.
|
|
echo.
|
|
echo It must sit in the EXTRACTED game folder, next to
|
|
echo the 'content' and 'build' folders.
|
|
echo.
|
|
echo Fix: right-click the .zip - Extract All, open the
|
|
echo extracted folder, and run this file from THERE.
|
|
echo (Do NOT run it from inside the zip.)
|
|
echo ==================================================
|
|
echo.
|
|
pause
|