tehAon’s Control Panel – Every Mod’s Settings and Hotkeys in One Screen

The panel wrote `*.local.xml` for every mod, but only some mods read one. For the rest it reported
success, the player restarted, and nothing had changed — the worst outcome available, because it
looks exactly like it worked. On the author's own install that was ten of twenty-two mods.
- **Mods that read no override file are now edited in their own config.** Each mod's assemblies are
scanned for the literal `.local.xml`; a mod that never names one cannot be reading one. Those mods
are marked `[direct]` in `ms`, and every change says plainly that it went into the mod's own file
and that an update to that mod will replace it. The file is copied to `*.orig.xml` before the first
write, which is both a restore point in a mod we do not own and the baseline "reset to default"
measures against — otherwise the baseline would drift to whatever the file said at world load.
- **A manifest can declare `overrides="local"` or `overrides="direct"`.** Consulted only when there
is no assembly to read — an XML-only mod, or a half-installed one. The installed DLL wins over a
manifest otherwise: a manifest promising an override file the player's actual build does not read
puts the panel back to writing files nobody opens.
- **A concurrent writer is no longer clobbered.** Saves re-read the file from disk and replay the
staged edits onto that, instead of writing the copy loaded at world load. ScoutMap rewrites its own
override file whenever the map is moved or resized, and a mod that owns its config rewrites it on
every console command — so changing any ScoutMap setting in the panel used to silently revert the
map layout to wherever it was when the world loaded.
- **`threatMaxY` and `maxMarginSeconds` were missing** from the bundled ScoutMap and FuelTopOff
manifests, so the panel hid two real settings. A manifest replaces the generic reader rather than
merging with it, which is exactly the failure the coverage test exists to catch — and it was not
catching it, see below.
- **The test sui…

Two bugs the panel could not report on itself, both found by looking at the screen.
THE SIDEBAR NEVER REPAINTED. Clicking a different mod changed the settings list but left the
highlight, the amber name and the changed-count on the mod you came from - the one thing on screen
telling you where you are was the one thing that was wrong. Every {binding} registers on the nearest
enclosing controller that is not a bare XUiController and stops there, so a sidebar row owns its
name, count and selected state exclusively. IsDirty is an inert field on XUiController: the base
Update never reads it, only XUiC_List and its nested XUiC_ListEntry do, which is why the middle list
needed nothing. The row set the flag and nothing consumed it, so it kept whatever it was painted
with the first time. It now consumes its own dirty flag from Update, the way the vanilla list entry
does.
SCOUTMAP'S SEVEN KEY BINDINGS WERE READ AS PLAIN TEXT, so they were absent from the KEYS page,
absent from the conflict check, and could not be rebound by pressing a key - while their rows looked
perfectly normal. The type inference in both the panel and the manifest generator matched only the
suffix spelling (stackHotkey); ScoutMap names its bindings the other way round (keyToggle,
keyZoomIn). Both now match either spelling and confirm it against the value, with a numeric guard:
Enum.Parse reads a bare "5" as KeyCode 5, which would have turned a keyRepeatDelay into an
unbindable hotkey. keyNudgeModifier stays text on purpose - a held modifier never fires on its own,
and the key capture refuses to record one.
With ScoutMap's keys visible, the KEYS page now reports collisions that were always there and could
not be seen: F5 (ScoutMap toggle vs Materialist panel), Backslash (ScoutMap rotate vs Focus panel),
and Home / End (ScoutMap size and corner vs SteadyView's HUD and pin).
Regression tests for both, 199 total: both binding spellings and the near misses that must NOT be
read as keys (a localization id, a n…

ScoutMap 0.2.0 shipped a round map, and the bundled manifest still described the square one.
EIGHT NEW SCOUTMAP SETTINGS ARE ON THE PANEL: hardCircle, showFrame, rimPx and colorRim under View,
and refreshSecondsFast, fillFromLoadedChunks, mapFillPerSweep and requestServerMapStream under
Upkeep. Without them the round map, the rim and the two map-completeness fixes were configurable
only by editing XML - which is the thing this panel exists to stop.
FIVE SETTINGS SCOUTMAP REDEFINED NOW SAY WHAT THEY NOW DO. circleMask no longer "fades the corners
to colorVignette"; it selects a genuinely clipped round map. maxSpanBlocks became a ceiling rather
than a size, rotateWithPlayer is safe with either shape, showAnimals covers the "awake" mode as well
as "all", and debugTiming logs two more counters. Stale help is worse than none: it is read as
current and acted on.
FOCUS GAINED THE EIGHT SETTINGS ITS MANIFEST NEVER HAD: money, moneySeconds, moneyContainers,
moneyRadius, moneyTraders, moneyUnlockedOnly, harvestDebug and harvestDebugRows. This one was not
new - the bundled-manifest coverage test had been failing on it for some time, which is exactly the
failure a test is supposed to stop you shipping past. The manifests now cover every setting every
bundled mod ships, and the suite is green at 200.
Nothing in the panel's own code changed.

- **Claims game 3.2.0.** `GAME_VERSIONS` widens from `V3.0.0-V3.1` to `V3.0.0-V3.2.0`.
Verified in game on a real V3.2.0 b10 client, not inferred: see `VERIFIED` for what was
actually exercised. No behaviour changed — this release is the claim and nothing else.
## Unreleased
- **A MODS view, and `ms mods` / `ms on <mod>` / `ms off <mod>`: switch a whole mod off from here.**
The panel could already show every binding and every collision, and rebind either side of one —
but the answer a player actually reaches for is often "leave both keys alone and turn one of the
two mods off while I use the other", and that meant finding the mod's own `enabled` setting inside
its own page. It is now one screen: every mod, ON or OFF, how many keys it claims, and how many of
them are in conflict, with the off ones counted on the sidebar.
The toggle writes the mod's own root-level `enabled` through the same path every other setting
change takes — override file, live reload — so it is a different way in, not a second mechanism.
Mods that ship no such setting are LISTED as such rather than silently missing, because a mod
absent from the list reads as the panel failing to see it.
- **`package.sh` now refuses to build a zip whose game-version label it cannot back up.** New
`tools/check_game_versions.py` reads `GAME_VERSIONS`, finds a game build for each version named,
and resolves every external reference in the DLL against all of them. A claimed version with no
build available fails too, rather than quietly passing — an unverified claim is the point. It also
compares `GAME_VERSIONS` against the same claim spelled in C#, so the zip name and the line the
mod prints at startup cannot drift apart.
This is the check that would have caught DroneAutomation v0.7.3, which shipped labelled
`V3.0.0-V3.1` and could not run on 3.0.0 at all. It was built against a newer game, which had
moved `AddItem` onto a base class 3.0.0 does not have — and the build succeeded, a refcheck
against 3.1 …