Settings -> Enable Custom Bitmaps was a static bool with no backing store:
it defaulted to off on every launch, so an operator had to re-tick it each
session and any custom plasma art was silently ignored until they did. New
ConsoleSettings persists machine-level menu toggles as XML in
%ProgramData%\Tesla Console\console.settings, alongside RPDefaults.rpd /
BTDefaults.btd / local.siteconfig. It is loaded once from Main and never
from a static initializer: the differential suite drives PlasmaBitmaps
directly and must keep seeing the original defaults rather than whatever
this machine has saved. A missing file is the first-run case; a corrupt one
is ignored and rewritten by the next toggle, because losing a menu setting
must never stop the console starting.
Custom art is now version-controlled and rolls with the release. New
Console\Plasma Images\ is copied into the package, and the lookup searches
%ProgramData%\Tesla Console\Plasma Images first and the exe-relative folder
second, so a release can never clobber a site's own name bitmaps.
install.bat creates the data-dir folder before the icacls grant so an
unelevated operator can write it. Ships with three 128x32 name bitmaps
(Deadmeat, Muerte, Phrogg); Muerte arrived as "Muerte_128x32-2.bmp", a name
the lookup can never build, so it is renamed to match its pilot.
Two fixes fell out of making the flag sticky. Path.Combine ran on the raw
participant name outside the try block, so with the option on a pilot named
"A:B" threw ArgumentException straight out of egg generation; names that
cannot be a Windows file name now just render procedurally. And the art was
loaded with Image.FromFile, which keeps the bitmap backed by the file and
locked for its whole lifetime — it is copied out through a stream now, so
art can be swapped between missions without restarting the console.
Verified against the built net40 exe: all three shipped bitmaps resolve by
pilot name, ProgramData wins over the shipped copy, a wrong-size file is
ignored, an illegal-character name does not throw, the file is not left
locked, and the settings round-trip and corrupt-file tolerance both hold.
Diff suite 106/106.
Version bumped 4.11.4.4 -> 4.11.4.5 across Console, Launcher, vPOD, the
install/build banners, the diff-suite version assertion and the README's
latest-release pointer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reconfigure timeout (launcher reinstall of an already-configured pod):
- The console pings each configured pod and connects on success, on a loop, and
never tore that down — so it kept hammering the pod's old IP with a stale
connection while SecureConfig tried to bring the pod up on that address, which
timed out. Only a console restart (closing all sockets) cleared it.
- DeletePod now Disconnect()s the pod's connection (closes the lingering socket)
so delete-to-reconfigure works WITHOUT a console restart.
- Reconfiguring a known pod in place now pauses that pod's ping/connect loop
(OperationInProgress) and drops its stale connection before SecureConfig, and
resumes on completion (success or failure) so it reconnects with the new key.
(StopPing kills the ping thread irreversibly, so pause via OperationInProgress.)
Note: PodInfo's static mPods registry is dead code (nothing registers), so the
real fix is the disconnect, not an unregister.
Console deployment:
- Console/install.bat: installs the console to C:\Program Files\TeslaConsole,
preps the %ProgramData%\Tesla Console data dir (Users: modify), creates a Start
Menu shortcut, and adds a per-program inbound firewall rule so it can receive
pod discovery beacons. net48 is in-box, no runtime install.
- Console/build-package.bat: publishes the console (net48 framework-dependent) to
dist\TeslaConsole\App and assembles the package with install.bat.
74 tests green; the pod-config fix is UI/network behavior, validate on a pod.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CydandClaude Opus 5