Loadouts and Game Versions

The Launcher keeps game files separate from Anomaly.Launcher.exe, can hold multiple SCP:SL builds side-by-side, and groups your mod choices into named loadouts.

Concepts

• GameRoot - the folder you choose to hold game files, mod cache, loadouts, and, on Linux, Wine prefixes. It is persisted in %APPDATA%/Anomaly/user.json.
• Game version - one installed SCP:SL build, such as 14.2.6, under GameRoot/games/<version>/.
• Loadout - a named bundle of one game version, platform-catalog mods with pinned versions, and the trackAnomalyClient flag.
• Mod cache - extracted catalog packages under GameRoot/mods-cache/<modId>-<version>/, shared by any loadout that uses that package.
• Runtime view - the materialized active files for one loadout under GameRoot/loadouts/<name>/runtime/.
• Local mods - user-supplied files under GameRoot/loadouts/<name>/local/, layered over catalog packages at materialize time.

Anomaly.Client tracking

Each loadout has a trackAnomalyClient flag, on by default. When enabled, the Launcher tries to resolve and download the latest Anomaly.Client compatible with the loadout’s game version at launch time.

If resolution fails because the network is down or no compatible release exists, the Launcher logs a warning and still launches the loadout without Anomaly.Client. You can also turn the flag off and pin Anomaly.Client as an ordinary mod, or omit it for vanilla-with-loadout setups.

On-disk layout

GameRoot/
|-- games/<gameVersion>/
|   |-- SCPSL.exe
|   |-- SCPSL_Data/
|   |-- version.dll
|   |-- MelonLoader/
|   `-- .anomaly_links.json       present only while a loadout is linked/running
|-- mods-cache/<modId>-<version>/
|   |-- package.json
|   |-- Mods/
|   |-- UserLibs/
|   `-- UserData/
|-- loadouts/<name>/
|   |-- loadout.json              { gameVersion, enabledMods[], trackAnomalyClient }
|   |-- runtime/
|   |   |-- Mods/
|   |   |-- UserLibs/
|   |   `-- UserData/
|   `-- local/
|       |-- Mods/
|       |-- UserLibs/
|       `-- UserData/
`-- wineprefixes/<loadout>/       native Linux launcher only

What happens at launch

1. The Launcher resolves the active loadout and its game version.
2. It checks that GameRoot/games/<version>/ exists; if not, install that build first.
3. For each catalog mod in the loadout, it ensures the package exists in mods-cache/.
4. If trackAnomalyClient is on, the latest compatible Anomaly.Client is added to the effective mod set.
5. LoadoutMaterializer rebuilds loadouts/<name>/runtime/ from cached packages and local/ overrides.
6. The Launcher links the runtime Mods/, UserLibs/, and UserData/ folders into games/<version>/.
7. The game starts from GameRoot/games/<version>/SCPSL.exe.

On Windows, loadout links are directory junctions created with mklink /J, so they do not require administrator-only symlink privileges. On Linux, the Launcher uses directory symlinks.

The Launcher writes games/<version>/.anomaly_links.json before link activation. On normal exit it removes the active links; on the next launch it also uses the sidecar to clean up stale links from a crash or forced close.

If a real non-empty Mods/, UserLibs/, or UserData/ directory is blocking the link path, the current Launcher migrates its contents into the runtime target before replacing it with the link. Conflicts resolve by last-write time, with the live source file winning ties.

UserData ownership

Mods/ and UserLibs/ are rebuilt every launch from the effective loadout. UserData/ is more careful because it contains user preferences and runtime state:

• Package-managed UserData/Anomaly/ is rebuilt during materialization so shipped overrides update.
• Package UserData/Skins/ is user-owned and skipped.
• Package MelonPreferences.cfg and Loader.cfg are skipped.
• Package and local UserData/i18n/<modId>/ files overwrite matching files but preserve languages and files absent from the incoming package.
• Loadout local/UserData/ files are copied last and can overwrite package-provided UserData files.

Local mods

Drop hand-built or non-catalog DLLs into GameRoot/loadouts/<name>/local/Mods/. Local files are layered after catalog packages, so a local DLL with the same filename replaces the cached package file for that loadout.

See Local and Dev Mods for the developer workflow.

Migrating from a single-install setup

If you upgrade from a Launcher version that kept SCPSL.exe in the same folder as Anomaly.Launcher.exe, the new build detects the legacy layout and offers to migrate:

1. Pick a GameRoot.
2. The Launcher copies game files into GameRoot/games/<detected-version>/.
3. Catalog mods listed in the old install state are snapshotted into mods-cache/<modId>-<version>/ and added to a default loadout.
4. Unknown DLLs in the old Mods/ or UserLibs/ folders move into loadouts/default/local/ so dev mods survive the move.
5. The old folder is left intact unless you opt into cleanup.

If migration is interrupted, rerun it. The migrator copies into the new layout before persisting the GameRoot.

Linux and Steam Deck

• Steam Deck Gaming Mode or Windows launcher under Proton: add Anomaly.Launcher.exe as a non-Steam game and force a Proton compatibility tool. The Launcher sets WINEDLLOVERRIDES=version=n,b when spawning the game so MelonLoader’s version.dll injects under Proton.
• Native Linux Launcher: loadout launches shell out to umu-run from umu-launcher, with a per-loadout WINEPREFIX under GameRoot/wineprefixes/<loadout>/ and PROTONPATH=GE-Proton. If umu-run is missing, the Launcher shows a distro-aware install hint for you to run manually.

Next

Troubleshooting and Logs.