Match this symptom
After an update, the server fails during startup, returns players to the menu, or loads a world without expected mod content.
The answer first
Stop the server before the modded world saves in an incomplete state. Back up ShooterGame/Saved, preserve the existing -mods list and logs, then verify server/client versions and each mod's current compatibility before changing the list.
Freeze the evidence
- 1Stop automatic restarts and prevent players from joining until the mod state is understood.
- 2Copy ShooterGame/Saved, the launch command and the current logs outside the install directory.
- 3Record the exact -mods argument and order. The ARK configuration reference documents -mods as the startup list for mod identifiers.
- 4Record which game, server and mod updates occurred before the first failure.
Read the failure point
- Server exits while loading one mod: verify that mod's current server compatibility and installation.
- Server starts but clients cannot join: compare client and server mod versions and required platform support.
- World loads with missing structures or creatures: stop immediately and restore the pre-update point rather than saving over the modded state.
- The list is ignored: confirm the -mods syntax and that the startup tool is using the edited command.
Controlled recovery
- 1Update the dedicated server and client first, keeping the world backup untouched.
- 2Refresh only the identified mod when its publisher confirms compatibility, then test privately.
- 3If one mod remains incompatible, wait for its update or restore the pre-update server state. Removing it from a live world may permanently remove mod-owned objects.
- 4Once a test join verifies the expected structures, inventories and map, create a new recovery point before reopening.
Prevent the next surprise
Schedule game and mod changes instead of applying them immediately. Keep an exported mod list, preserve a known-good server build when licensing permits, and require a verified recovery point before every maintenance window.
Read mod failures in load order
Preserve the earliest mod-related error and the package loaded immediately before it. A download or entitlement failure differs from a package that loads and then calls an incompatible API. A server that reaches the map while clients fail can indicate a client package/version gap, while missing structures after world load is a data-integrity emergency that should stop all further saves.
Build a manifest containing the ordered mod IDs, publisher release/update times, dependencies, supported platforms, and the last server build that passed. Restore or update dependency groups together only where their publishers require it. After recovery, inspect representative mod-owned creatures, structures, inventories, and configuration through a save/restart cycle; a process reaching 'online' does not prove the modded world is complete.
If a mod publisher has not marked the package compatible with the current ASA build, treat that absence as unresolved—not evidence that reinstalling it repeatedly is safe. Retain the known-good snapshot and communicate the dependency block instead of opening the world with content missing.