arcattackandClaude Opus 5
bf40c53e1e
Regression in my own fix from an hour ago, reported immediately by the
operator on relaunch:
find: '/I': No such file or directory
find: 'btl4.exe': No such file or directory
The game has exited. ...
The wait loop called bare `find`, which resolves to the MSYS/Git-Bash **Unix**
find on any box with git on PATH (confirmed here: `which find` ->
/usr/bin/find, `which timeout` -> /usr/bin/timeout). So the loop errored out
and fell straight through -- restoring exactly the misleading "The game has
exited" message it was meant to remove. `timeout` was the same exposure one
line later (GNU coreutils ships one, with different arguments), so the block
had TWO PATH-dependent failures.
Harmless to the game (the loop only reports; it never touched the session),
but it made the fix a no-op for anyone with git installed -- which is every
developer and a fair number of players.
FIX: no external tools at all.
* detection is now a pure-cmd `for /f "tokens=1"` over tasklist output,
comparing the first token to btl4.exe -- no find/findstr;
* tasklist and timeout are both invoked by ABSOLUTE %SystemRoot%\System32
path, so a shadowing PATH cannot reach them.
Failure modes stay safe: if tasklist is unavailable the variable never gets
set and the loop degrades to reporting immediately (the old behaviour, never a
hang), and a genuinely dead exe still falls straight through so the #41 launch
forensics are untouched.
VERIFIED both branches by running the shipped detection lines from THIS bash
shell -- i.e. the hostile shadowed PATH that broke v1, a harder case than a
playtester's clean environment:
game running -> RESULT: WOULD-WAIT [process detected]
absent-name control -> RESULT: WOULD-EXIT [no process]
No find/timeout errors in either.
(players/ is the shipped source per tools/mkdist.py:78; the gitignored root
copies re-synced byte-identical.)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
71 lines
3.0 KiB
Batchfile
71 lines
3.0 KiB
Batchfile
@echo off
|
|
rem BT411 -- STEAM play (EXPERIMENTAL, dev testers). Launches the glass
|
|
rem front-end menu: HOST a Steam lobby or JOIN one from the menu -- there
|
|
rem is no address to configure; sessions form through the Steam lobby.
|
|
rem Requires: the Steam client RUNNING and logged in, and the steam build
|
|
rem extracted next to content\.
|
|
cd /d %~dp0
|
|
if not exist "build\Release\btl4.exe" goto badpath
|
|
if not exist "content\BTL4.RES" goto badpath
|
|
set BT_PLATFORM=glass
|
|
set BT_STEAM_NET=1
|
|
if exist content\steam.log del content\steam.log
|
|
set BT_LOG=steam.log
|
|
set BT_LOG_APPEND=1
|
|
rem Cockpit view + MFD gauges -- the same client flags the join bats set
|
|
rem (field report: players booted 3rd-person without them). Inherited by
|
|
rem the menu's mission relaunch.
|
|
set BT_START_INSIDE=1
|
|
set BT_DEV_GAUGES=1
|
|
rem full menu here (all modes + steam buttons); clear the solo trim in
|
|
rem case this shell ran play_solo.bat first
|
|
set BT_FE_SOLO=
|
|
cd content
|
|
..\build\Release\btl4.exe
|
|
|
|
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
|
|
rem NO EXTERNAL TOOLS: `find`, `findstr` and `timeout` are all shadowed by
|
|
rem Git-Bash / MSYS / GnuWin32 builds of the same names when those are on
|
|
rem PATH (a dev box, or a player who installed git). The MSYS `find` is
|
|
rem the Unix one and dies with "find: '/I': No such file or directory",
|
|
rem and GNU `timeout` takes different arguments. So: parse tasklist with
|
|
rem a pure-cmd for/f, and call both helpers by ABSOLUTE System32 path.
|
|
rem A genuinely dead exe leaves no process and falls straight through, so
|
|
rem the #41 launch forensics above still work. If tasklist is missing
|
|
rem entirely the loop degrades to reporting immediately -- the old
|
|
rem behaviour, never a hang.
|
|
rem ------------------------------------------------------------------
|
|
:btwait
|
|
set "BT_STILL_RUNNING="
|
|
for /f "tokens=1" %%P in ('%SystemRoot%\System32\tasklist.exe /FI "IMAGENAME eq btl4.exe" /NH 2^>nul') do (
|
|
if /I "%%P"=="btl4.exe" set "BT_STILL_RUNNING=1"
|
|
)
|
|
if defined BT_STILL_RUNNING (
|
|
%SystemRoot%\System32\timeout.exe /t 2 /nobreak >nul 2>nul
|
|
goto btwait
|
|
)
|
|
echo.
|
|
echo The game has exited. If it closed unexpectedly, send the operator
|
|
echo content\steam.log. Steam not running = the menu still works but
|
|
echo lobbies will not appear.
|
|
pause
|
|
exit /b
|
|
:badpath
|
|
echo.
|
|
echo ==================================================
|
|
echo ERROR: this file is not in the right place, or
|
|
echo the zip was not fully extracted.
|
|
echo.
|
|
echo It must sit in the EXTRACTED game folder, next to
|
|
echo the 'content' and 'build' folders.
|
|
echo ==================================================
|
|
echo.
|
|
pause
|