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>
2.9 KiB
SiteConfigMerge
Decodes TeslaConsole .siteconfig files and merges multiple sites' configs into a
single master.siteconfig for the central console that commands the fleet during a
SiteLink event.
The .siteconfig files themselves are not stored in this repo — they change over
time; sites hand them over as <siteName>.siteconfig when an event is being set up.
Usage
SiteConfigMerge dump <file.siteconfig> [...]
Decode and print each file: squads, pods, IPs, MACs, host types, key presence, and the TeslaConsole assembly identity that serialized it.
SiteConfigMerge merge -o master.siteconfig FSA.siteconfig Pharaoh.siteconfig [...]
Merge sites into one config:
- The site name is taken from each input's file name (
FSA.siteconfig→FSA). - Every squad is renamed
<siteName>-<original squad name>(FSA-bay1); unnamed squads become<siteName>-squadN. - Pod records are copied byte-for-byte from the inputs — GUIDs, IPs, MACs, keys, art paths all pass through untouched. Only the squad records (which carry the name) are re-serialized.
- The output declares the TeslaConsole assembly identity captured from the first input, so the console accepts it as its own.
Warnings (merge proceeds; read them):
- duplicate pod GUID or MAC across inputs — same pod imported twice?
- same IP at two sites — expected until sites renumber into their
10.0.<site>.0/24; it must be resolved before actually linking.
Hard error: duplicate post-rename squad name (same site file given twice).
Build
dotnet build -c Release
Targets .NET Framework 4.8 (same toolchain as TeslaSuite); output at
bin\Release\net48\SiteConfigMerge.exe, runs on any Windows 10/11 box.
File format (from TeslaSuite\Console\TeslaConsole\Site.cs)
int32 squadCount
per squad:
BinaryFormatter(TeslaConsole.Squad) mGuid, mName, mOnline
int32 podCount
podCount × BinaryFormatter(TeslaConsole.Pod)
mId, mIPAddress, mGateway, mDns, mSubnet, mHostName,
mKey, mMacAddress, mName, mPodArtPath, mHostType, mOnline
The tool uses stand-in types with a SerializationBinder mapping TeslaConsole.*
both directions, so it has no build dependency on the TeslaSuite repo.
Verification status (2026-07-10)
- Decoded a real
local.siteconfig(squadbay1, TeslaConsole 4.11.4.1 identity). - Merged two simulated sites; duplicate-GUID and IP-overlap warnings fired correctly.
- The real
TeslaConsole.exe(4.11.4.1) loaded the merged output through its ownSite.LoadFromFile— squads renamed, pods intact (reflection harness).
Deploying to the central console
TeslaConsole loads local.siteconfig from its common-appdata directory at startup
(Site.Load()). To arm the central console for an event: back up its existing
local.siteconfig, drop master.siteconfig in its place under that name, restart
the console. Restore the backup after the event.