Commit Graph
5 Commits
Author SHA1 Message Date
CydandClaude Opus 4.8 0434585566 Pack: wrap the dist zip in a single BT412/ folder
The zip previously stored files at the root (Compress-Archive -Path dist\*),
so extracting spilled loose files into the extraction directory. Build the
archive with .NET's ZipFile and prefix every entry with BT412/, so it extracts
into one self-contained BT412\ folder. Local staging dir stays dist\.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 11:06:52 -05:00
CydandClaude Opus 4.8 a3ee609cde Input: move the 1st/3rd-person view toggle to TAB
Per request, bind the cockpit (1st person) / external chase camera (3rd person)
toggle to TAB instead of F1. Still a desktop-only convenience on `focused`
(always live, even under PadRIO); V remains look-behind only. TAB is otherwise
unbound (the 0x09 in bindings.txt is a RIO button ADDRESS on the C key, not the
TAB virtual key). Dist README updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:54:35 -05:00
CydandClaude Opus 4.8 abeb7727e9 Input: split the V key -- look-behind stays, view toggle moves to F1
'V' was double-bound: the authentic look-behind (held) AND the cockpit/chase
view toggle (edge), so a single press flipped the camera while also looking
behind. Move the view toggle to F1 (unused); V is now look-behind only.

The view toggle is a desktop-only convenience (no RIO equivalent) so it stays
on `focused`, always live -- including under PadRIO. Look-behind keeps the
BT_DEVKEYS `gfocus` gate (a RIO device's binding owns it when engaged).

Dist README/environ.ini corrected to match reality: under L4CONTROLS=PAD the
default keyboard driving is the NumPad (WASD are MFD-bank buttons in the default
bindings.txt), the controller left stick drives, F1/backtick/V-hold are the
always-live desktop keys, and BT_DEVKEYS=1 re-enables the built-in quick keys.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:47:47 -05:00
CydandClaude Opus 4.8 77f019ed4f Net: host->member mission marshal -- a Steam/LAN mission plays end to end
The lobby could stage a room but the launched mission never fed the members.
BTLocalConsole_InstallNetworkMission (btl4console.cpp) makes the host play the
arcade console in-process over the NetTransport seam (Winsock TCP or Steam SDR):

  - connect to each member's console channel (ip[:port] from BT412HOSTPODS);
  - feed each the chunked egg (NetworkManager::ReceiveEggFileMessage, \n->NUL
    wire image like tools/btconsole.py), resending until it ACKs;
  - poll member state (StateQueryMessage); when the whole mesh is staged at
    WaitingForLaunch, dispatch RunMission to every member + locally at once;
  - StopMission at expiry (members first, then self after a short grace);
  - scores are BT's kills/deaths snapshotted from the *meshed* roster at the
    stop -- no EndMission wire intake (that flow is a BT stub; the mesh already
    put every pilot in the host's roster). The owner's own pod is fed locally
    via L4NetworkManager::FeedLocalEgg.

Engine change (ported 1:1 from RP412): gConsoleMarshalsLaunch (APPMGR.h/.cpp) +
the `!gConsoleMarshalsLaunch &&` guard in APP.cpp's WaitingForLaunch self-launch.
The owner has no console connection to itself, so without this it would
self-launch before the mesh staged and never send the coordinated RunMission.
Default False = stock behavior; solo boot un-regressed.

WinMain host path (btl4main.cpp) now honors BT412HOSTPODS (+BT412HOSTPORT) for
the lobby host AND a classic-LAN host: SetNetworkCommonFlatAddress +
InstallNetworkMission, falling back to a solo marshal if no member is reachable.

Verified (loopback): two `btl4.exe -net` pods fed by tools/btconsole.py reach
"All connections completed!" and run after the engine change -- the exact
protocol + launch handshake the marshal uses. Both gates build+link; the
Release dist boots and the Steam transport comes up. The live multi-machine
Steam mission (FakeIP mesh + pilot-slot matching) is untestable here -- see the
new docs/STEAM-3-MACHINE-TEST.md. Dist README updated: multiplayer is now
"newly implemented, please test" rather than deferred.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 07:30:17 -05:00
CydandClaude Opus 4.8 a92e3a5780 Pack: pack-dist.ps1 -- assemble a runnable Steam test dist (Phase 7)
Adapt RP412's pack-dist.ps1 for BattleTech. Assembles dist\ from a Release
Steam build (build-steam\Release\btl4.exe -- Release so it runs on a machine
without VS's non-redistributable debug CRT) plus steam_api.dll + OpenAL32.dll,
the content\ data (AUDIO/GAUGE/VIDEO, BTL4.RES, BTDPL.INI, the VREND
manifests, bindings.txt, DEV/MP/MP1 eggs), oalinst.exe (OpenAL fallback),
tools\btconsole.py, a TEST-only steam_appid.txt=480, a self-documenting
environ.ini (BT412STEAM=1 + the L4MFDSPLIT cockpit), start.bat, and a README
that states the multiplayer status plainly (lobby works; the host->member
mission feed is deferred; classic btconsole.py TCP path works today). -Zip
emits BattleTech-4.12.zip (~46 MB).

Verified: the Release exe boots a live DEV.EGG mission (optimizer-clean), and
the packaged exe run from dist\ brings the Steam transport up (FakeIP
allocated, lobby available) -- self-contained. dist/ + the zip are gitignored.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:41:34 -05:00