Files

T

CydandClaude Fable 5 499f94d007 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>

2026-07-10 11:37:09 -05:00

2.9 KiB

Raw 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.

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), master-console vs federation, per-game linking analysis, shared services, security, open questions, and a phased roadmap.

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.

2.9 KiB Raw Blame History Unescape Escape

SiteLink

Seed concept (2026-07-10)

Contents

Related repositories (gitea.mysticmachines.com/VWE)

Status

2.9 KiB

Raw Blame History