The eight internet pod rows are furniture the operator builds once in
Manage Site — the slot-to-IP map is frozen — but which of those slots a
human actually claimed changes every session. New SessionRoster reads the
roster TeslaLobby writes at the state=launching flip, and both game panes
grow a session strip above Mission Properties: a banner (session key, game,
slots claimed, waiting, written-at), Apply Session, and the Reset Pods that
until now existed only as a right-click on a Go button that is disabled
exactly when the reset is wanted.
Two properties shape all of it. Only claimed slots appear in the file, so
absence is the unclaimed signal and every failure path — truncated, stale,
unreadable, refused — degrades to "no roster", which is byte-for-byte
today's arcade behaviour; museums run this software and a bad JSON file
must never stop a mission that would otherwise run by hand. And enabled
implies claimed, not the reverse: the operator may always sit a pilot out,
never add one, because an enabled row nobody claimed puts a dead IP in the
egg and the pods then wait on a peer that will never boot. Roster issues
join the pane's existing issue text, so the Go button is still the gate.
The roster is one file per launch generation and deliberately not a live
view: pod peer tables are boot-static, so a player whose lobby crashed is
still in every pod's table and still playable, and live tracking would
evict that working pod mid-session. Poll runs at ~1Hz off the existing
network timer with its own deadline, and the strips are built at runtime —
InitializeComponent is decompiled 1995 designer output that the
differential tests compare literally.
Go/Load also re-checks CheckAllValues at the click instead of trusting the
last status tick: a pod that died in that gap went straight into the
mission, and the post-Load barrier in NetworkScan then waited forever for a
WaitingForLaunch that never arrives.
vPOD gains -bind <ip>. Both listeners defaulted to IPAddress.Any, so a
second vPOD on the machine lost the port and the console could only ever
see one fake pod; binding each instance to its own address runs a whole
eight-pod session side by side with no cockpits. Bind all of them or none —
Windows lets IPAddress.Any take a port that specific addresses already
hold, and the unbound instance then answers for every slot nobody claimed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The per-page "DOSBox IPs (+100)" checkbox becomes a single machine-level
setting per game, edited in Settings > Change <game> Defaults (a "DOSBox
Build" row below Autotranslocate Delay) and persisted in the game's
defaults file (RPDefaults.rpd / BTDefaults.btd) as a top-level
DosBoxAddressShift element.
The game pages no longer carry the checkbox; each RPGame/BTGame reads the
stored default once at construction into a readonly field and applies it
when enabling a pod (MungaGame.DosBoxAddressShift) and when building the
mission egg (MissionAddress). Since it is read at construction, an
already-open game page keeps its shift until reopened -- consistent with
how every other game default behaves.
Verified against vPOD: enabling the DOSBox default drives a freshly
opened game page's pod connection to 127.0.0.101 and the egg to
pilot=127.0.0.101 with no per-page control; unchecking round-trips to
False in the defaults file. All 103 diff tests pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Same row instead of a fourth row below it: the mission-properties table
gains a ninth column holding the checkbox at (7,2) and the issues label
moves to column 8, so the group box returns to its original height.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The DOSBox-X preservation pods run the original DOS builds of BattleTech
4.10 / Red Planet 4.10 inside an emulator whose bridged NIC is enumerated
100 above the host pod's last octet. A new checkbox on each game page
(RP Death Race / Martian Football, BT Free For All / No Return) shifts
every siteconfig address the page uses by +100 so the same pages control
either version of the games:
- Munga game connections (port 1501) target host+100; toggling the box
drops and reconnects any requested pods at the new address.
- Mission egg player and camera entries carry the shifted address.
- The checkbox locks while a mission is loaded/running, like the other
mission properties.
Launcher / site-management traffic is untouched -- those services still
run on the pod host itself. Pages share a pod's MungaGame, so the most
recent page to toggle or enable wins if two pages fight over one pod.
Verified end-to-end against vPOD: netstat shows the game connection move
127.0.0.1 -> 127.0.0.101 -> 127.0.0.1 as the box is toggled, and the egg
received by vPOD carries pilot=127.0.0.101. All 103 diff tests pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-locate the two cockpit-pod projects into a single repository:
- Console/ : TeslaConsole, the net48 WinForms operator console (decompiled
reconstruction) plus its differential + catalog test suite.
- Launcher/ : TeslaLauncher, the net6 pod-side Service + Agent rewrite.
Adds a combined TeslaSuite.sln, root README documenting the shared wire
contract (and its current duplication, the main follow-up), and a root
.gitignore. Histories were not preserved per request; this is a fresh start
from the current working state of both projects.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CydandClaude Opus 5