docs/PHASE0-PLAN.md: - Lab topology mirroring production 1:1 - two minimum-shape sites (console + 2 cockpits) + hub, hub-and-spoke WireGuard over a host-only "WAN" net with netem as the simulated internet. - Lab IP conventions (strawman seat map; flagged for alignment with real bay numbering before Phase 1). - VM inventory: full 9-VM set and a 5-VM minimum-viable start. - VM management recommendations: VMware Workstation Pro 17 (free personal; host is Win11 Home so no Hyper-V) for the first pass, Proxmox VE on a spare box as the persistent lab / future hub staging; gold images + linked clones, snapshot-per-experiment discipline, config-as-code under lab/, one-knob netem sweep script. - Experiments E1-E9 with pass criteria mapped to the brainstorm's open questions: routed fabric + console RPC over WAN, broadcast locality, FS directed join + port matrix, latency cliff table, WAN-drop behavior, MTU, BT411 cross-subnet egg push, hub host + stream rehearsal, event-day dry run (SiteConfigMerge gate). - Risks: MW4-in-VM rendering (physical-host fallback), vPOD fidelity limits, firewall discipline. Linked from BRAINSTORM Phase 0 and the README contents table. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.5 KiB
SiteLink
Linking multiple VWE Pod Bays together to play games across the internet.
A Pod Bay today is an air-gapped network of ~20 computers: 1 command console, 1 printer, 2 review stations (Live Cam & Mission Review), and 16 cockpit computers. SiteLink is the project to connect those islands — so a bay in one city can field a lance against a bay in another, share a queue, share voice, and (eventually) be commanded as one fleet.
Seed concept (2026-07-10)
Organize each site into its own
10.0.y.xsubnet (site 1 =10.0.1.x, site 2 =10.0.2.x, …), VPN them all together into a single10.0.0.0/16, then collect every site's.siteconfigand merge them for a master console that can command the entire fleet.
That concept is the anchor of this repo. The analysis, alternatives, and open questions live in the docs below.
Contents
| File | What it is |
|---|---|
| docs/PODBAY-ECOSYSTEM.md | Survey of the existing bay software stack — every component, every protocol/port, with source pointers into the sibling repos. The ground truth SiteLink has to work with. |
| docs/BRAINSTORM.md | The design record: goals, the seed proposal analyzed, addressing plan, VPN topology options (routed vs bridged), the event authority-handover model, per-game linking analysis, shared services, security, open questions, and a phased roadmap. |
| docs/PHASE0-PLAN.md | The lab-proof plan: VM topology simulating two sites + the hub, hypervisor/VM-management recommendations, and experiments E1–E9 with pass criteria that close the brainstorm's open questions — no cockpit hardware, no travel. |
| tools/SiteConfigMerge | Working tool: decodes TeslaConsole .siteconfig files and merges <siteName>.siteconfig inputs into one master.siteconfig for the central event console, renaming squads <siteName>-<squad>. Verified against the real TeslaConsole 4.11.4.1 loader. |
Related repositories (gitea.mysticmachines.com/VWE)
| Repo | Role |
|---|---|
TeslaSuite |
TeslaConsole (operator console), TeslaLauncher (pod service), the Console↔Pod RPC contract, SecureConfig provisioning, and vPOD (virtual pod — our cross-site test double). |
firestorm |
BattleTech: Firestorm — the MW4/Gameleap-engine game the 16 cockpits run. DirectPlay 4 multiplayer. Contains the drafted 16→32 player-cap plan that a two-bay link needs. |
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 — 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
Brainstorm / design phase. Nothing here touches a live bay yet.