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 <noreply@anthropic.com>
This commit is contained in:
Claude Fable 5
@@ -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
|
||||
|
||||
|
||||
+3
-4
@@ -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
|
||||
|
||||
+23
-22
@@ -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) |
|
||||
|
||||
Reference in New Issue
Block a user