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>
- 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>
- Ecosystem doc: new section on the TeslaRel410 project — custom
DOSBox-X fork HLE-emulating the Division VPX board to run the
original, unmodified Tesla 4.10 BattleTech/Red Planet DOS binaries
on current Windows 10 pod hardware (RIO COM1 / plasma COM2
passthrough). Networking facts for SiteLink: WATTCP (real TCP/IP)
via NetNub over emulated NE2000 bridged by pcap -> routable in
principle; BOOTP is broadcast -> site-local provisioning.
- Clarified BT411 and RP411 as the two native Win32 Tesla 4.10
reconstructions (per operator), complementary to the emulation path.
- Brainstorm: new game-linking subsection for the emulated originals +
open question 11 (NetNub cross-subnet addressing, 30 Hz sim latency
tolerance).
- CTCL naming note: provenance question is out with VWE veterans.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Searched the firestorm tree for an authoritative expansion of "CTCL" and
found none. Replaced the guessed "cafe/Tesla control layer" wording with
the attested facts (Console 2 Launcher message comments, _ECTCL_Console/
_ECTCL_Launcher roles, Tesla-centric coin-op API) and flagged the reading
"Console-Tesla Control Layer" as inference. New facts from the dig: CTCL
is game-agnostic (_EAT_MW4/_EAT_RP) and has its own ports 1000/1001,
added to the port map.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5