Files
CydandClaude Fable 5 71292db455 Phase 0 lab plan: topology, VM management, experiments E1-E9
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>
2026-07-10 13:44:30 -05:00

3.5 KiB
Raw Permalink Blame History

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.x subnet (site 1 = 10.0.1.x, site 2 = 10.0.2.x, …), VPN them all together into a single 10.0.0.0/16, then collect every site's .siteconfig and 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 E1E9 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.
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 199496 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.