- 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>
vPOD has outgrown its home inside the console's folder: it now emulates both
halves of a pod (Munga game client + TeslaLauncher service / provisioning),
so it lives at the repo root beside Console/, Launcher/, Contract/ and
SecureConfig/, like the peer it has become.
Accompanying changes: project references rebased (Contract, SecureConfig,
the console's vendored Munga Net.dll), solution + DiffTests reference paths,
the console csproj's now-obsolete vPOD source exclusion removed, and the
root README / Apps.xml / vPOD README path mentions updated. pack.ps1 is
self-relative and now emits vPOD/dist/vPOD.zip.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vPOD impersonates a Tesla game client (rpl4opt.exe / btl4.exe) so the Red
Planet and BattleTech operator consoles can be exercised without real cockpit
hardware. New net48 WinForms project under Console\vPOD:
- MungaPodServer: the server half of the Munga control protocol (TCP 1501).
The vendored MungaSocket is client-only, so this reimplements the identical
framing ([16-byte header][12-byte base + body], dispatched by
ClientID+MessageID) for the listening side, reusing the vendored message
classes' WriteTo/BinaryReader serialization.
- PodSimulator: the ApplicationState machine driven by the console's messages -
answers StateQuery, reassembles the streamed egg and acknowledges it, and
walks WaitingForEgg -> LoadingMission -> WaitingForLaunch -> RunningMission
and back on Run/Stop/Abort/Suspend/Resume.
- VPodForm: live display of listening/connection status, the colour-coded
ApplicationState, an egg viewer (fields + summary), and a newest-first
protocol log. A Red Planet / BattleTech toggle changes which ApplicationID
the pod reports, live, so one vPOD stands in for either game.
- PodArguments: parses the real client's launch flags (-net/-app/-lc/-mr/
-host/-res).
Deployable from Manage Site -> Install Product: a catalog product in
RedPlanet\Apps.xml (Game Client / Live Camera / Mission Review entries) plus
pack.ps1, which builds dist\vPOD.zip laying out vPOD\vPOD.exe for the launcher
to extract to C:\Games\vPOD. CatalogTests updated to 5 products / 11 entries
with the four vPOD entry assertions (88/88 pass). TeslaConsole.csproj excludes
vPOD\** from its **/*.cs glob; the project is added to the solution.
Verified end-to-end over real TCP: a console-role client using the vendored
MungaSocket drives connect -> WaitingForEgg -> stream egg -> (ack) ->
WaitingForLaunch -> Run -> RunningMission -> Stop -> WaitingForEgg, with vPOD
reporting the correct state at each step. MungaGame (what the console's game
windows use) is a thin wrapper over MungaSocket, so this exercises the exact
wire behaviour.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Completes the BattleTech console feature to parity with Red Planet:
- BTPrintDocument: the per-pilot landscape score sheet (mech portrait,
placing, kill/death/damage stats, randomized mission-highlights narrative,
pilot-vs-pilot damage matrix, place-over-time chart), mirroring
RPPrintDocument minus the football/lap/boost/score-zone concepts. Wired into
BTGame (Auto Print checkbox + Print Last Mission button) and the shell's File
menu (BT Mission Print Preview / Print BT Mission, loading .btm files).
- BTStrings(.xml): the BT mission-highlight narrative pools (damage tiers,
kill, death-without-honor, recap), loaded from BattleTech\BTStrings.xml like
RPStrings.
- BTDefaultsDialog: two-column (Free For All / No Return) editor for the BT
operator defaults, reachable from Settings (Change/Import/Export BattleTech
Defaults). Verified via UI Automation: opens with all 18 option combos
populated.
- Apps.xml: the BattleTech 4.11 product (btl4.exe on the shared RP411 engine,
same -net/-res/-lc/-mr command line; deploys to C:\Games\BT411) with Game
Client / Live Camera / Mission Review launch entries. CatalogTests updated to
4 products / 8 entries plus the three new BT entry assertions.
Role model spelling corrected to "noreturn": the Mac Console.ini tag and the
game's BTL4.RES role resource are dfltrole/NoReturn; the 4.10 console's eggs
emitted a broken "noretun" that cannot resolve against the RES. BTGoldenEggTests
and BTConfig.xml updated accordingly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Firestorm selects game vs. Live Cam behavior from its assigned IP address, so a
separate LC product entry is unnecessary. Drop it from Apps.xml and update the
catalog tests (now 3 products / 5 entries; removed FirestormLC_Matches_Original).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
RIOJoy lifecycle is now owned by the console + launcher (the auto-start Run entry
was removed on the RioJoy side): Apps.xml autoRestart false -> true, so the
launcher starts RIOJoy and keeps it alive. Safe with uninstall — the watcher only
relaunches a still-tracked process, and uninstall's kill untracks it first.
Uninstall now physically removes the product (was unregister-only):
- Agent CmdUninstallApp: after kill + unregister, reports the product's
C:\Games\<dir> to clean up — but only if no remaining registered launch entry
still uses that folder (orphan check keeps multi-entry products like Red Planet's
GameClient/LC/MR intact until the last entry is removed).
- Service (SYSTEM): on UninstallApp, runs <dir>\pre-uninstall.bat if present
(RIOJoy's removes ViGEmBus + config) then deletes the directory, on a background
thread so it can't trip the Console's RPC timeout. Path-guarded to only ever
delete a proper subdirectory of C:\Games. Logged to podconf.log.
74 tests green; the cleanup path is pod-behavior, not unit-tested here.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
RIOJoy (the cockpit RIO → virtual-gamepad feeder; separate net48 repo) is now an
installable/launchable product in Console/RedPlanet/Apps.xml. Its dist zip is
already TeslaConsole-shaped (postinstall.bat + RIOJoy\ → extracts to C:\Games, the
launcher runs postinstall.bat as SYSTEM to install ViGEmBus + register auto-start),
so this is the only change needed on the TeslaSuite side.
- Launch entry exe C:\Games\RIOJoy\app\RioJoy.Tray.exe, autoRestart=false (the
postinstall HKLM Run entry owns startup; the catalog entry is for registration +
manual restart from the console).
- CatalogTests: bumped the count guard to 4 products / 6 entries and added a
byte-exact LaunchData check for the RIOJoy entry. 74 tests green.
Co-Authored-By: Claude Opus 4.8 <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 Fable 5