SiteConfigMerge tool + operating-model updates from operator input
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>
This commit is contained in:
Claude Fable 5
+77
-50
@@ -12,7 +12,8 @@ brainstorm builds on.
|
||||
gets a route to the general internet.
|
||||
3. **Fleet visibility/command**: an operator (eventually a master console) can see — and
|
||||
where appropriate command — pods at every site.
|
||||
4. **Shared front-of-house**: cross-site events share a queue, callsigns, scores, voice.
|
||||
4. **Shared front-of-house**: cross-site events share a queue, callsigns, scores.
|
||||
(Voice: backburnered — see §6.)
|
||||
5. **Zero changes to cockpit hardware**, minimal changes to bay-local operation: a bay
|
||||
must keep working stand-alone when the link is down.
|
||||
|
||||
@@ -38,7 +39,9 @@ are about *how*, not *whether*.
|
||||
PQS, Mumble, NTP, a neutral dedicated game host. Nothing site-specific lives there.
|
||||
- **Site ID registry lives in this repo** (`sites/` — one small file per site: ID, name,
|
||||
operator, subnet, contact). First allocation: `10.0.1.0/24` = Fallout Shelter Arcade;
|
||||
`10.0.2.0/24` = next site. 254 sites max — plenty.
|
||||
`10.0.2.0/24` = next site. **Scale reality (2026): 6 active pod bays, fewer than 120
|
||||
cockpits in existence** — 254 site IDs is beyond generous, and every topology choice
|
||||
below can assume single-digit sites.
|
||||
- **Netmask choice is the real design fork** (see §3): hosts configured `/24` + gateway
|
||||
= routed model; hosts configured `/16` = requires a bridged L2 overlay.
|
||||
- Renumbering mechanics: TeslaConsole already owns pod IP config (provisioning writes
|
||||
@@ -88,36 +91,33 @@ L3. The bay machines themselves never run VPN software; only the per-site gatewa
|
||||
|
||||
The seed proposal: merge all `.siteconfig` files → one master console commands the fleet.
|
||||
|
||||
**Reality check on "concatenate":** `local.siteconfig` is a BinaryFormatter object graph
|
||||
(Squad → Pods), not a text file — merging means a small tool that deserializes N
|
||||
siteconfigs and emits one multi-squad config. Straightforward since TeslaConsole is
|
||||
rebuilt from source; the natural mapping is **one Squad per site** ("FSA-bay1",
|
||||
"Pharaoh-bay1", …). TeslaConsole's UI already organizes pods by squad.
|
||||
**The merge tool exists:** [`tools/SiteConfigMerge`](../tools/SiteConfigMerge/README.md)
|
||||
decodes `<siteName>.siteconfig` files and emits one `master.siteconfig`, renaming every
|
||||
squad **`<siteName>-<original squad name>`** ("FSA-bay1", "Pharaoh-bay1", …) — one
|
||||
squad group per site, which TeslaConsole's UI already organizes naturally. Pod records
|
||||
pass through byte-for-byte; verified against the real TeslaConsole 4.11.4.1 loader.
|
||||
|
||||
**Security consequence:** a pod's `mKey` in the siteconfig *is* command authority over
|
||||
that pod. Shipping your siteconfig to a master console = granting fleet-wide control.
|
||||
Fine between trusted operators, but do it deliberately:
|
||||
**The operating model (settled 2026-07-10): event-scoped authority handover.** When a
|
||||
SiteLink event runs, **every participating site willingly hands console authority to
|
||||
the central console for the duration of the event** — concretely, by contributing its
|
||||
`<siteName>.siteconfig` to the merged master. Outside events, each site console is
|
||||
authoritative over its own bay. Notes that keep this clean:
|
||||
|
||||
- Siteconfigs travel operator-to-operator over a secure channel; **never through this
|
||||
repo** (repo carries the merge tool + templates only).
|
||||
- A master console with all keys is a single high-value target — it lives on shared
|
||||
infra (`10.0.0.0/24`), not on someone's laptop.
|
||||
- The pod keys inside a siteconfig have no practical value outside the bay's
|
||||
air-gapped network (anyone with bay access has the file anyway) — handing the file
|
||||
over *is* the handover ceremony, not a security event.
|
||||
- Siteconfigs change over time, so they are exchanged fresh per event and are not
|
||||
stored in this repo (tools only).
|
||||
- Nothing *enforces* the handover — TeslaLauncher has no arbitration if a site console
|
||||
and the central console command the same pod concurrently. Convention: site consoles
|
||||
stand down for the event window. A soft "event mode" lock in TeslaConsole is a
|
||||
nice-to-have if the convention ever gets violated in practice.
|
||||
- Remaining technical to-do for the central console: WAN-tolerant RPC timeouts, and
|
||||
it should live on shared infra (`10.0.0.0/24`) with a decent uplink.
|
||||
|
||||
**Three architectures, in order of effort:**
|
||||
|
||||
1. **Merged-config master console (the seed).** One TeslaConsole instance with all
|
||||
squads/keys. Cheapest to reach; needs the merge tool + WAN-tolerant RPC timeouts.
|
||||
Risks: WAN blip mid-install, and two consoles (site + master) commanding the same pod
|
||||
concurrently — the launcher has no arbitration. Convention needed: master commands
|
||||
only during cross-site events, site console otherwise.
|
||||
2. **Hybrid (probably the sweet spot).** Site consoles stay authoritative for
|
||||
provisioning/installs; the master console gets *visibility everywhere* +
|
||||
*game-orchestration rights* during events. Could be as simple as (1) plus agreed
|
||||
scope, or a read-only fleet mode in TeslaConsole.
|
||||
3. **Federation service.** A SiteLink coordinator each site console registers with; the
|
||||
coordinator brokers cross-site game setup, no raw pod keys leave a site. Cleanest
|
||||
trust story, most new code. Later phase, if the fleet grows past a handful of
|
||||
trusted operators.
|
||||
**Federation (a coordinator service so raw keys never leave a site) is off the table**
|
||||
at current scale — 6 bays run by trusted operators doesn't need it. Recorded here only
|
||||
in case the fleet's trust model ever changes.
|
||||
|
||||
## 5. Linking the games themselves
|
||||
|
||||
@@ -126,10 +126,26 @@ Fine between trusted operators, but do it deliberately:
|
||||
host placement:
|
||||
- a) Host at one site's console (simplest; other site eats the WAN RTT; O(n²) load on
|
||||
that console's uplink);
|
||||
- b) **Neutral dedicated host** on shared infra (`mw4dedicatedui` exists!) —
|
||||
symmetric latency for both sites, best uplink, and the camera/review stations at
|
||||
*each* site can join as local spectators. Needs validation that the dedicated
|
||||
server builds/runs (it's in the solution but unexercised in the modern work).
|
||||
- b) **Neutral host at the WireGuard hub (preferred direction, 2026-07-10).**
|
||||
Symmetric latency for every site, best uplink — and it exploits an operational
|
||||
fact: **the Firestorm server is almost always the Live Cam for that game.** A
|
||||
hub-hosted host running the camera-ship role turns the neutral server into the
|
||||
event's broadcast point: capture its output and **stream the show to every
|
||||
participating site** (Live Cam screens everywhere show the same feed), and
|
||||
optionally **stream it publicly to the internet** as the fleet's shop window.
|
||||
Considerations: the camera ship *renders*, so the hub box needs a real GPU
|
||||
(physical box at the hub location or a GPU cloud instance — not a bare VPS);
|
||||
`mw4dedicatedui` (headless) remains the fallback if hub rendering is impractical,
|
||||
with a camera-ship client joining from a site instead. Streaming transport is
|
||||
one-way and latency-tolerant: OBS capture → SRT/RTMP internally, Twitch/YouTube
|
||||
for the public leg. Needs validation either way (dedicated UI is unexercised in
|
||||
the modern tree; camera-ship-as-DirectPlay-host in the CTCL flow should be
|
||||
confirmed against `ctcl-game.ini`'s `*1`/cameraship entry and the PQS
|
||||
`cameraship` flag).
|
||||
- **The Mission Review instance lives at the hub too, for the same reasons:** one
|
||||
authoritative post-match review (`ctcl-mr` role / MSRSpectator) running next to
|
||||
the host that recorded the match, its output streamed to every site's Mission
|
||||
Review screen — every bay debriefs from the same show.
|
||||
- **Player counts:** the golden first milestone is **8v8 across two sites (8 cockpits
|
||||
each) — inside the stock 16-player cap, zero engine changes.** Full 16v16 site-vs-site
|
||||
needs the already-drafted 16→32 plan in `firestorm\CLAUDE.md` (compiled defaults +
|
||||
@@ -178,16 +194,19 @@ Fine between trusted operators, but do it deliberately:
|
||||
| Service | Notes |
|
||||
|---------|-------|
|
||||
| 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 |
|
||||
| Virtual scoresheet printer | A virtual printer at the hub that "prints" event debriefings/scoresheets to **PDF** (Firestorm's print path: `printdebriefing` / `mw4print`). PDFs land in one place and are retrievable from any site on the link — a simple web share on the hub over the VPN. Sites can still print paper locally from the PDFs |
|
||||
| Voice (backburnered) | The FS507D release integrated Mumble, but only one operator ever ran it. Technically easy to stand up on the shared network — revisit only if event interest warrants |
|
||||
| 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 |
|
||||
| Neutral game host + event broadcast | Firestorm host for site-vs-site matches, co-located with the WireGuard hub. Doubles as the Live Cam (the FS server usually *is* the Live Cam): stream its output to all sites' Live Cam screens, optionally to the public internet. The **Mission Review instance runs at the hub too** — one authoritative debrief streamed to every site's MR screen. Needs GPU at the hub |
|
||||
| NTP | One clock for scores, logs, and replay/debrief alignment |
|
||||
| Fleet monitoring | VncThumbnailViewer pointed across the VPN; later, master-console status board |
|
||||
|
||||
Local-only forever: printer, RIO/cockpit I/O, Mission Review & Live Cam *stations*
|
||||
(they join the match as spectators over the VPN, but the screens/printer serve the local
|
||||
audience). Cross-site match results reach both printers via PQS/debrief distribution —
|
||||
worth a small design of its own later.
|
||||
Local-only forever: printer and RIO/cockpit I/O. For cross-site events the Live Cam
|
||||
and Mission Review *instances* run at the hub (above); each site's LC/MR *screens*
|
||||
become display endpoints for the hub streams, serving the local audience. Bay-local
|
||||
games keep running their own LC/MR stations exactly as today. Cross-site scoresheets
|
||||
go to the hub's virtual PDF printer (table above) — retrievable from any site, with
|
||||
local paper printing off the PDFs where wanted.
|
||||
|
||||
## 7. Security posture
|
||||
|
||||
@@ -199,9 +218,11 @@ worth a small design of its own later.
|
||||
- *Game plane* (DirectPlay fixed port, Munga 1501, Mumble): site↔site and site↔shared.
|
||||
- *Management plane* (TCP 53290 launcher RPC, VNC 5900): only site-console↔own-pods
|
||||
and master-console↔pods — other sites' consoles have no business on your 53290.
|
||||
- **Secrets:** siteconfigs (pod keys) and WireGuard private keys never enter this repo.
|
||||
Repo holds templates, tools, and *public* site registry data (subnets, endpoints'
|
||||
hostnames, WireGuard public keys).
|
||||
- **Repo hygiene:** WireGuard private keys never enter this repo. Siteconfigs aren't
|
||||
stored here either — not because the pod keys matter off-site (they don't; the bays
|
||||
are air-gapped and anyone with bay access has the file), but because they're living
|
||||
operational data exchanged fresh per event. Repo holds tools, templates, and
|
||||
*public* site registry data (subnets, endpoint hostnames, WireGuard public keys).
|
||||
- Era-Windows reality: assume every bay box is compromised-if-reachable. The allowlist
|
||||
above is the actual security boundary; the VPN is transport, not trust.
|
||||
|
||||
@@ -220,12 +241,15 @@ worth a small design of its own later.
|
||||
and can camera/MR spectators join it cleanly?
|
||||
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")?
|
||||
7. **Console arbitration** — *policy settled 2026-07-10: sites voluntarily hand
|
||||
authority to the central console for the event window.* Residual: nothing enforces
|
||||
it (TeslaLauncher has no arbitration); an optional soft "event mode" lock in
|
||||
TeslaConsole only if the convention ever fails in practice.
|
||||
8. **Who hosts shared infra** — VPS vs best-connected site; bandwidth math for a
|
||||
32-player O(n²) host (~upstream estimate needed from real packet captures).
|
||||
9. **Site count ambitions** — 2 sites soon, how many eventually? Affects hub sizing and
|
||||
whether federation (§4.3) is ever needed.
|
||||
9. ~~Site count ambitions~~ — **answered 2026-07-10: 6 active bays, fewer than 120
|
||||
cockpits in existence.** Hub-and-spoke is trivially sufficient; federation is
|
||||
permanently unnecessary barring a trust-model change.
|
||||
10. **WAN-drop behavior** — for each linked flow, what breaks when the tunnel drops
|
||||
mid-match, and does the bay cleanly fall back to stand-alone?
|
||||
11. **NetNub over routed subnets (TeslaRel410)** — how do the original 4.10 games
|
||||
@@ -240,11 +264,14 @@ worth a small design of its own later.
|
||||
RPC (53290), a 2-client Firestorm match across subnets, latency sweep, BT411
|
||||
cross-subnet egg push. *Everything above that's marked "verify" gets verified here.*
|
||||
- **Phase 1 — First real link.** Two sites, gateways, tunnel, renumber to
|
||||
`10.0.1.x`/`10.0.2.x`. Mumble + fleet VNC + remote Mission-Review spectating. First
|
||||
`10.0.1.x`/`10.0.2.x`. Fleet VNC + remote Mission-Review spectating. First
|
||||
cross-site Firestorm match at ≤16 total players (8v8) on the stock exe.
|
||||
- **Phase 2 — Fleet operations.** siteconfig merge tool → master console visibility
|
||||
(hybrid model, §4.2). PQS event mode with shared queue/callsigns. Debrief/scoresheet
|
||||
distribution to both printers.
|
||||
- **Phase 2 — Fleet operations.** ~~siteconfig merge tool~~ ✅ built
|
||||
([`tools/SiteConfigMerge`](../tools/SiteConfigMerge/README.md), verified against the
|
||||
real console loader) → run an event under the authority-handover model (§4): collect
|
||||
`<siteName>.siteconfig`s, merge, central console commands the fleet. Optional PQS
|
||||
event mode with shared queue/callsigns; debrief/scoresheet distribution to both
|
||||
printers.
|
||||
- **Phase 3 — Full site-vs-site.** Execute the firestorm 16→32 plan (code defaults +
|
||||
drop zones), neutral dedicated host, 16v16 events.
|
||||
- **Phase 4 — More titles, more sites.** BT411/RP cross-site as those engines mature;
|
||||
|
||||
Reference in New Issue
Block a user