From 499f94d0074f25c36919b334e3537952281e4ead Mon Sep 17 00:00:00 2001 From: Cyd Date: Fri, 10 Jul 2026 11:37:09 -0500 Subject: [PATCH] Apply operator clarifications: BOOTP, attract mode, PQS scope - BOOTP was never actually implemented anywhere despite header mentions: removed it as a design consideration (pod addressing is static config); left a one-line "never implemented, don't design against it" note so it doesn't creep back in. - No cockpit title has an attract mode - the games were never deployed as walk-up public arcade machines (Firestorm had unfinished plans for one). Corrected the TeslaRel410 deployment-goal wording. - PQS reclassified from core bay component to support tooling: it is the operator's own event traffic-flow tool, not standard bay infrastructure. Kept as the natural seed for future cross-site queue/roster coordination (brainstorm shared-services table + open question reworded accordingly). Co-Authored-By: Claude Fable 5 --- README.md | 2 +- docs/BRAINSTORM.md | 7 +++---- docs/PODBAY-ECOSYSTEM.md | 45 ++++++++++++++++++++-------------------- 3 files changed, 27 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index 912be8c..009851d 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ live in the docs below. | `RP411` | Classic Red Planet — Tesla 4.10 reconstruction as a native Win32 port (MUNGA engine + L4 platform layer, DX9). Console-controlled via Munga protocol, TCP 1501. | | `BT411` | Classic BattleTech — Tesla 4.10 reconstruction on the shared RP411/MUNGA Windows engine. Console streams the mission egg over TCP; pods mesh with each other. | | `TeslaRel410` | The original 1994–96 Tesla 4.10 source/content archive **plus a custom DOSBox-X emulator** (HLE of the Division VPX render board) to run the *original unmodified DOS games* on today's Windows pod hardware — cockpit RIO and plasma passed through on COM1/COM2, pod networking via emulated NE2000. | -| (local `PQS/`) | Pod Queue System — PHP/MySQL front-of-house: registration, callsigns, queue, and the HTTP endpoints the game/console poll for the next mission + roster. | +| (local `PQS/`) | Pod Queue System — operator-built PHP/MySQL event tooling (traffic flow when bringing pods to events): registration, callsigns, queue, and the HTTP endpoints the game/console poll for the next mission + roster. Support tooling in SiteLink scope; possible future coordination layer. | ## Status diff --git a/docs/BRAINSTORM.md b/docs/BRAINSTORM.md index 550ae01..4285b9e 100644 --- a/docs/BRAINSTORM.md +++ b/docs/BRAINSTORM.md @@ -163,8 +163,6 @@ Fine between trusted operators, but do it deliberately: TCP/IP) via NetNub**, surfaced through NE2000-emulation bridged onto the bay LAN via pcap. Because it's plain IP with the emulated pod holding a real bay address, the routed-VPN model extends to them *in principle* unchanged. -- Site-local pieces: BOOTP (broadcast) needs an answerer or static config per site — - same "provision locally, play routably" pattern as everything else. - Unknowns to test (cheap — emulator instances run on any PC, no cockpit needed): NetNub discovery/mesh addressing across subnets, and the latency tolerance of a 30 Hz 1996 lockstep-era sim. Fold into the Phase 0 netem lab once the emulator @@ -181,7 +179,7 @@ Fine between trusted operators, but do it deliberately: |---------|-------| | WireGuard hub | The rendezvous point; a VPS (could sit near the existing mysticmachines.com infra) or a box at the best-connected site | | Mumble | Cross-site voice day one — the FS507D release already integrated Mumble on the bay side. Channel per team, cross-team lobby channel | -| Central PQS (event mode) | Cross-site events need one queue/roster. Options: (a) one central PQS all consoles poll — simplest, DB schema grows a `site` column; (b) per-site PQS + sync — only if WAN-down resilience of the local queue matters during events. Callsign uniqueness becomes fleet-wide (global registration table) | +| Queue/roster coordination (future) | Cross-site events will want one queue/roster. **PQS** — the operator-built event traffic-flow tool — is the natural seed, but for now it stays support tooling. If promoted: (a) one central instance all consoles poll — simplest, DB schema grows a `site` column; (b) per-site instances + sync — only if WAN-down resilience of the local queue matters during events. Callsign uniqueness would become fleet-wide | | Neutral game host | Firestorm dedicated server for site-vs-site matches | | NTP | One clock for scores, logs, and replay/debrief alignment | | Fleet monitoring | VncThumbnailViewer pointed across the VPN; later, master-console status board | @@ -220,7 +218,8 @@ worth a small design of its own later. degrade (rubber-banding, desync, disconnect)? 5. **Dedicated Firestorm host** — does `mw4dedicatedui` build & run in the modern tree, and can camera/MR spectators join it cleanly? -6. **PQS multi-site schema** — site column vs event database; global callsign policy. +6. **PQS promotion** — if/when the event queue tool becomes cross-site coordination: + site column vs event database; global callsign policy. 7. **Master-console arbitration** — what happens when site + master consoles command the same pod; do we need a soft lock ("bay is in fleet mode")? 8. **Who hosts shared infra** — VPS vs best-connected site; bandwidth math for a diff --git a/docs/PODBAY-ECOSYSTEM.md b/docs/PODBAY-ECOSYSTEM.md index 6d25314..c1908f8 100644 --- a/docs/PODBAY-ECOSYSTEM.md +++ b/docs/PODBAY-ECOSYSTEM.md @@ -9,7 +9,7 @@ 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 | +| 1 | Command console | Operator station: TeslaConsole (pod management) + the game's console/lobby (Firestorm "BattleTech Console" ConLobby, or the era console for BT/RP) | | 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`) | @@ -125,19 +125,21 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m 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). +- **Ultimate goal:** deploy to the current pods — power-on boots straight into the + game, playable in the cockpit (plan estimates ~3–5 months focused work; gauges + deferred). *Note: none of the cockpit software has an attract mode — these titles + were never deployed as walk-up public arcade machines. Firestorm had plans for + one, never finished.* - **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: + Ethernet using **WATTCP (DOS TCP/IP) via VWE's NetNub layer** + (`CODE\*\MUNGA_L4\NETNUB\`). Pod addressing is static configuration. (BOOTP + appears in a few WATTCP headers but was never actually implemented anywhere — + don't design against it.) The emulator exposes the stack 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, + 2. 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 @@ -145,16 +147,15 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m 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 +- **PQS — Pod Queue System** (`C:\VWE\PQS`): operator-built event tooling — developed + by the pod owner to manage traffic flow when bringing pods to events, not part of + the standard bay network. XAMPP (Apache/PHP/MySQL): registration, callsigns, + combined queue displays, history/search. The game/console side polls simple HTTP + endpoints (`getFSgame.php` = next mission's type/map/condition flags; + `getFSplayers.php` = roster; MySQL db `pqs`). **SiteLink scope: support tooling for + now** — but it's the natural seed if cross-site queue/roster coordination is wanted + later. - **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. @@ -174,7 +175,7 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m | 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) | +| 80 | TCP | console/game → PQS box | PQS HTTP endpoints (event tooling, when deployed) | +| 3306 | TCP | PQS internal | MySQL (localhost) | | 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention) | | 5900 | TCP | operator → pods | VNC monitoring (optional) |