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>
TeslaConsole
Reconstructed C# source for the original TeslaConsole.exe — the operator
console that drives the cockpit pods (the counterpart to TeslaLauncherService
/ TeslaLauncherAgent).
Provenance
This source was recovered by decompiling the original managed assembly with
ILSpy (ilspycmd 7.2). The original
TeslaConsole.exe is a .NET Framework 2.0 WinForms application
(assets/Tesla Console/TeslaConsole.exe, dated 2012). The reconstructed project
here is retargeted to .NET Framework 4.8 so it builds with current tooling;
it is otherwise a faithful decompilation, not a rewrite.
Decompiled code is functionally equivalent to the original but not character-for-character identical to the lost sources. Local variable names, some control flow, and compiler-generated members differ. Treat this as a recovered baseline, not pristine source.
Dependencies
The console references these assemblies. Most are vendored as binaries under
lib/ (copied from assets/Tesla Console/):
| Assembly | Origin |
|---|---|
WeifenLuo.WinFormsUI.Docking.dll |
Third-party docking UI (open source, see assets/Tesla Console/WeifenLuo.txt) |
TeslaConsoleLaunchLib.dll |
Wire types / launch protocol — now built from source (see below) |
TeslaSecureConfiguration.dll |
First-boot secure config protocol — now built from source (see below) |
Munga Net.dll |
Managed C# client for the Red Planet game's Munga protocol (TCP 1501); manual binary serialization, no BinaryFormatter (proprietary, vendored) |
BitmapLibrary.dll |
Plasma-display bitmap rendering (proprietary, vendored) |
The Red Planet game itself is C++ and lives in its own repo (
c:\vwe\rp411/gitea.mysticmachines.com/VWE/RP411.git). That source defines the Munga protocol but is not a drop-in for the managedMunga Net.dllabove, so it is not vendored here.
Two of these are no longer vendored binaries — they are built from source and shared across the suite:
TeslaConsoleLaunchLib←../Contract/Tesla.Contract.csproj(net40, like the whole suite since XP11): the single source of truth for the Console↔Launcher RPC contract (wire types, thePodManagerConnectionclient, and the framed-JSONPodRpcprotocol), shared with the Launcher. The assembly keeps theTeslaConsoleLaunchLibname so the original-exe baseline still resolves in the differential tests; the wire no longer embeds assembly names (see RPC note below).TeslaSecureConfiguration←../SecureConfig/Tesla.SecureConfig.csproj(net40), the first-boot provisioning protocol (UDP beacons, OFB crypto, RSA key exchange).
The original TeslaSecureConfiguration.dll is retained under lib/ as the baseline
for the byte-identical crypto guard (SecureConfigCompatTests). The remaining
vendored assemblies (Munga Net, BitmapLibrary) are .NET 2.0 managed and could be
decompiled to source the same way if full-source builds are needed.
Console ↔ Launcher RPC (no BinaryFormatter)
The pod-management channel (TCP 53290) runs length-prefixed JSON
frames over the existing OFB-encrypted stream — see Contract/PodRpcProtocol.cs,
shared verbatim by both ends (Newtonsoft.Json — net40 has no System.Text.Json).
This replaced the original BinaryFormatter +
serialized-MethodBase scheme (a remote-code-execution sink, and what had pinned the
Launcher to an old runtime); dispatch is now by method-name string. The Launcher and
the Console both target net40 (XP11: XP SP3 through Windows 11). Note the Console
still uses BinaryFormatter for local disk persistence (Site config, mission
results) — that is local file I/O, not the network surface, and is intentionally
left alone.
Layout
This folder is self-contained — it can be lifted out into its own repository and still build and run.
TeslaConsole/
*.cs, TeslaConsole.*/ decompiled source (by namespace)
*.resx, app.ico string resources + icon
assets/icons/ UI images (raw originals, embedded as manifest resources —
the resx BinaryFormatter blobs cannot build for net40)
TeslaConsole.csproj net40 project (XP11: runs on XP SP3 through Windows 11)
RedPlanet/ runtime content (RPConfig.xml, RPStrings.xml) — copied to output
images/ source art (pod art / maps / vehicles) — reference only
installer_banner.bmp installer artwork — reference only
lib/ referenced binaries + WeifenLuo license
original/ original TeslaConsole.exe + .InstallState — reference baseline
Building
Requirements: .NET SDK (6.0+) — the Microsoft.NETFramework.ReferenceAssemblies
NuGet package supplies the net40 reference assemblies, so a standalone Framework
targeting pack is not required.
dotnet build TeslaConsole.csproj -c Release
Output: bin/Release/net40/TeslaConsole.exe (with RedPlanet/ and all
dependency DLLs copied alongside it).
Runtime content
RedPlanet\RPConfig.xml,RedPlanet\RPStrings.xmlare loaded relative to the exe and are copied to the build output automatically.Plasma Images\*.bmp(under%ProgramData%) is an optional override set; when absent the console renders plasma-display text procedurally, so it is not required to build or run.
Notes
- The
.resxresources embed BinaryFormatter-serialized bitmaps. The project setsGenerateResourceUsePreserializedResourcesand referencesSystem.Resources.Extensionsso these build under the modern SDK. - Namespaces:
TeslaConsole(UI + pod management),TeslaConsole.RedPlanet(the Red Planet game scenario/mission model),TeslaConsole.Properties(settings + resources).