CydandClaude Opus 5 c1729e40c7 The callsign and loadout outlive the session
The loadout has always survived a race - gPersistSelection is why the
setup screen reopens the way you left it - but only for as long as the
process lived. Closing the game was a reset, and the callsign is the one
thing on that screen a player types rather than picks, so it was the one
they had to type again every launch.

pilot.cfg beside bindings.txt now holds both, KEY=VALUE like environ.ini,
one line per group.

BT411 solved this first, in fe_last.ini, and its own comment says why
RP412 never grew the file: BT411 relaunches the process between missions
and would otherwise forget the loadout mid-evening, while RP412 stays in
one process. That made the gap invisible from inside a session and total
across two. Same idea, two differences worth naming:

  BT411 saves only on a launch - it returns before SavePersisted when
  the player quits. That loses a callsign typed by somebody who then
  changed their mind, which is exactly the moment this feature exists
  for, so this writes on the way out however the menu is left:
  launching, stepping into a lobby, or EXIT GAME.

  BT411 takes the stored name as-is. A callsign here is quoted into
  frontend.egg, joined into a comma-separated list for the results
  screen, and published as Steam lobby member data, so a comma alone
  would split one pilot into two on the score sheet. SanitizeCallsign
  drops what could end a token early and is applied to what is typed as
  well as to what is read, so the file cannot hold what the game will
  not accept.

Every index is range-checked on the way in, against the group's real
size rather than a constant - the track list is the one that moves,
since football and the death race carry different maps, so it answers
for whichever scenario is selected. The track is re-checked after the
whole file is read as well, because the file is parsed in the order it
happens to be written and the scenario may arrive second.

Written unconditionally rather than only on a change: it is a few
hundred bytes, and writing every time means a value hand-edited out of
range comes back corrected instead of being quietly re-rejected on every
launch forever.

Verified by round trip. A callsign typed and then abandoned via EXIT
GAME is in the file and back in the box next launch. A file carrying
   Ba"d,Na#me   loads as BadName; an empty one falls back to Pilot. A
full loadout round-trips value for value; vehicle=999 and color=-3 come
back 0 with the rest untouched; and track=9 under football falls back to
0 both when the scenario is read first and when it is read second, which
is the case the second check exists for.

One correction to my own test rig on the way: cross-process
SetWindowText on an EDIT updates the cached caption, which an external
GetWindowText then reads back happily, while leaving the control's own
buffer alone - so the harness looked right and the game correctly saw
the old name. WM_SETTEXT is marshalled properly and shows the truth.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 12:56:15 -05:00
2026-08-05 10:18:43 -05:00

Red Planet 4.12 — the Steamification

Red Planet is VWE's pod-racing game: eight-player VTV contests on Mars — Martian Death Race and Martian Football — originally played from inside VWE Tesla cockpit pods. This repo is the third life of that code:

Generation What it was
Red Planet 4.10 The original game, running on the Tesla 1 pod platform (DOS-era MUNGA engine, serial RIO cockpit hardware, operator console, batch-file relaunch between missions)
Red Planet 4.11 The Win32 port of 4.10 (RP411) — DirectX 9, WinSock TCP, TeslaConsole/TeslaLauncher session control; still runs in pods, still a LAN
Red Planet 4.12 This repo: the Steamification of 4.11 — the same engine, the same wire protocol, the same missions, made distributable on Steam and playable over the internet with no cockpit hardware

The architecture is deliberately conservative: the VWE's design survives intact, with each pod-era dependency replaced by a consumer equivalent behind the engine's existing seams.

Arcade (4.10/4.11) 4.12 replacement
RIO cockpit board (serial) PadRIO — virtual RIO from XInput pad + keyboard, fully rebindable (bindings.txt, vRIO profile format)
Seven physical displays Single-window cockpit — all displays composed on a locked 1920×1080 canvas around the viewscreen, with the real button banks lamp-lit and clickable
Pod button lamps On-screen lamps, plus an RGB keyboard mirror (Windows Dynamic Lighting)
TeslaConsole operator In-game front end — race setup menu builds the mission egg locally; an in-process console marshals every race (missions still only end on a console stop, exactly as designed in 1994)
TeslaLauncher relaunch-per-mission Single binary — menu → race → results → menu in one process
WinSock TCP LAN mesh NetTransport seam — the deterministic pod mesh unchanged, running over plain TCP (LAN/dev) or Steam Networking Sockets (FakeIP + Steam Datagram Relay)
Site network / fixed IPs Steam lobbies — lobby owner is the console; members exchange FakeIPs and loadouts as lobby data

Status: it works. v4.12.2 carried the first verified end-to-end internet build: three machines, three Steam accounts, lobby → mesh → marshaled five-minute race → deaths and respawns → timed stop → results on every machine → rematch from the same lobby.

v4.12.3 is about the screen. The cockpit now scales up as well as down and re-fits whenever the window changes, keeping 16:9 so a wide panel letterboxes instead of stretching; -fit runs it borderless over the whole monitor and picks the render size to land on the viewscreen 1:1. The displays are the player's to arrange — each of the six can be scaled on its own and the radar moved out of the middle of the road (environ.ini). Each display's button bank now reaches under its glass, so the picture itself is the press target rather than a sliver at the edge.

v4.12.4 is about the lobby. Both rooms now show the host's mission setup — the track, then time of day, weather and game length — since everyone flies the owner's picks and it was the one thing in the room nobody could see for themselves. The football team sheet names each player's VTV beside their team colours and position. And a lobby holds eight players rather than four, a full grid as the pod hall ran it, with the room sizing its roster to whatever space the window gives it.

v4.12.5 restores the Winners Circle. The pod hall stood the finishers on a numbered award platform when the race ended, and all of it was still in this repo — the stand, eight ranked spots in every map, and the code to put racers on them — wired only into the mission-review build and so never once run by a pod. The race now fades out and fades back in on the platform: finishers in finishing order, each pilot's callsign on the plate beside their spot, the cockpit glass cleared away, held for a few seconds before the results screen. Three pieces of it had been stubbed out in the D3D9 port and are working again.

v4.12.6 is about the windows. Where you put them now survives the menu-race-menu loop: RP412MFDLAYOUT remembers the game window, the exploded view's display panes and the plasma glass in mfd_layout.cfg beside bindings.txt. Append ,noframe to a line to take that window's title bar and border off — a cockpit filling the monitor edge to edge at a rect you chose, rather than -fit taking the whole screen — and the setup screen carries its own EXIT GAME button, since a window with no title bar needs a way out. The Steam buttons now dim and say STEAM NOT RUNNING instead of disappearing. And the Winners Circle camera is framed off the award stand itself rather than off whoever is standing on it, so the shot is the same one for every player at every head count.

v4.12.7 is about sticks. Anything that is not an Xbox-class pad — a flight stick, a HOTAS throttle, a twist grip, rudder pedals, a wheel — comes in through DirectInput rather than XInput, and the game could not see any of it. Now it can, and joyconfig.bat sets it up: the wizard asks you to move each control in turn, works out which device and axis answered and which way round it reads, and writes the joystick rows of bindings.txt, leaving anything you have edited yourself alone. A twist grip or rudder bar drives both pedals through one signed Pedals axis, and a real throttle lever owns its channel outright rather than nudging a position the way a spring-centred stick has to. Ported from the sibling BT411.

Playing

Grab the release zip (or run pack-dist.ps1 on a build). Single player: run start-windowed.bat — the game boots into the setup menu, where the SCENARIO group picks Death Race or Football (Football swaps in the team/position columns and its own track list). Steam multiplayer: see docs/STEAM-3-MACHINE-TEST.md (until RP412 has its own AppID it runs under Spacewar, 480).

The two config files beside the exe are self-documenting: environ.ini (every engine option, commented) and bindings.txt (every key, pad button, and axis; written with the full default layout on first run). Default controls: numpad flies (8/2/4/6 stick, 7/9 pedals, 0 trigger), Shift/Ctrl throttle, Alt reverse, arrows look, Space fires, letter rows are the MFD button banks as printed on the panel. Alt+Q aborts a mission. Full map with pad and keyboard diagrams: docs/CONTROLS.md.

Building

VS 2022 (v143) + DirectX SDK June 2010 + the vendored Steamworks SDK (extern/steamworks_sdk_164) — see BUILD.md. Solution WinTesla.sln, configuration Release|Win32, output Release\rpl4opt.exe.

Documentation

Doc Contents
docs/CONTROLS.md Controls map — pad and keyboard diagrams, the panel button banks, rebinding
docs/RP412-ROADMAP.md The original plan and workstreams
docs/RP412-FRONTEND-DESIGN.md TeslaConsole analysis, the egg format, the console protocol, and the Steam mapping — with status notes as each layer landed
docs/STEAM-3-MACHINE-TEST.md Multiplayer test procedure, Steam Input notes, the abort key
BUILD.md Toolchain and build steps

Dev tooling: tools/two-pod-test.ps1 races two pods on loopback, marshaled by a console feeder speaking the arcade Munga protocol.

Repo Role
RP411 Upstream: the Win32 arcade port this repo Steamifies (full history preserved; remote rp411 for cross-pulling fixes)
VRIO Virtual RIO panel + vPLASMA — source of the bindings format, the cockpit layout, and the keyboard lamp mirror
TeslaSuite TeslaConsole / Launcher / vPOD — the arcade session-control stack 4.12 absorbed (and the reference implementation of the Munga control protocol, TCP 1501)
S
Description
No description provided
Readme
121 MiB
Languages
C++ 86.4%
C 12.7%
PowerShell 0.5%
Python 0.2%
Assembly 0.2%