Menu
 

Mid-Save Update Broke My Modded World — Recovery Guide

Mid-Save Update Broke My Modded Vintage Story World — Recovery Guide

One of the most painful Vintage Story dedicated-server problems: you update the server from 1.21 to 1.22 with mods installed, the world saves successfully, players join, and then... chunks won't load. Players walk to the edge of their existing base and the world just stops. Server log shows mysterious deserialization errors. This page is the diagnostic flow for that exact scenario.

If you're reading this in panic: stop the server NOW. Don't let players continue playing in a partially-broken state. Make a backup of the current save state, then work through this page methodically. Most modded mid-save corruption is recoverable with patience.

What just happened (the technical version)

A mod that worked in 1.21 wrote custom block entity data, custom item data, or custom NBT into your world's chunks. When you updated to 1.22:

  1. The mod either failed to update at the same time, OR updated but with breaking changes to its data format.
  2. When 1.22's chunk loader tries to deserialize a chunk containing that mod's data, it hits an exception.
  3. The loader logs the error and skips that chunk silently (in some versions) or hangs (in others).
  4. To the player, the world just "doesn't exist" past their last visited chunk before the update.

The world data is usually still THERE in the .vcdbs file. It just can't be deserialized by the new mod version.

Step 1 — Stop the server immediately

If players keep playing in a broken state, two things get worse:

  • The chunks that DO load can write modified data that compounds the corruption.
  • The auto-backup may overwrite your last clean (pre-update) backup.

Stop the server. Don't restart yet.

Step 2 — Snapshot the current broken state

Copy the entire VintagestoryData/Saves/<world-name>.vcdbs file to a safe location. This is your "what we have right now" snapshot. You may need it later for partial recovery even if it's not loadable.

Also copy VintagestoryData/Mods/ and serverconfig.json. These tell you exactly what mod set existed at the moment of breakage.

Step 3 — Identify the breaking mod

Open VintagestoryData/Logs/server-main.txt from the most recent server run. Look for lines that look like one of these:

System.IO.InvalidDataException: Could not deserialize block entity at ...
  at ModName.SomeBlockEntity.ReadFromTreeAttribute ...

NullReferenceException: Object reference not set ...
  at Vintagestory.Server.ChunkLoader.LoadChunk ...
  at ModName.SomeClass.OnLoaded ...

System.MissingFieldException: Field 'SomeField' not found on type ...

The mod namespace in the stack trace is the breaking mod. Note its name and check its page on the Vintage Story Mod DB to see if a 1.22 update is available.

If multiple mods appear in the log, the FIRST exception is usually the root cause — subsequent errors are cascade effects.

Step 4 — Three recovery paths, ranked by data preservation

Path A: Wait for the mod's 1.22 update (best data preservation)

If the breaking mod has a 1.22 build in progress (check the Mod DB and the mod's Discord), this is the cleanest path:

  1. Roll your server back to 1.21 temporarily.
  2. Restore your pre-update save backup.
  3. Tell players the server is "paused" until the mod updates.
  4. Wait for the mod 1.22 build.
  5. When ready: update mod AND server together (not server first).

This costs days of community downtime but preserves 100% of the world.

Path B: Remove the breaking mod (medium data loss)

If the mod is abandoned or not getting a 1.22 update, you'll have to live without it:

  1. Roll back to 1.21 first.
  2. Restore your pre-update backup.
  3. Stop the server.
  4. Walk to every base/structure built with the breaking mod's content (via admin teleport).
  5. Have players salvage anything they want from those structures into vanilla containers.
  6. Now remove the mod. Some blocks will become "unknown" placeholders. Use admin commands to clean them: /blockentity remove or use a save editor.
  7. Update to 1.22 cleanly.

This costs significant player time but preserves the world structure.

Path C: Force-load past the corruption (most data loss)

If you don't have a backup and rolling back isn't possible, you can attempt to force the server to load by tolerating corrupted chunks:

  1. Stop the server.
  2. Edit serverconfig.json and add: "AllowCorruptChunkLoad": true (if this option exists in your VS version; otherwise see step 3).
  3. Use a save editor (community tool, available on the Vintage Story Discord) to identify chunks containing the breaking mod's data and either delete them or strip the mod's data from them.
  4. Start the server. Corrupted chunks will be empty/regenerated.
  5. Players lose anything stored in those chunks.

This is a last-resort path. Document for affected players exactly what was lost so they can rebuild.

Preventing this next time

Mid-save mod-related corruption is the single biggest hosting risk in modded Vintage Story. Three habits prevent it:

  1. Never update the server version before mods are confirmed compatible. Check each mod's page for "1.22 compatible" status. If any mod is still 1.21, wait.
  2. Take a full backup before any update. Stop the server, copy VintagestoryData/Saves/ AND Mods/ AND serverconfig.json to a separate location BEFORE the update. Not just "the file is there in case" — actively copy it.
  3. Test the update on a copy first. If your hosting supports it, clone the server, update the clone, let one trusted player walk around. If it works, do the real update.

Common scenarios and which path fits

ScenarioRecommended pathWhy
Popular mod with active dev, 1.22 update in progressPath A (wait)Mod update usually ships within 1-2 weeks; rollback preserves everything
Abandoned mod with no update plannedPath B (remove, salvage)Mod is dead anyway; better to migrate while content can be salvaged
You don't have a pre-update backupPath C (force, accept data loss)Only option that doesn't require backup; document losses for players
Multiple mods broken at oncePath A for the salvageable ones, Path B for the dead onesHybrid approach; fix in priority order
Server is your business / paid by usersPath A even if it costs weeksCustomer trust > update urgency

What to communicate to players

Whatever path you choose, communicate clearly to players. Honest:

  • Acknowledge that an update broke something.
  • State which mod is the cause (it's not their fault).
  • Outline the recovery path and timeline.
  • Be honest about expected data loss, if any.
  • Offer migration help / compensation (admin-spawned replacement items, etc.) if appropriate.

Players will accept significant inconvenience if they understand what happened and feel respected. Silence or vague "we're investigating" responses lose communities.

Related guides

Want a hosting setup where mid-save mod issues don't cost you the world? Supercraft Vintage Story hosting takes hourly auto-backups with 14-day retention, lets you clone servers for safe update testing, and pins both VS version and mod versions on a per-deployment basis. Plans from $5.99/mo.

Tired of fighting this issue every patch?

Run a managed Vintage Story server with us. We handle the patches, mod-version pinning, save backups, and DDoS protection. Set up in 3 minutes, 5 datacenter regions, no contract.

See Vintage Story hosting plans →
Top