- Adopt the launch-key convention (documented in the Apps.xml header):
fresh Guid = product id, first Launch key reuses it, each extra entry
increments the last hex digit (wrapping F->0). Never a -1 suffix:
keys parse as System.Guid and silently collapse to Guid.Empty.
- Rewrite BT411 LC/MR + RIOJoy keys to the convention. RP4.11 LC/MR stay
pinned to the original console's hardcoded Guids (SiteManagement
constants + diff tests).
- Remove vPOD from the shipped catalog: dev tool, never a console-deployed
product (README documents the ad-hoc Add Product path instead).
- Add TeslaRel410 (DOSBox-X preservation pods): six entries, BT/RP 4.10 x
GameClient/LC/MR, all C:\Games\TeslaPod410\pod-launch.exe with mode
bt/rp. LC/MR boot identically (role assigned via egg hostType) and no
{res} token (output size fixed per rig at postinstall).
- CatalogTests: now 5 products / 14 entries; full diff suite 106/106.
Co-Authored-By: Claude Fable 5 <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, a net48 project: the single source of truth for the Console↔Launcher RPC contract (wire types, thePodManagerConnectionclient, and the framed-JSONPodRpcprotocol), shared with the Launcher Service. 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(net48), 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 System.Text.Json
frames over the existing OFB-encrypted stream — see Contract/PodRpcProtocol.cs,
shared verbatim by both ends. 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
Service/Agent target net48, same as the Console. Note the Console still uses
BinaryFormatter for local disk persistence (Site config, mission results) — that
is local file I/O on net48, 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 embedded resources + icon
TeslaConsole.csproj net48 project
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 net48 reference assemblies, so a standalone Framework
targeting pack is not required.
dotnet build TeslaConsole.csproj -c Release
Output: bin/Release/net48/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).