Resolve Terraria mod mismatches without losing modded saves

After a Terraria-related update, first check which program is running. A vanilla server, tModLoader and TShock have different compatibility rules. A client mismatch may need coordinated releases; a plugin load error may need an updated API dependency. Neither problem justifies deleting the world.

Separate the failing stage

1. Capture both ends. Save the server's startup output and the affected client's complete error. Note whether the server reaches its ready state, whether another player can join and whether the failure started immediately after a game, loader or package update.
2. Compare the software family and branch. Record the Terraria release, tModLoader branch/build where applicable, and all enabled package versions. A preview client and stable server are not an assumed compatible pair. For TShock, record the TShock and Terraria Server API versions alongside plugin releases.
3. Preserve current data before experiments. Stop normally and back up the selected world, complete player data, configuration, package files and relevant databases. The tModLoader backup instructions treat a world's .wld and .twld as a pair. Do not restore only one file or mix timestamps. Save paths differ between major branches and hosted layouts.

If tModLoader clients cannot join

Compare the enabled mod set rather than only the Workshop subscription list. A downloaded package can be disabled, and a manually installed file may differ from its Workshop release. Check dependency versions and whether the author's update requires configuration changes or a new world. Read the first mod-specific exception in the client and server logs.

For servers using the upstream management tools, Dedicated Server Utils distinguishes the Workshop installation list from the enabled list. Check the effective install.txt and enabled.json in that layout. A hosted template can place these elsewhere; changing an unused copy will have no effect. Coordinate a known compatible pack with one test client before asking every player to reinstall anything.

If a TShock plugin fails

Check the first assembly, API or configuration error and compare it with the plugin author's supported releases. The TShock parameter documentation describes both the standard ServerPlugins location and optional additional plugin directories. Inspect the actual startup arguments for an overlooked second copy. Do not bypass API-version checks to force an old DLL to load; a bypass does not make its code compatible.

On an isolated copy, reverse the newest plugin change with its documented dependencies and configuration. Preserve account and server-side-character databases, including any external database needed for the test. If permission changes are involved, test with an ordinary account instead of granting everyone administrative access.

Confirm a safe recovery

Use a disposable world to isolate runtime/package failures before opening a copied production save. Once the compatible set starts, test the copied world, an existing character and the affected feature. Repeat a save/start cycle. A clean startup alone does not validate stored mod content.

Rollback means restoring a compatible runtime, complete package set and appropriate pre-update data together. Keep the failed state for investigation and avoid saving a content-dependent live world with missing mods. Send support the sanitized first error and the exact combinations tested if the failure remains.

Related: protect server-side characters and check player connections.