CydandClaude Opus 5
33f734da2d
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>
TeslaSuite
The Tesla cockpit-pod software, in one repository:
| Folder | What it is | Target |
|---|---|---|
Console/ |
TeslaConsole — the operator console (WinForms) that configures and drives the pods. A decompiled reconstruction of the original TeslaConsole.exe (now the modernized 4.11.4.x line), with a differential test suite pinning it to the original 4.11.3.37076 baseline. |
.NET Framework 4.0 |
Launcher/ |
TeslaLauncher — the pod-side launcher: ONE userland tray app (RPC listener + app launcher). A clean rewrite of the original; the old Service+Agent split (a Session 0 workaround) is gone. | .NET Framework 4.0 |
Contract/ |
Tesla.Contract — the shared Console↔Launcher RPC contract: wire types, the client, and the framed-JSON protocol. Emits assembly TeslaConsoleLaunchLib. |
.NET Framework 4.0 |
SecureConfig/ |
Tesla.SecureConfig — the first-boot pod provisioning protocol (UDP beacons, OFB crypto, RSA key exchange). Emits assembly TeslaSecureConfiguration. |
.NET Framework 4.0 |
vPOD/ |
vPOD — a virtual pod for testing the consoles without cockpit hardware: impersonates both the game client (Munga, TCP 1501) and the pod's TeslaLauncher (provisioning + Site Management / Install Product on TCP 53290). | .NET Framework 4.0 |
Everything targets net40 on purpose (the XP11 port, v4.11.4.3): it is the newest
.NET Framework that installs on Windows XP SP3, and net40 assemblies run in-place on
the 4.8 runtime that ships in Windows 10/11 — so the same binaries cover the original
XP-era cockpit PCs and modern hardware. That rules out net45+ APIs
(System.Text.Json, ZipFile, async/await, ...); JSON is Newtonsoft, zip extraction
is the launcher's own MiniZip.cs.
The console and launcher talk over TCP 53290 using length-prefixed JSON
frames over an OFB-encrypted stream (Contract/PodRpcProtocol.cs),
dispatched by method name. The wire contract lives in one source project
(Contract/) referenced by both sides — a single source of truth, no
duplication or hand-syncing.
Note: Red Planet game control uses a separate protocol (Munga, TCP 1501) via the vendored
Munga Net.dll— not the RPC channel above. The game itself is C++ and lives in its own repo (gitea.mysticmachines.com/VWE/RP411.git).
Building
dotnet build TeslaSuite.sln -c Release
dotnet test Console/tests/TeslaConsole.DiffTests # differential + protocol + crypto guards
Pod deployment: Launcher/build.bat publishes the
framework-dependent net40 package into Launcher/dist/ — the launcher itself is tiny,
but the package bundles the pod redists (DirectX June 2010, OpenAL, UltraVNC, and
dotNetFx40_Full_x86_x64.exe for XP-era pods that don't have .NET 4.0 yet).
Launcher/install.bat deploys it on a cockpit PC — dual-OS
(XP SP3 and Win10/11 code paths): auto-login, Run-key registration for the single
launcher binary, firewall + box hardening. The operator console packages
the same way: Console/build-package.bat → Console/dist/,
installed with Console/install.bat. vPOD packages with
vPOD/pack.ps1 → vPOD/dist/vPOD.zip, deployable to a pod via the
console's Install Product (or run directly on any machine).
Release packages for all three are attached to the Gitea releases (latest: v4.11.4.3).
Layout notes
Console/original/TeslaConsole.exe— the 4.11.3.37076 reference baseline the differential tests compare against. Keep it.Console/lib/*.dll— the remaining vendored binary dependencies (Munga Net,BitmapLibrary,WeifenLuodocking). The originalTeslaConsoleLaunchLib.dllandTeslaSecureConfiguration.dllare also kept here, but only as byte-compatibility test baselines — both are now built from source (Contract/,SecureConfig/).Console/RedPlanet/Apps.xml— the data-driven product catalog (see the console's Site Management → Add Product / Register Product on Pods).
History
The system was modernized in 2026: the duplicated wire contract was extracted to a single
source project, BinaryFormatter (an RCE sink, and what pinned the launcher to an old
runtime) was replaced with the framed-JSON protocol, and the launcher was rebuilt — briefly
on net8/x64, then on net48, then (the XP11 port, v4.11.4.3) the whole suite settled on
net40 so one set of binaries runs on the original Windows XP SP3 cockpit hardware and
on Windows 10/11 alike. XP11 also merged the launcher's Service+Agent pair — a workaround
for Vista+ Session 0 isolation that XP never needed — back into a single userland app, and
moved the console's .resx BinaryFormatter bitmaps to raw embedded images (their runtime
reader doesn't exist on net40). The whole console↔pod path (provisioning, install, launch)
is validated on real pods; the net40 build is bench-validated on Win11's 4.8 runtime (real
XP SP3 hardware still pending).