Local and Dev Mods

The Launcher’s loadout system has an escape hatch for DLLs that are not on the mod platform: each loadout has a local/ directory whose contents are layered on top of platform-catalog mods when that loadout starts.

Note

This is the supported workflow for iterating on a mod you are developing, running a private build, or loading a mod the catalog does not carry. The Launcher does not curate, sign, or version-check anything in local/.

Where to drop files

GameRoot/
`-- loadouts/<loadout-name>/
    `-- local/
        |-- Mods/
        |   `-- MyMod.dll
        |-- UserLibs/
        |   `-- MyMod.SharedLib.dll
        `-- UserData/
            |-- i18n/
            |   `-- mymod/
            |       `-- en.yaml
            `-- Anomaly/
                `-- Overrides/
                    `-- AudioClip/
                        `-- mymod_alert.ogg

• local/Mods/* becomes part of the loadout runtime Mods/.
• local/UserLibs/* becomes part of the loadout runtime UserLibs/.
• local/UserData/* becomes part of the loadout runtime UserData/.

Subdirectories are preserved.

Override semantics

The materializer first rebuilds the loadout runtime from catalog packages, then copies local/ on top. For Mods/ and UserLibs/, last writer wins, so a local DLL with the same filename replaces the catalog package’s copy for that loadout.

local/UserData/ is also copied last and can overwrite package-provided files. It does not clear files that are absent from local/, so user-added languages and loadout-specific data survive between launches.

Package-provided UserData has extra protections:

• UserData/Anomaly/ from packages is rebuilt so shipped overrides update.
• UserData/Skins/ from packages is skipped because skins are user-owned.
• Package MelonPreferences.cfg and Loader.cfg are skipped because they are user-owned preference files.
• Package UserData/i18n/<modId>/ files overwrite matching files but preserve languages and files absent from the package.

Iteration loop

1. Build your mod. The output is typically bin/Debug/net6.0/MyMod.dll.
2. Copy or link it into GameRoot/loadouts/<your-loadout>/local/Mods/MyMod.dll.
3. Launch the loadout through the Launcher.
4. Check the in-game MelonLoader log to confirm the mod loaded.
5. Edit, rebuild, re-copy, relaunch.

A filesystem link into your project’s build output can avoid the copy step. On Windows, use mklink; on Linux, use ln -s.

Coexistence with trackAnomalyClient

If your loadout has trackAnomalyClient: true and you are working on a fork of Anomaly.Client, drop your built Anomaly.Client.dll into local/Mods/. Because local files are copied after cached platform files, your build replaces the catalog version for that loadout even though the catalog version may still be resolved at launch.

To skip the catalog lookup entirely, set trackAnomalyClient: false in loadout.json.

What the Launcher does not do

• It does not call the platform API for files in local/.
• It does not version-check, review, or malware-scan local DLLs.
• It does not back up or source-control local files.

Keep your dev DLLs and assets in source control, not only under GameRoot/loadouts/.

Next

Architecture Choices for choosing the right client/server shape.