CydandClaude Fable 5
e0d30120e0
New: tools/SiteConfigMerge (net48 console app) - dump: decode any .siteconfig (squads, pods, IPs, MACs, host types) - merge: combine <siteName>.siteconfig inputs into master.siteconfig, renaming squads "<siteName>-<original squad name>" - Pod records pass through byte-for-byte; only squad records (the rename) are re-serialized, under the TeslaConsole assembly identity captured from the input. Stand-in types + SerializationBinder, so no build dependency on TeslaSuite. - Warns on duplicate pod GUID/MAC and cross-site IP overlap. - Verified end-to-end: the real TeslaConsole.exe 4.11.4.1 loaded the merged master via its own Site.LoadFromFile (reflection harness). Doc updates from operator decisions: - Operating model settled: sites voluntarily hand console authority to the central console for the duration of a SiteLink event, by contributing their siteconfig. Federation ruled out at current scale. - Siteconfig "secrets" framing corrected: pod keys have no practical value outside the air-gapped bay; files are exchanged per event and never stored in this repo (tools only). - Fleet scale recorded: 6 active pod bays, <120 cockpits in existence; bay sizes range console+2 cockpits up to the full 20-node complement. Open question 9 answered. - Hub hosting direction: neutral Firestorm host at the WireGuard hub; the FS server usually IS the Live Cam, so stream its output to all sites and optionally to the public internet. Mission Review instance runs at the hub too - one authoritative debrief streamed everywhere. - Virtual PDF scoresheet printer at the hub: event debriefings print centrally, retrievable from any site on the link. - Voice (Mumble) backburnered - revisit only on event interest. - .gitignore: build outputs; siteconfig exclusion rationale reworded. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
42 lines
3.2 KiB
Markdown
42 lines
3.2 KiB
Markdown
# 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](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](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. |
|
||
| [tools/SiteConfigMerge](tools/SiteConfigMerge/README.md) | **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.
|