ATLAS Constants Switcher
Swaps a running Motion Applied ATLAS 10 session onto a different set of Function constants in a few seconds - no restart. Built for exactly the situation a serious multi-car team hits constantly: switching between two cars' constant sets mid-session, quickly and without disrupting the engineers already working in ATLAS.
The problem it solves
ATLAS 10 loads its Function constants - the values custom FDL functions reference, stored in
Constants\default_constants.txt - once at startup. Normally, switching to a
different car's (or track's) constants means editing that file by hand and restarting ATLAS,
which is disruptive mid-session and simply too slow when a team needs to move between two cars'
setups repeatedly through a weekend. ATLAS has no built-in "reload constants" command and no
official plugin or scripting API that exposes constants at all - what it does have is a live,
in-app Constant Editor that can Add, Update or Delete individual constants while running, with
every change written straight through to disk immediately. This tool drives that exact editor
under the hood: it reads what's currently loaded, diffs it against a saved "profile" file you
pick from a list, and applies only the Add/Update/Delete operations needed to match - live, in
a few seconds, with ATLAS never closing.
What's involved
With no official ATLAS scripting API, the tool drives the same Constant Editor a person would click through - via the accessibility layer screen readers use (Invoke, SelectionItem and Value patterns), not simulated mouse clicks. That means it doesn't need the ATLAS window focused or on top to work.
A profile is a plain Name<TAB>Value text file - the same format as ATLAS's
own constants file - dropped into a Profiles folder. The documentation's own
example profile names are literally Track A.txt and Car 2.txt.
It reads the live Constant Editor grid, compares it against the chosen profile, and only touches what actually differs - added, updated or removed - rather than clearing and re-entering everything on every apply.
v3 is the current recommended build: it fixes v1/v2's tendency to leave the Constant Editor and Function Editor panels stuck open over the ATLAS workspace after a silent close failure, and adds a "Currently loaded" indicator that remembers the last profile applied, even across restarts of the tool itself. All three versions still share the exact same single-instance lock, because two copies racing on the same Name/Value fields has been observed to crash ATLAS outright.
Why it's worth trusting
The riskiest part of this kind of tool is firing an Add or Update while the editor's Name field is unexpectedly blank - ATLAS throws an unhandled, app-crashing exception if that happens. The script re-reads the Name field immediately before every click and skips the operation rather than firing blind if it doesn't match what was just set, which is also what catches a second copy of the tool interfering with the same dialog. A delete always raises ATLAS's own "are you sure?" confirmation, which the tool waits for and accepts automatically rather than assuming it won't appear. And v3's panel-closing logic was deliberately changed to always close the Constant Editor and Function Editor after every run, regardless of who opened them - closing only-if-we-opened-it sounds safer, but a single silent failure under that rule left every future run believing the panels were already open and skipping the close entirely, which is exactly what caused the stuck-open workspace bug v3 fixes.
Known limitations are documented plainly rather than glossed over: only the "Default" constants scope is managed, not per-Recorder Sets; a cosmetic quote-formatting difference between the profile file and ATLAS's own editor can occasionally log a harmless no-op "update" on a text-valued constant; and since ATLAS 10 has no official plugin SDK, the tool depends on today's UI layout and may need updates after a future ATLAS interface change.