CydandClaude Fable 5
d373e3c1d3
- Ecosystem doc: new section on the TeslaRel410 project — custom DOSBox-X fork HLE-emulating the Division VPX board to run the original, unmodified Tesla 4.10 BattleTech/Red Planet DOS binaries on current Windows 10 pod hardware (RIO COM1 / plasma COM2 passthrough). Networking facts for SiteLink: WATTCP (real TCP/IP) via NetNub over emulated NE2000 bridged by pcap -> routable in principle; BOOTP is broadcast -> site-local provisioning. - Clarified BT411 and RP411 as the two native Win32 Tesla 4.10 reconstructions (per operator), complementary to the emulation path. - Brainstorm: new game-linking subsection for the emulated originals + open question 11 (NetNub cross-subnet addressing, 30 Hz sim latency tolerance). - CTCL naming note: provenance question is out with VWE veterans. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
181 lines
12 KiB
Markdown
181 lines
12 KiB
Markdown
# The Pod Bay ecosystem — what SiteLink has to work with
|
||
|
||
Surveyed 2026-07-10 from the sibling repos under `C:\VWE`. Every claim below has a source
|
||
pointer so it can be re-verified as those repos evolve.
|
||
|
||
## 1. Physical bay composition
|
||
|
||
A Pod Bay is **an air-gapped network of ~20 computers**:
|
||
|
||
| Count | Machine | Software role |
|
||
|------:|---------|---------------|
|
||
| 1 | Command console | Operator station: TeslaConsole (pod management) + the game's console/lobby (Firestorm "BattleTech Console" ConLobby, or the era console for BT/RP) + PQS front-of-house |
|
||
| 16 | Cockpit computers | Run the game exe in pod mode (`-ctcltype 2` for Firestorm) with cockpit I/O (RIO boards → RioJoy/VRio joystick layer) |
|
||
| 1 | Live Cam station | Firestorm: game exe as camera ship (`-ctcltype 3`, `ctcl-camera.ini`) |
|
||
| 1 | Mission Review station | Firestorm: `ctcl-mr.ini`; engine has a dedicated `MSRSpectator` project (`firestorm\Gameleap\code\mw4\Code\MSRSpectator`) |
|
||
| 1 | Printer | Debriefing / scoresheet output (`printdebriefing` flag in PQS game config) |
|
||
|
||
Air-gapped is a *feature*: the cockpit boxes run era Windows images, deliberately hardened
|
||
and never internet-exposed (TeslaLauncher's `install.bat` hardens the box). SiteLink must
|
||
preserve that property — the linked fleet becomes one bigger air-gapped network, not 20×N
|
||
machines on the internet.
|
||
|
||
## 2. Addressing conventions found in the wild
|
||
|
||
- **Dev/legacy bays:** `200.0.0.x` — pods at `.1–.8` and `.11–.18`, camera ship at `.9`
|
||
(see `firestorm\MW4\ctcl-game.ini` `[teslas]`). Note `200.0.0.0/8` is *public* address
|
||
space — harmless while air-gapped, a real conflict once bays are routed together.
|
||
- **FS507D 2016 LAN-center release:** per-machine `10.0.0.x` (release `postinstall.bat`,
|
||
ctcl inis) — already in RFC1918 space, and the convention the SiteLink seed proposal
|
||
generalizes to `10.0.<site>.x`.
|
||
|
||
## 3. Components and their wire protocols
|
||
|
||
### TeslaConsole ↔ TeslaLauncher (pod management plane)
|
||
- **TCP 53290**, length-prefixed JSON frames over an OFB-encrypted stream; per-pod key
|
||
(`TeslaSuite\Contract\PodRpcProtocol.cs`). Console provisions, installs products on,
|
||
and launches games on pods.
|
||
- **First-boot provisioning:** UDP beacons + RSA key exchange (`TeslaSuite\SecureConfig\`)
|
||
— *broadcast-based, local-subnet only*. Provisioning is inherently an on-site act.
|
||
- **`local.siteconfig`** (`C:\VWE\local.siteconfig`): .NET BinaryFormatter graph of
|
||
`TeslaConsole.Squad` (mGuid, mName, mOnline) → `TeslaConsole.Pod` records:
|
||
`mId, mIPAddress, mGateway, mDns, mSubnet, mHostName, mKey, mMacAddress, mName,
|
||
mPodArtPath, mHostType, mOnline`. Two consequences for SiteLink:
|
||
1. "Concatenating" siteconfigs = a real deserialize/merge/reserialize tool (or native
|
||
multi-site support in TeslaConsole — buildable, since the console is now rebuilt
|
||
from source). The `Squad` concept maps naturally to "one squad per site".
|
||
2. `mKey` is the credential that lets a console command a pod. **Siteconfig files are
|
||
secrets.** Sharing one with a master console = handing over control of your bay.
|
||
- **vPOD** (`TeslaSuite\vPOD\`): impersonates both a pod's launcher (TCP 53290) and a
|
||
game client (Munga TCP 1501). **This is our test double for a whole remote bay** — we
|
||
can prototype every SiteLink flow without touching cockpit hardware.
|
||
|
||
### Firestorm (MW4/Gameleap engine) — the flagship game
|
||
- **Game transport: DirectPlay 4** (`IDirectPlay4A`, TCP/IP service provider, DirectPlay
|
||
reliable protocol enabled) — `firestorm\...\GameOS\Net_Main.cpp:387,2226`.
|
||
- Port: registry value `DirectPlayPort` (`Games_LAN.cpp:2307`); `0` = stock DirectPlay
|
||
ports (TCP/UDP 47624 enumeration + dynamic 2300–2400 range). Setting it fixed makes
|
||
firewalling exact.
|
||
- **Directed join works without broadcast:** `TryToJoinASpecificGame(szIPAddress, name)`
|
||
builds a compound address with `DPAID_INet = host IP` and unicasts the session
|
||
enumeration (`Net_Main.cpp:2887–2937`). Broadcast is only the "browse LAN games"
|
||
path. **This is what makes routed (L3) site-linking viable.**
|
||
- Player cap: compiled default **16** (`MW4Shell.cpp:13319`); engine arrays go to 255.
|
||
A drafted, phased **16→32 plan** exists in `firestorm\CLAUDE.md` (code defaults +
|
||
lobby UI + ≥32 drop zones per map). Two full bays in one match needs it; one bay's
|
||
16 split across two sites does not.
|
||
- Replication is ~O(n²) at the session host — host placement/upstream matters.
|
||
- **CTCL — the console↔Tesla control layer:** `ctcl.dll` (client, compiled into
|
||
game/launcher/editor from shared `ctcl.cpp`) + `ctcls.dll` (server side,
|
||
`code\ctcls\`) + per-role inis (`ctcl-game.ini`, `ctcl-camera.ini`, `ctcl-mr.ini`):
|
||
`[teslas]` maps pod IP → pilot seat; `[Games]` lines carry the exe + `-ctcltype`
|
||
role; aux-message and taunt tables. The bay roster is **static config**, which is
|
||
exactly what a site-ID-based addressing scheme can template.
|
||
- *Naming note:* the acronym is never expanded anywhere in source, comments, or
|
||
docs. What **is** attested (`ctcl.h`, `ctcl.cpp`, `ctcl_params.h`): message
|
||
directions are commented "Console 2 Launcher" / "Launcher 2 Console"; role
|
||
constants are `_ECTCL_Console` / `_ECTCL_Launcher`; the API is Tesla-centric
|
||
(`CTCL_GetTeslaCount`, `STeslaInfo`, `MAX_TESLAS 16`, `MAX_CAMERAS 4`) and
|
||
coin-op-aware (`CTCL_CoinDisplay`). So "Console↔Tesla Control Layer/Link" is our
|
||
best reading — treat it as inference, not fact. *(Provenance question is out
|
||
with VWE veterans — update here when word comes back.)*
|
||
- **Game-agnostic:** app-type constants `_EAT_MW4` and `_EAT_RP` (`ctcl_params.h`)
|
||
— the same control layer drives both Firestorm and Red Planet. One layer for
|
||
SiteLink to reason about, not two.
|
||
- **Own ports:** `PORT_Launcher 1000`, `PORT_Game 1001`, `PORT_CameraShip 1001`
|
||
(`Launcher\ctcl.cpp`) — distinct from Munga 1501 and DirectPlay (transport
|
||
details unverified; confirm in Phase 0).
|
||
- **Dedicated server exists:** `mw4dedicatedui` project (`...\mw4\Code\mw4dedicatedui`) —
|
||
option to host cross-site matches on a neutral box instead of one bay's console.
|
||
- **Dormant internet-era code:** MSN Zone "GUN" matchmaking (`Games_GUN.cpp`,
|
||
`GUNGameList.h`) and GameSpy advertisement (`Games_GSpy.cpp`) — dead services, live
|
||
code paths; a revival hook if SiteLink ever wants a fleet-wide game browser.
|
||
- **2016 release integrated Mumble** for voice (FS507D postinstall) — cross-site voice is
|
||
a solved problem: one Mumble server on the shared network.
|
||
|
||
### BT411 (classic BattleTech — Tesla 4.10 reconstruction, native Win32)
|
||
- **Console-push model over plain TCP:** the console connects to each pod's `-net <port>`
|
||
listener (convention 1501/1601), streams the mission egg in 1040-byte framed chunks,
|
||
then sends `RunMission` twice (`BT411\tools\btconsole.py` documents the full wire
|
||
format, verified against the engine).
|
||
- Pods form their mesh from the egg's `[pilots]` list; the console must stay connected
|
||
for the duration (engine quirk: console loss also closes the game listener).
|
||
- Cross-site implication: `btconsole.py MP.EGG 10.0.1.11:1501 10.0.2.11:1501` is *already*
|
||
a cross-site game launch, modulo whatever the pod↔pod mesh needs (open question: does
|
||
the `[pilots]` list carry literal IPs? → see BRAINSTORM open questions).
|
||
- Status: entity/movement replication works; cross-pod combat in progress.
|
||
|
||
### Red Planet (RP411 — classic Red Planet, Tesla 4.10 reconstruction, native Win32)
|
||
- Same lineage as BT411: the classic Tesla 4.10 title carried forward as a native
|
||
Win32 port (MUNGA engine + L4 platform layer, DX9). Console game-control via
|
||
**Munga protocol, TCP 1501** (vendored `Munga Net.dll` in TeslaConsole 4.11.4).
|
||
Same console-directed model as BT411 (shared `MUNGA_L4\L4NET.CPP`).
|
||
|
||
### TeslaRel410 — the *original* Tesla 4.10 games under emulation
|
||
The third route to the classic titles (`C:\VWE\TeslaRel410`): don't port the game —
|
||
**emulate the 1996 pod computer** and run the original, unmodified DOS executables on
|
||
the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.md`.
|
||
|
||
- **What it is:** archival snapshot of the 1994–96 Tesla:BattleTech and
|
||
Tesla:Red Planet source + content (Borland C++ 5.0 / TASM, MUNGA + MUNGA_L4), plus
|
||
complete runnable DOS installs (`sda4\BTLIVE`, `sda4\RPLIVE`).
|
||
- **The approach:** a custom **DOSBox-X fork** whose main addition is a
|
||
high-level-emulation device impersonating **Division Ltd.'s VPX render board** at
|
||
its host interface (INMOS C012 link adapter, polled I/O at port 0x150) and
|
||
rendering via OpenGL. The cockpit's real **RIO (COM1)** and **plasma display
|
||
(COM2)** are passed through to physical serial ports so the game's own 1996
|
||
drivers run the actual cockpit hardware; SB16 emulation feeds the speakers.
|
||
- **Ultimate goal:** deploy to the current pods — power-on → attract mode, playable
|
||
in the cockpit (plan estimates ~3–5 months focused work; gauges deferred).
|
||
- **Networking — the SiteLink-relevant part:** the original pods networked over
|
||
Ethernet using **WATTCP (DOS TCP/IP, with BOOTP) via VWE's NetNub layer**
|
||
(`CODE\*\MUNGA_L4\NETNUB\`). The emulator exposes this through **NE2000 emulation
|
||
bridged via pcap** — i.e. the emulated game gets a real presence on the bay LAN
|
||
with its own MAC/IP. Consequences:
|
||
1. It's plain IP — in principle it routes across a SiteLink VPN like any other
|
||
bay host (an emulated pod could be a `10.0.y.x` address).
|
||
2. **BOOTP is broadcast** — the boot-time address assignment is site-local; each
|
||
site needs its own BOOTP answerer (or static WATTCP config). Same pattern as
|
||
SecureConfig beacons: provisioning local, play routable.
|
||
3. Pod-to-pod/console addressing inside NetNub (discovery, mesh formation,
|
||
latency assumptions of a 30 Hz 1996 sim) is unverified for cross-subnet play —
|
||
open question, testable cheaply since emulator instances run on any PC.
|
||
- **Relationship to BT411/RP411:** two complementary strategies for the same
|
||
titles — native reconstruction (BT411/RP411, modern netcode we control) vs
|
||
faithful emulation (TeslaRel410, original binaries, original protocols). SiteLink
|
||
should assume *both* may want cross-site play eventually.
|
||
|
||
### PQS — Pod Queue System (front of house)
|
||
- XAMPP (Apache/PHP/MySQL) app: registration, callsigns, combined queue displays,
|
||
history/search (`PQS\*.php`).
|
||
- The game/console side **polls simple HTTP endpoints**: `getFSgame.php` prints the next
|
||
mission's game type/map/16 condition flags; `getFSplayers.php` the roster. MySQL db
|
||
`pqs`, tables `pqs_gameconfig`, `pqs_queue`, `pqs_mission`.
|
||
- Single-site by construction today (localhost MySQL, one queue). Multi-site play needs
|
||
either a shared central PQS or per-site PQS with an event/sync mode.
|
||
|
||
### Support tooling
|
||
- **VncThumbnailViewer** (`C:\VWE\VncThumbnailViewer`): operator monitoring of pod
|
||
screens — works fine across a VPN, and a master console could reuse it for fleet-wide
|
||
eyes-on.
|
||
- **RioJoy / VRio**: cockpit hardware I/O → joystick. Purely local to each cockpit;
|
||
SiteLink never touches it.
|
||
- **SheepShaver**: classic-Mac emulation (the original 1990s VGL-era console stack) —
|
||
heritage/reference only.
|
||
- **blackthorn**: archived site builds (Airlock standard install 2018, Firestorm SMT
|
||
builds) — useful as references for how deployed sites were actually configured.
|
||
|
||
## 4. Port map (current, single bay)
|
||
|
||
| Port | Proto | Flow | Purpose |
|
||
|------|-------|------|---------|
|
||
| 53290 | TCP | console → pod | TeslaLauncher RPC (provision/install/launch), OFB-encrypted framed JSON |
|
||
| (local bcast) | UDP | pod ↔ console | SecureConfig first-boot beacons (on-site only) |
|
||
| 1501 | TCP | console → pod | Munga game control (RP; BT411 uses same convention, port per `-net`) |
|
||
| 1000 / 1001 | TCP/UDP (unverified) | console ↔ launcher/game/camera | CTCL control channel (`PORT_Launcher`/`PORT_Game`/`PORT_CameraShip` in `firestorm\...\Launcher\ctcl.cpp`) |
|
||
| 47624 + 2300–2400, or fixed `DirectPlayPort` | TCP/UDP | pod ↔ session host | Firestorm DirectPlay 4 session + game traffic |
|
||
| 80 | TCP | console/game → PQS box | PQS HTTP endpoints |
|
||
| 3306 | TCP | PQS internal | MySQL (localhost today) |
|
||
| 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention) |
|
||
| 5900 | TCP | operator → pods | VNC monitoring (optional) |
|