CydandClaude Fable 5
3fd637c58a
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>
36 lines
764 B
Plaintext
36 lines
764 B
Plaintext
# Build output
|
|
[Bb]in/
|
|
[Oo]bj/
|
|
|
|
# Launcher build.bat staging + final output
|
|
/Launcher/_stage_svc/
|
|
/Launcher/_stage_agt/
|
|
/Launcher/TeslaLauncher/
|
|
|
|
# Runtime / installer state (generated, not source)
|
|
*.InstallState
|
|
*.log
|
|
|
|
# IDE / OS
|
|
.vs/
|
|
.vscode/
|
|
.idea/
|
|
*.user
|
|
*.suo
|
|
*.userosscache
|
|
*.sln.docstates
|
|
Thumbs.db
|
|
desktop.ini
|
|
.DS_Store
|
|
__pycache__/
|
|
|
|
# 410console hand-off: the docs/spec/reference/tools are tracked; the raw Mac
|
|
# archive and its extraction are not (may be committed later for completeness)
|
|
/410console/410consoleArchive.sit
|
|
/410console/4_10-console-extracted/
|
|
/410console/.finf/
|
|
|
|
# vPOD: the packed dist zip is tracked (deployable via Install Product), but the
|
|
# intermediate stage folder pack.ps1 lays out before zipping is not.
|
|
/Console/vPOD/dist/vPOD/
|