This is the generic version of a pattern the per-game guides each show once. If your game has its own guide here — Skyrim, Lethal Company, Bannerlord, RimWorld, Baldur's Gate 3 and the rest — read that for the exact names and IDs. This page is the shape they all share, for when yours doesn't have a guide yet.
01The three layers
A working modded game is a stack of three things, and a patch can break any of them. The reason a naive downgrade fails is that people fix only the first:
- The game build — the version of the game itself.
- The loader — the framework that lets mods run at all (a script extender, BepInEx, a modding API). It hooks into the game's executable, so it's locked to the build.
- The mods — built against a specific loader and game version.
The rule that makes everything work, and the one sentence to take away: game build, matched loader, matched mods — one era, all three. Mix eras across those layers and you get the crash-on-launch that fills every modded game's forums after a patch. The three sections below are those three layers in order.
02Layer 1 — get the build
Decide which version you need first — your essential mods' pages state the game version they target; that's your destination, not "the newest that still has the mod." Then get that build, easiest route first:
- Official legacy branch. Many developers keep old versions in Steam's Betas tab — pick it, done, no tooling. Check there before anything else.
- By manifest. No branch for your version? Download it with DepotDownloader — the universal downgrade guide walks the whole flow and find-your-IDs covers the SteamDB lookup.
Then stop Steam re-updating it — set Updates to "only when I launch" plus the read-only appmanifest trick, or keep the pinned build in its own folder away from your live install. The mechanics of installing and pinning are in after the download. A re-update silently undoes everything below, so this step isn't optional.
03Layer 2 — the loader under your mods
This is the layer people forget, and it's almost always what actually crashes. Nearly every mod ecosystem stands on a loader that's compiled against the game binary — change the game version and the old loader stops loading, taking every mod above it with it. Match the loader release to your game build. The big families:
| Ecosystem / loader | Games (examples) |
|---|---|
| Script extender — SKSE / SKSE64, F4SE, etc. | Bethesda games: Skyrim, Fallout. Version-locked to the exe; the famous case. |
| BepInEx (+ Thunderstore / r2modman) | Unity games: Lethal Company, Valheim, Risk of Rain 2, Subnautica, Sons of the Forest (RedLoader). |
| Harmony + framework mods (ButterLib, UIExtenderEx, MCM) | Bannerlord — the "big four" under most mod lists. |
| Per-patch Modding API | Hollow Knight — a separate API build per game patch; the manager fetches the matching one. |
| ModTheSpire + BaseMod | Slay the Spire — two required libraries, both version-locked. |
| SMAPI | Stardew Valley — the loader nearly every mod needs; pin the SMAPI build that matches your game version. |
| tModLoader | Terraria — itself versioned to the Terraria build it targets. |
| Script Hook V | GTA V single-player — breaks on every title update until it's rebuilt. |
The diagnostic shortcut: when a downgraded modded game crashes at the launcher or main menu, suspect the loader first, not the flashy mods on top. The mistake I made first, more than once, was reinstalling the mods one by one to find the culprit — it was the loader every single time. Get the loader's release that's dated for (or labelled for) your game version, and most of the breakage usually disappears.
04Layer 3 — era-correct mods
With the build and loader matched, the mods themselves have to be the versions built for that pairing. The good news is that most mod hosts keep old versions:
- Nexus Mods — every mod's "Old files" / archived-files tab holds previous versions. Grab the one that matches your game/loader era.
- Thunderstore — keeps every past release of every mod, tagged by version; r2modman installs the right one per profile.
- GitHub releases — loaders and many mods are versioned here; the release dated for your era is the one.
Trim the list to what you actually need, then assemble it against the pinned install. If your manager supports it, the cleanest method is a per-version profile (below). Keep each game version's mods separate from the others — a folder of current-version hooks pointed at an old build is a crash generator, not a time machine.
05The Workshop version-history trap
06Letting a mod manager do it
You don't have to track all this by hand — the managers built for these ecosystems do the era bookkeeping, especially the side-by-side case (a pinned modded build next to your current install):
- r2modman / Thunderstore (BepInEx games) — per-profile, installs version-matched mods and the right BepInEx; the profile-transplant trick (build a profile, copy its files into the pinned game folder) gives a standalone modded install.
- CKAN (KSP) — thinks in instances: point it at each install and it resolves only mods compatible with that instance's version.
- Vortex / Mod Organizer 2 (Bethesda & others) — profile-based; point them at the pinned install and manage that era separately.
Whichever you use, the discipline doesn't change — it just gets automated. If it were my install, I'd let the manager handle the bookkeeping and spend my own attention only on the one must-have mod that decides the era. Decide the era from your must-have mod, get that game build and pin it, install the matching loader, then the matching mods, and keep the whole set together. Archive that trio (build + loader + mods) the way the preservation guide argues, and the modded game you love survives the next patch that would have broken it.