"Race" is Red Planet's term (it's a racing game) and rode in with the
RPL4LOBBY port. In BattleTech the gameplay unit is a MISSION. Sweep it out
of the front-end / lobby / marshal code + the roadmap and steamification
digest: rename the public API BTLobby_Push/PullRaceResults ->
Push/PullMissionResults, the internal PrimeHostedRace -> PrimeHostedMission,
the deferred marshal InstallNetworkRace -> InstallNetworkMission, and the
user-facing strings ("STEAM MISSION LOBBY", "L A U N C H M I S S I O N",
"HOST/JOIN STEAM MISSION"). Comments follow. No behavior change; both gates
(default + BT412_STEAM) still build + link clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Port RP412's RPL4LOBBY to BT: an ISteamMatchmaking room stands in for the
arcade Site-Management screen. Compiled both gates -- stubs without
BT412_STEAM, the full room under it (both configs build + link clean).
Lobby (game/reconstructed/btl4lobby.*):
- Room screen (green-on-black, like the menu), owner = console.
- Member data: FakeIP + fake console/game ports + persona + mech/color/badge
(ip/cp/gp/nm/vh/cl/bd keys).
- Nonced "go" launch roster -> SteamNetTransport_RegisterPeer for every peer.
- Push/PullRaceResults over lobby data rebuild the shared score sheet.
Front end (btl4fe.*): HOST/JOIN buttons when BTLobby_Available() (Steam
transport up); the menu loop exits on a steam action and BTFrontEnd_Run
routes the lobby outcome -- host builds the egg with every member as a
[pilots] mesh entry (BTFrontEnd_SetHostedPilots), member returns launch
mode 2. Results screen prefers the marshal's collated result names.
Marshal (btl4console.*): add GetResultName / ClearResults / InjectResult so
the lobby owner can refill the sheet from the collated wire scores; Result
gains a name field.
WinMain (btl4main.cpp): install the Steam transport on BT412STEAM env
(before the front end, so the lobby is offered); branch on
BTFrontEnd_LastLaunchMode() -- host owns the marshal clock + joins the mesh,
member enters as a network pod on :1501 (SetNetworkCommonFlatAddress +
gConsoleLossEndsMission); Push (host) / Pull (member) results, then relaunch.
CMake: btl4lobby.cpp joins bt410_l4; that lib gets BT412_STEAM + the
Steamworks include under the gate. build-steam/ gitignored.
Deferred (untestable here -- needs Steam + multiple machines): the
host->member wire egg-feed marshal (InstallNetworkRace); a member currently
waits for a console connection nothing supplies, so a live host+member race
is blocked on it. The lobby object does not survive the per-mission
relaunch. docs/STEAM-3-MACHINE-TEST.md for BT not yet authored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Completes the marshal chain: menu -> mission -> timed stop -> results ->
relaunch. BT had no mission-end score flow; this builds one from the
data the Comm MFD pilotList already tracks.
- btl4console: at the timed stop (game thread, state still live) snapshot
each roster pilot's kills/deaths via the BTResolveRosterPilot /
BTPilotKills / BTPilotDeaths bridges; expose BTLocalConsole_ResultCount
/ GetResult.
- btl4fe: BTFrontEnd_ShowResults -- a GDI green-on-black 'MISSION COMPLETE'
scoreboard (PILOT / KILLS / DEATHS, slot 0 named from the menu), any
key or ~12s to dismiss; store the last pilot name.
- btl4main: show the scoreboard after a marshaled mission, before the
relaunch.
Verified: MISSION COMPLETE screen renders with the pilot row and the
snapshotted score (0/0 on a no-combat test run; the data path is the
same one the live Comm MFD reads).
Phase 5 (front end) COMPLETE: menu + egg builder + marshal + timed stop
+ results + single-binary (relaunch) loop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The in-process console that replaces the operator for solo play: it owns
the mission clock and ends the race at the chosen length, then relaunches
to the setup menu -- the arcade launcher behavior in one binary.
- engine/APPMGR: gPerFrameHook -- a per-frame observer called on the game
thread in RunMissions (the marshal's engine-safe tick site).
- btl4console.{hpp,cpp}: BTLocalConsole_Install/MissionCompleted -- the
marshal watches for RunningMission, starts the clock, and dispatches
Application::StopMissionMessage at expiry (BT_MISSION_SECONDS overrides
for testing). Confirmed: StopMission cleanly ends the mission and
RunMissions returns.
- btl4fe: expose BTFrontEnd_LastMissionSeconds; Enter=LAUNCH / Esc=quit in
the menu loop; BT_FE_AUTOLAUNCH quick-launch (skips the menu).
- btl4main WinMain: front-end mode runs menu -> arms marshal -> mission;
when the marshal ends it, RELAUNCH a fresh instance (arcade launcher
model) -> lands back on the menu. This sidesteps BT's in-process
re-init fragility: a second mission in-process AV'd on stale gBT*
per-mission entity globals (gBTTerrainEntity et al., cdb-traced to
MakeEntityRenderables); a fresh process has none.
Verified: menu LAUNCH -> mission runs -> marshal stops it at the set
length -> RunMissions returns -> relaunch (3 distinct PIDs across a
multi-cycle run, no crash).
Remaining in Phase 5: the results screen (kills/deaths at stop).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The in-game menu that replaces the operator console. A GDI-painted
green-on-black terminal (RP412 RPL4FE pattern) in its own top-level
window, shown in front-end mode (no -egg/-net) before the mission:
- Catalogs as clickable columns: MAP (8), MECH (8), COLOR (8), TIME,
WEATHER, LENGTH, plus a PILOT NAME edit box and a LAUNCH button.
Selected item highlighted; click cycles selections.
- LAUNCH fills a BTFeMission from the selections, writes the egg
(BTFeMission_WriteEgg -- the existing builder), and points the
standard -egg load path at it. Closing the menu quits the process.
- btl4main.cpp: front-end mode runs the menu; menu-close exits.
Verified end to end: no-args launch shows the menu; clicking LAUNCH
builds frontend.egg from the chosen map/mech/color/time/length and the
mission loads and runs (map=grass mech=bhk1 color=White time=day
length=300 from the default selections).
Remaining in Phase 5: the LocalConsole marshal (timed stop + results +
single-binary menu<->mission loop).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The core 'single-player without the operator console' capability: a
zero-argument launch now builds its own mission and plays.
- game/reconstructed/btl4fe.{hpp,cpp}: the BattleTech catalog (8 maps,
8 mechs + variants, colors) and BTFeMission_WriteEgg -- emits the exact
console egg format (verified against content/MP.EGG): [mission],
[ordinals] + the 4 static rank-place plasma bitmaps, [pilots],
per-pilot loadout sections, and [largebitmap]/[smallbitmap] with
GDI-rendered 128x32 / 64x16 pilot-name plasma bitmaps.
- L4APP.H: SetEggNotationFileName / SetNetworkCommonFlatAddress setters
(from RP412) so the front end feeds the standard -egg load path.
- btl4main.cpp WinMain: front-end mode -- no -egg and no -net builds
frontend.egg locally (BTFrontEnd_Run) and boots it. -egg/-net runs
are untouched.
Verified: no-args launch -> '[frontend] built frontend.egg' -> mission
loads and runs; the generated egg is structurally identical to MP.EGG
(32x32/16x16 name bitmaps with real glyph pixels, all sections present).
Remaining in Phase 5 (deferred): the interactive on-screen catalog menu,
the in-process LocalConsole marshal (mission clock + StopMission at
expiry + single-binary loop), and the score-intake/results screen (new
for BT -- no mission-end flow exists yet). (Phase 5 of the roadmap)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Opus 4.8