How to Update Params After a Game Patch

When FromSoftware patches a game, your mod doesn't come along. Your regulation.bin was built on the old param tables, and the patch ships a new one with changed values, sometimes new rows, occasionally new fields. Keep your old modded file and you miss the patch's fixes; copy the new vanilla file over your mod and you lose every edit. The fix is to re-base: carry your changes forward onto the new version's regulation.bin so you get the patch and keep your mod — using the same CSV workflow as merging. (Raw CSV mechanics: CSV export and import; here that workflow is applied to the patch scenario.)

What a patch actually does

A patch replaces the game's regulation.bin. The new file usually keeps the same overall structure but changes values on existing rows, may add new rows (new items/enemies), and occasionally adds or alters fields when the patch introduces mechanics. Your mod is a regulation.bin frozen at the old version — there's no in-place "sync," they're independent snapshots. To update, move your specific changes onto the new snapshot rather than reconciling two whole files by hand. In the most disruptive case — the Elden Ring 1.12 (Shadow of the Erdtree) boundary — the format changed enough that v1.11.1 can't open the new file at all (covered at the end).

The re-base — via CSV

Works regardless of tool version, because it operates on your changes, not the whole file:

1. Open your current mod (the project built on the old version).
2. Isolate your changes. For each edited table, type modified in the search box so only your rows show, select them (Ctrl+A on the filtered view), File → Export → Param CSV → Selected Rows. One CSV per table.
3. Get the new vanilla base. Update the game, then unpack the new version with UXM for a clean patched baseline.
4. New project on the patched base, Game Type set correctly, pointing at the newly unpacked files.
5. Import your CSVs — File → Import → Param CSV, Replace existing rows / add new rows, confirm. Your edits land on top of the new vanilla values.
6. Save (Ctrl+S). You now have the new patch plus your changes.

Same export-modified → import-onto-base pattern as merging mods; only the base differs — a newer game version instead of another mod's file.

What carries over vs what stays new

Takeaway: everything you didn't touch is automatically current, because it comes straight from the new base. Only rows you both edited and the patch changed need a human decision.

After updating — re-check

Don't assume it's done — verify. In the new project, run modified on each table and confirm your edits are present with the right values. Then think about overlap: if the patch rebalanced something you also modified, your imported value overwrote the patch's. Decide per case whether to keep yours or adopt the patch's (re-import that single row from the new base for the patch's value). For most mods the overlap is small, but checking it is the difference between "updated" and "silently reverted a balance fix."

Updating a merged pack after a patch

Run a merged pack — several mods in one regulation.bin — and a patch is more work, because you have several change sets, not one. The clean way: keep each mod's modified-rows CSV from when you built the pack. After the patch, create a project on the new vanilla base and import each mod's CSV in the same order you originally merged them, resolving overlaps as you go (last import wins on shared rows). This is exactly why the merge guide says to save per-mod CSVs and note which mod won each contested row — that record turns a painful re-merge every patch into a repeatable import sequence. Didn't keep the CSVs? You'll have to re-extract each mod's changes against the old base first — so save them this time. (To make this one command, see DSMSPortable.)

When updating fails

Can't open the new regulation.bin at all — DSMapStudio throws "Unknown DCX format"? The patch is newer than your tool version supports, and no CSV workflow helps because the tool can't read the new base. This is the Elden Ring 1.12+ situation:

• Switch to Smithbox, which reads current patches, and run the same re-base there (vs Smithbox).
• Roll the game back to a version v1.11.1 supports if you need this tool — steps on the Unknown DCX format page.

Either way the re-base method is identical; you're just running it in a tool that can open the new file.

Your mod is now current and still carries your work. Test through ModEngine2, and if you maintain several mods together, the merge guide and Param Editor hub cover the workflows you'll reuse every patch cycle.