# Survival Games

Valheim, Project Zomboid, 7 Days to Die, Terraria, ARK and Palworld server guides.

# Check Palworld crossplay platforms and dedicated-server compatibility

Palworld joining advice has changed as crossplay support developed. An old tutorial that separates every Steam and Xbox server may no longer describe your installation. Diagnose the exact client, server release and joining route before changing configuration or moving a world.

## Establish the platform and build

Ask the player which edition they use: Steam, Microsoft Store on Windows, Xbox, PlayStation or Mac. Record the game version displayed by the client and the dedicated-server build from startup output. Check current Pocketpair documentation for that release. A matching game name does not prove that two independently updated clients speak the same server protocol.

The current server guide documents crossplay-enabled dedicated and community servers. The configuration reference uses `CrossplayPlatforms` to control allowed platforms and marks `AllowConnectPlatform` unavailable in the current version. Do not paste an older single-platform setting into a recent configuration and assume it overrides the current list. Older installations need their own matching documentation.

## Check the joining route independently

Dedicated and community-server presentation can use different joining workflows. Confirm the correct workflow for the player’s current platform rather than assuming every console has the same address-entry screen as a PC client. Record what the player selected and the full error message. A server absent from a browser and a visible server rejecting a connection are different failure stages.

Use only the public game endpoint assigned to this service. Do not give players the panel website, a private container address or an administration API port. If advertising details are wrong, have support check them against the actual listener. Changing a displayed public port does not necessarily change where the server listens.

## Run a small compatibility test

1. Take a configuration copy and record the existing allowed-platform list before editing.
2. Confirm at least one player on a known working platform can join. This establishes a useful baseline.
3. Test the affected platform with a current client, the intended join method and the correct password.
4. Compare the time of the attempt with server output. Determine whether the request reaches the server before investigating platform restrictions.
5. Change one confirmed incompatibility at a time, and retest the working platform after each change.

## Keep crossplay separate from save conversion

Allowing another platform to connect does not automatically migrate an existing local character, convert another hosting format or merge worlds. Preserve the complete existing save before any migration work. Do not delete a player profile to solve a platform error; that can turn a connection problem into lost progress.

Mods can introduce an additional compatibility boundary. Record server mods and affected clients, then check their authors’ current support statements. Do not assume a mod accepted by one platform works everywhere. Send support the client edition, versions, attempted route, timestamp and redacted error. That evidence is more useful than changing several backend flags without a reproducible test.

## Related guides

- [Fix Palworld joining problems](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-palworld-password-and-joining-problems)
- [Move a Palworld world safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-existing-palworld-world-safely)

## Further reading

- [Pocketpair server types and crossplay](https://docs.palworldgame.com/getting-started/about-server/)
- [Pocketpair configuration parameters](https://docs.palworldgame.com/settings-and-operation/configuration/)
- [Pocketpair joining guidance](https://docs.palworldgame.com/getting-started/connect-server/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Check Valheim BepInEx mods before updating a server

## Build a compatibility list first

A Valheim modded server depends on several versions working together: the game, the BepInEx loader, individual plugins and their dependencies. “Newest” in one category is not proof of compatibility with the others. Read each mod author’s supported game build, loader major version and server/client requirements before changing a working installation.

Make a short inventory containing plugin name, version, download source, required libraries and whether clients also need it. Some plugins are client-only; others need matching client and server components. A server-side feature does not automatically work on consoles or other platforms where clients cannot install the required loader.

## Protect the save and the working mod environment

Schedule a maintenance window, stop the server normally and download the world data, startup configuration and existing loader/plugin files. Keep configuration files alongside the matching plugin versions. A world backup alone may not be enough to reproduce modded items or game behaviour after a rollback.

Test on a separate copy where possible. Use a copied save or an explicitly separate test world identifier; do not use the production world as a compatibility experiment. A mod can change saved data even when the server appears to start successfully. Removing its DLL later may not undo those changes.

## Install the right loader and a small test set

Choose a BepInEx package matching the game runtime, operating system and architecture, following the loader and Valheim mod-pack documentation for the exact release. Do not replace a working Valheim loader with an arbitrary generic or preview package. Hosted startup integration may also be required: uploading a loader does not guarantee the launch process actually loads it.

Plugin assemblies normally belong under `BepInEx/plugins`, with generated settings under `BepInEx/config`. Preserve any dependency or patcher layout supplied by the author. Avoid uploading a complete desktop game directory over the dedicated server. If the host’s startup needs adjustment, ask support rather than trying operating-system commands through the game console.

## Read the loader log and verify gameplay

After a test start, inspect `BepInEx/LogOutput.log` when present, plus the game log. Confirm that the loader starts and that the intended plugin versions load. Missing dependencies, duplicate plugin identifiers and method or type errors point to different problems; save the first error rather than only the final crash line.

Add plugins in small dependency-aware groups. Join using a matching client and test the mod’s actual feature, saving and reconnecting. Compare memory and startup behaviour with the earlier baseline. If the loader never appears in logs, investigate startup integration before repeatedly rearranging plugins.

## Return to a known working combination

When an update fails, stop the test, restore the previous plugin/configuration set and use the corresponding untouched world copy if the failed combination saved changes. Do not open a modified world in vanilla simply to see what survives. Keep the incompatible files separately for diagnosis.

For support, provide the game build, loader version, mod inventory and a redacted log excerpt. Remove passwords, access tokens and player identifiers where unnecessary. Report which single change introduced the fault; this is more useful than repeatedly updating every component at once.

## Related guides

- [Plan a safe game-server update](https://help.cloudexa-hosting.com/books/game-hosting/page/update-paper-purpur-and-plugins-safely)
- [Keep a complete Valheim world copy](https://help.cloudexa-hosting.com/books/survival-games/page/transfer-a-valheim-world-without-losing-the-original)

## Further reading

- [BepInEx installation documentation](https://docs.bepinex.dev/articles/user_guide/installation/index.html)
- [BepInEx troubleshooting](https://docs.bepinex.dev/articles/user_guide/troubleshooting.html)
- [Valheim dedicated-server manual](https://valheim.com/support/a-guide-to-dedicated-servers/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Choose the correct ARK Ascended configuration file and section

ARK: Survival Ascended uses several configuration sources. A valid setting in the wrong file can be ignored without an obvious error. Treat configuration as a small, reversible change: establish which file the running server reads, preserve its contents, and test one documented option.

## Identify the active files

Stop the server normally before editing. Download copies of both `Game.ini` and `GameUserSettings.ini`, together with the visible startup settings. Record the map and server build. Do not replace either file with a large configuration downloaded for ARK: Survival Evolved; the two games have different supported options.

Find the files inside this installation’s `ShooterGame/Saved/Config` tree. A Windows server build running through a compatibility layer on a Linux host may still use a Windows configuration directory. Ask support to identify the active directory if several copies exist. The operating system of the physical host does not establish which directory the game reads.

## Match the option to its section

Use the official community wiki’s applicability columns and the entry for the exact option. `GameUserSettings.ini` contains sections such as `[ServerSettings]` and `[SessionSettings]`. `Game.ini` gameplay entries commonly belong beneath `[/script/shootergame.shootergamemode]`. These headings are meaningful; placing every line under the first heading does not combine their effects.

A launch argument is a separate configuration source. URL-style options and dash-prefixed arguments have different syntax. Do not paste a complete startup command into an INI file, or assume that an INI setting has a matching launch argument. If a panel exposes the same option separately, ask which source takes precedence before maintaining conflicting values.

## Make and verify one change

1. Search the complete active file for the existing key and section. Preserve unrelated entries and avoid adding a second copy of a scalar setting.
2. Change one value using the documented spelling and format. Keep the before-and-after values in your maintenance notes.
3. Start the server and read its first startup messages. Allow the map to finish loading before joining.
4. Test the relevant behaviour in game. A successful startup proves that the server runs; it does not prove the setting took effect.
5. Stop normally and inspect the active file again. If your edit disappeared, investigate generated configuration or a conflicting panel value.

## If the setting has no effect

Check the game edition, installed build, section name and active path first. Some changes affect only new events or newly generated entities, so existing objects may not demonstrate the result. Avoid wiping creatures, characters or worlds merely to test configuration. Restore the saved configuration if behaviour becomes unexpected, and send support the key, redacted section, build and test result. Remove administrator passwords and join passwords from screenshots and attachments.

Keep an annotated copy containing the reason for each change. Avoid comments that include secrets, and compare the next generated file with that baseline after updates.

## Related guides

- [Choose an ASA map and mods](https://help.cloudexa-hosting.com/books/game-hosting/page/choose-an-ark-survival-ascended-map-and-curseforge-mods)
- [Plan a consistent ASA rollback](https://help.cloudexa-hosting.com/books/survival-games/page/restore-an-ark-ascended-checkpoint-with-consistent-player-and-tribe-data)

## Further reading

- [ARK server configuration reference](https://ark.wiki.gg/wiki/Server_configuration)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Configure Project Zomboid Workshop mods for the correct build

## Match the game branch before choosing mods

Check the full server version and the players’ client branch first. Build 41 and Build 42 are different compatibility targets; a Workshop item advertising one does not necessarily provide the other. Read the item’s current description, dependencies and update notes. The same Workshop item can contain several mods or alternative versions, so its title is not enough.

Do not follow early Build 42 multiplayer instructions as a statement of current support. Multiplayer and mod handling changed throughout that release series. Use documentation and mod releases matching the installed build. Keep a record of the last working game version and mod list before introducing anything new.

## Understand the two configuration lists

The active named server configuration contains `WorkshopItems=` and `Mods=`. The former identifies numeric Steam Workshop items to download; the latter identifies the actual mods to load. A Workshop collection URL or collection ID is not a substitute for the individual required item IDs.

Use each mod author’s published Mod ID and required dependencies. Separate list entries with semicolons. Build 42 configurations may use backslash-prefixed Mod IDs; preserve the syntax produced for your exact build rather than copying a Build 41 example unchanged. Check generated settings and the author’s installation instructions together. Do not guess an ID from a display name.

## Make a small, reversible change

Stop the server after players leave and keep a complete backup of its save, account database and named configuration files. Export the current mod lists to a separate note. For mods that add maps, items or persistent systems, test on a copied save or separate test server before changing the live world.

Locate the active server configuration from startup and logs. The usual user-data directory contains a `Server` folder and files named after the server profile, but hosting can relocate it. Editing a different profile has no effect. If startup regenerates a list, update the controlling configuration rather than fighting the generated file.

## Start once and check download and loading stages

Add only the chosen mod and its required dependencies first. Start the server and watch for Workshop download completion followed by mod loading. A downloaded item is not proof that its internal mod is enabled. Note the first missing-mod, dependency or Lua error, including the item and mod identifiers involved.

Join with one test client, let it obtain the required items and check the actual feature. Reconnect after a normal save and restart. If a map mod requires a fresh world or a particular map order, stop and follow its documented migration limits; do not delete map cells or force it into an established save as a quick fix.

## Recover without damaging the world

If startup fails, return the configuration to its recorded working list. If the changed mods saved persistent data, restore the matching pre-change save and account copy as a set. Keep failed-test files for diagnosis instead of overwriting the only backup.

When asking for help, send the game build, individual Workshop links, selected Mod IDs and redacted startup errors. Never paste the whole server configuration publicly: it may contain access passwords or other sensitive settings. A short reproducible mod list is easier to diagnose than a large untested collection.

## Related guides

- [Preserve Zomboid saves across server moves](https://help.cloudexa-hosting.com/books/survival-games/page/move-a-project-zomboid-save-and-preserve-its-server-identity)
- [Back up before changing versions](https://help.cloudexa-hosting.com/books/game-hosting/page/update-paper-purpur-and-plugins-safely)

## Further reading

- [Project Zomboid dedicated-server wiki](https://pzwiki.net/wiki/Dedicated_server)
- [Server settings reference](https://pzwiki.net/wiki/Server_settings)
- [Official Build 42 release notes](https://projectzomboid.com/blog/news/2026/07/project-zomboid-build-42-20-released/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Connect to Valheim using Steam or crossplay networking

## Identify which networking backend is running

Valheim dedicated servers can use Steam networking or the crossplay backend. Check the active startup arguments and server log rather than guessing from the server name. The `-crossplay` argument selects PlayFab networking. Without it, the documented dedicated-server configuration uses the Steam backend. Players need compatible game builds and any required mods before connection tests mean much.

Crossplay is the route for supported non-Steam clients joining a dedicated server. It does not make arbitrary mod packs compatible across platforms. If an installation depends on client mods that another platform cannot load, establish a separate supported configuration before promising that those players can join.

## Use allocated ports rather than default examples

For Steam networking, Iron Gate documents a base UDP port and the next UDP port: the default example is 2456–2457. A hosted server must use ports actually allocated to it. If its configured base is different, the adjacent required port must also be allocated and reachable. Do not choose a neighbouring number that belongs to another service.

For a hosted CloudExa server, opening ports on your home router does not change the server’s network. Give support the server identifier and requested UDP allocation if the required pair is unavailable. Do not open every protocol or expose file transfer, administration or database ports to solve a game connection problem.

## Test crossplay using its public connection method

The crossplay backend uses a PlayFab relay and does not require the same inbound router-forwarding arrangement as Steam networking. It still needs working outbound networking and access to its backend services. A host may reserve game ports for its configuration even when a relay carries the player traffic; keep those assigned settings consistent.

Use the public address and configured port, the join code, or the supported server list. Iron Gate specifically warns that local and loopback addresses cannot be used to connect through the crossplay backend. A failed localhost test therefore does not prove that a public crossplay server is down. Share join codes privately with intended players.

## Separate visibility from actual reachability

The dedicated-server `-public` setting affects listing visibility. A hidden server may still accept a direct connection. First wait for the log to report its successful connection, then test with one external player. Confirm the player selected the right networking method and entered the port separately where the client requests it.

If Steam joins fail, compare the active port with the allocated UDP pair and report the exact timeout. If crossplay joins fail, record whether a fresh join code works and whether every platform fails or only one. Include timestamps and relevant log lines with secrets removed. Change one networking setting per test and retain the previous working configuration for rollback.

## Related guides

- [Troubleshoot game-server connection errors](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-common-minecraft-connection-errors)
- [Transfer an existing Valheim world safely](https://help.cloudexa-hosting.com/books/survival-games/page/transfer-a-valheim-world-without-losing-the-original)

## Further reading

- [Valheim dedicated-server networking](https://valheim.com/support/a-guide-to-dedicated-servers/)
- [Official crossplay FAQ](https://valheim.com/support/crossplay-faq/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Edit 7 Days to Die serverconfig.xml safely

## Find the configuration actually used at startup

7 Days to Die reads a server configuration selected by its launch command, commonly through `-configfile=serverconfig.xml`. The presence of a file with that name does not prove it is active. Check the startup configuration and first log lines, or ask support which visible file controls this installation. A hosting template can generate values when the server starts.

Use the sample configuration shipped with your installed game build as the reference. Online examples may describe an old Alpha release and include removed properties or omit newer ones. Keep the game version in your change notes so that a future administrator knows which defaults and comments were being followed.

## Create a reversible editing point

Let players leave, stop the server normally and download the active XML plus a full save backup. Save a separate copy named with the date outside the live configuration location. Note the current selected world and game name before touching anything, even if you only intend to change a password or player limit.

Edit one group of related settings at a time using a plain-text editor. Preserve the document’s root element and each property’s name/value structure. Avoid smart quotation marks introduced by word processors. A property inside an XML comment is not active; adding a second conflicting copy elsewhere can make troubleshooting confusing.

## Keep XML and network values valid

A typical property has the form `<property name="ServerName" value="Community Server" />`. XML special characters need escaping inside attribute values: use `&amp;` for an ampersand and `&quot;` for a quotation mark. A missing closing quote or slash can prevent the configuration from loading at all.

Use your allocated game port rather than copying a default from another server. The exact TCP/UDP ports and adjacent ports required depend on the game build and its configured networking protocols; check that build’s sample comments and the allocations supplied for the service. Do not expose the web dashboard, telnet or administration endpoints just to make normal player connections work.

## Keep the running world unchanged

`GameWorld` selects the world and `GameName` identifies the save within it. `WorldGenSeed` and world-generation size are not harmless cosmetic settings for an established game. Leave these values unchanged when adjusting access, performance or gameplay options unless you are deliberately preparing a separate world.

Also preserve any active `UserDataFolder` or save-location override. Changing the data root can make a working save appear to vanish while the files remain elsewhere. Never respond to an unexpected fresh map by deleting the old directory; stop and compare the startup values with your backup.

## Validate the result and undo only the change

Upload the edited XML while stopped and start once. Read the earliest configuration errors, then confirm the expected world and save load. Join with a test player, verify the intended setting and make sure familiar structures and player progress remain. A running process alone does not prove the right configuration was used.

If startup fails, stop and restore the saved XML. If the edit opened or generated a different world, preserve that attempt separately and restore the original selection. Give support the game build, property names changed and a redacted error excerpt. Remove server passwords and administration secrets before sharing configuration.

## Related guides

- [Keep world names and generation settings safe](https://help.cloudexa-hosting.com/books/survival-games/page/preserve-a-7-days-to-die-save-when-moving-or-changing-worlds)
- [Diagnose a game connection failure](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-common-minecraft-connection-errors)

## Further reading

- [Official server configuration reference](https://7daystodie.wiki.gg/wiki/Server%3A_serverconfig.xml)
- [Developer save-location guidance](https://support.7daystodie.com/hc/en-us/articles/48520694260628-Locating-or-moving-your-save-file)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Investigate ARK Ascended mod updates and startup conflicts

A server that stops loading after a mod update does not automatically have a damaged world. Separate download failures, game-build incompatibility, missing dependencies and actual save-load errors. Keep the live save intact while collecting evidence; repeatedly starting it with different missing content can make recovery harder.

## Capture the last working combination

Record the installed ASA build, map, ordered mod IDs, client platforms and the approximate last successful start. Save the full startup output from before the failure, not only its final line. Note whether the first error appears while downloading a mod, loading the map or admitting a player.

ASA uses CurseForge mods. Do not substitute a Survival Evolved Steam Workshop ID or apply ASE-only update flags. Check each affected project’s current page for supported platforms, required dependencies and release notes. A mod available on PC is not necessarily approved for every console. A paid mod may also have access requirements that are separate from whether its files downloaded.

## Distinguish the failure stage

1. **Download failure:** note the project ID and HTTP or storage error. Check available disk space and the provider’s status before retrying once. Do not clear the entire server directory.
2. **Server load failure:** identify the first named module, dependency or asset error. Later errors can be consequences of the first failure.
3. **Client mismatch:** compare the affected client platform and installed mod version with a player who can join. Let the normal in-game required-mod process complete.
4. **World-load failure:** preserve the save and the exact mod list. Missing structures or creatures can reflect absent mod content rather than a networking problem.

## Isolate conflicts on a copy

Arrange a separate test installation or ask support for a safe isolated test. Take a stopped backup of the live world, configuration and mod list first. A new empty test world can show whether the executable and mod combination load, but it cannot prove that an established world migrates safely.

Test suspected changes one at a time. Respect dependency and load-order requirements from the mod author. If testing removal of a content mod, use an expendable save copy and keep the original untouched. Starting and saving the live world without a content mod can remove objects that the mod supplied. Do not use uninstall-and-save as the first diagnostic step.

## Return to service deliberately

After a successful test, check joining, a representative mod feature and a normal save cycle. Confirm the next restart also succeeds before calling the incident resolved. Keep the previous checkpoint until players confirm their characters and bases are intact. A successful mod download alone does not establish that the saved world is healthy.

For support, provide the server ID, build, mod IDs, first error and test result. Redact credentials and player identifiers from public posts. If the issue belongs to one project, send the author a minimal reproduction rather than an entire private world archive.

## Related guides

- [Choose ASA maps and mods](https://help.cloudexa-hosting.com/books/game-hosting/page/choose-an-ark-survival-ascended-map-and-curseforge-mods)
- [Protect saves during an ASA rollback](https://help.cloudexa-hosting.com/books/survival-games/page/restore-an-ark-ascended-checkpoint-with-consistent-player-and-tribe-data)

## Further reading

- [CurseForge ASA mod installation](https://support.curseforge.com/support/solutions/articles/9000232983)
- [CurseForge known issues](https://support.curseforge.com/support/solutions/articles/9000196615)
- [ARK server configuration reference](https://ark.wiki.gg/wiki/Server_configuration)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Manage Project Zomboid administrators and whitelist access

## Know which account you are changing

Project Zomboid has several separate access controls: the shared server password, individual multiplayer accounts, staff access levels and whitelist rules. Changing one does not automatically configure the others. Record the installed game build and active server profile before editing access. Build 42 introduced further multiplayer changes, so check command help on your server rather than relying on an old permissions chart.

Use the player’s exact multiplayer username, including spaces and case where relevant. Their Steam display name and hosting-panel email may be different. Never make a player an administrator merely to solve a connection or whitelist error; first determine which access check is refusing the account.

## Keep an account recovery copy

Before a bulk access change, stop the server during a planned maintenance period and copy the account database with the matching named configuration and world save. Do not edit a live database file or replace it with a blank one. Keep the archive private because it contains account and player information.

For an established server, prefer its supported commands or administrator tools over direct database changes. The panel console is a privileged interface: anyone with access may be able to change accounts. Limit panel access separately from in-game staff roles and avoid sharing the owner’s credentials.

## Grant a role and verify it

Use the server’s `help` command to inspect supported syntax. In-game administrator commands normally start with a slash; a dedicated-server console generally uses the command without that slash. For example, in-game `/setaccesslevel "ExactUser" "admin"` targets that specific account. Confirm that the account exists before assigning a role.

Choose the least powerful role needed for the job. The developer’s historical role list includes admin, moderator, overseer, gm and observer, but capabilities can change between builds. Read the installed version’s help and test the intended staff action. Do not promise a moderator can or cannot perform a particular action solely from a years-old role list.

## Configure private entry without locking out players

For a closed server, review the active INI options governing open registration and automatic whitelist creation, including `Open` and `AutoCreateUserInWhiteList` where supported. A shared server password alone does not create individual accounts. Record the current settings before changing them and announce the entry process to players.

The documented `adduser` command can create a named account for whitelist access; consult local help for its arguments and supply a unique temporary password privately. Treat console and chat credentials as sensitive because they may appear in logs. Change passwords through the supported account workflow and never publish command transcripts containing them.

## Test ordinary access and retain a way back

Reconnect as the staff account and confirm the selected role. Separately test a normal allowed account and an unlisted test account so you know the whitelist actually enforces the intended policy. Verify staff access after a normal restart if configuration changes required one.

If access fails, check the active profile, username, account existence and server password before making broader changes. Revert the recorded access settings if needed; do not wipe the database or world to reset permissions. For support, include the build, redacted command response and whether the problem affects one player or every player.

## Related guides

- [Back up Zomboid accounts and world data](https://help.cloudexa-hosting.com/books/survival-games/page/move-a-project-zomboid-save-and-preserve-its-server-identity)
- [Manage game-panel access separately](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)

## Further reading

- [Project Zomboid command reference](https://pzwiki.net/wiki/Admin_commands)
- [Server options reference](https://pzwiki.net/wiki/Server_settings)
- [Developer explanation of access levels](https://theindiestone.com/forums/topic/21056-server-access-level/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Move a Project Zomboid save and preserve its server identity

## Separate a server move from a version upgrade

A location change should first reproduce the working server on the same game build and mod combination. Combining a move with a major update makes missing characters, broken mods and save conversion harder to distinguish. Record the exact source version, branch, server profile name and installed Workshop/mod lists before stopping it.

Build 41 saves and mods must not be assumed compatible with Build 42. Early Build 42 releases also had explicit save compatibility breaks. Read the release notes covering your exact source and destination versions. A destination marked “latest” is not a promise that an older world can be opened safely.

## Capture a complete stopped snapshot

Ask players to disconnect, stop the server normally and wait until it has exited. Download the complete active world-save directory, associated multiplayer/player data, the named account database and its server settings. Keep an untouched archive outside the service. Check that the download completed and that there is enough destination storage for both the imported data and a recovery copy.

Common layouts place worlds under `Saves/Multiplayer`, account databases under `db`, and named settings under `Server` within the game’s user-data root. Hosting and startup parameters can change that root. Use the source configuration and logs to identify the actual directories instead of copying the first similarly named folder.

## Preserve names and dependencies

A named server profile can have an INI file, sandbox Lua settings and spawn configuration alongside its matching database and save directories. Preserve the complete set and filename case. The public server title is different from the profile name used at launch; changing the profile can make the game select a different world and account database.

Install the matching game build and required mods on the destination before opening the copied world. Stop the destination, keep any existing destination data separately and upload the snapshot without merging unrelated saves. Do not copy only map chunks: player state, vehicles and other persistent systems need their associated data too.

## Test the copy before returning to normal play

Start the destination once and confirm the log selects the intended server profile. Join with a compatible client and verify an existing character, familiar location, stored items and world changes. Test at least one ordinary player account as well as the administrator; administrator access can hide an account or whitelist problem.

Perform a normal save, stop and restart, then reconnect. Compare results with the source snapshot. If the server displays a fresh world or new characters, stop immediately and inspect the selected profile, save-root paths and upload nesting. Do not continue playing while deciding which copy should become authoritative.

## Keep a clear rollback point

Once a newer game version writes to a save, do not assume an older binary can read it. Rollback means restoring the untouched pre-change data with its matching build, mods and configuration, rather than downgrading software over the converted copy.

Keep the source stopped while testing, and retain its data until the owner confirms the move. If a staged update is required, test each supported conversion on another copy first. Send support the versions, profile name and redacted errors; never send account databases or password-bearing configuration through a public discussion.

## Related guides

- [Match Zomboid mods to the installed build](https://help.cloudexa-hosting.com/books/survival-games/page/configure-project-zomboid-workshop-mods-for-the-correct-build)
- [Create a recoverable game-server backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Further reading

- [Project Zomboid dedicated-server wiki](https://pzwiki.net/wiki/Dedicated_server)
- [Official Build 42 compatibility warning](https://projectzomboid.com/blog/news/2024/12/build-42-unstable/)
- [Current official release notes](https://projectzomboid.com/blog/news/2026/07/project-zomboid-build-42-20-released/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Plan an ARK Ascended cluster without risking character transfers

An ARK: Survival Ascended cluster is more than two servers displaying the same name. Transfer discovery, supported map builds, shared transfer data and consistent restrictions must all agree. Plan it with support before moving a valued character; a visible destination is not proof that downloading will succeed.

## Confirm what the hosting setup supports

List the participating server IDs, maps, builds, mods and intended transfer rules. Ask CloudExa whether those installations can use a supported shared transfer-data location. Separate game-server file areas are isolated by design. This guide does not imply that the panel supplies shared storage or that customers can mount another server’s files themselves.

The configuration reference documents a common `-clusterid` and `-ClusterDirOverride` for cluster data. These are launch options, not ordinary INI entries. The exact path must be valid and accessible inside each running server’s environment. A Windows executable under a Linux compatibility layer may see paths differently from the host. Have support confirm the arrangement instead of copying a host path into every startup field.

## Keep transfer data separate from map saves

A shared cluster directory holds transfer state. It is not permission to share or merge entire map-save directories. Each map must retain its own world and related player and tribe files. File-copy jobs that overwrite one map with another can damage ownership or create inconsistent character state.

Use a distinct cluster identifier and review upload and download restrictions together. Agree whether characters, items and creatures are allowed in each direction. Check that participating releases and required mods support the intended route. A common identifier cannot convert Survival Evolved saves into Ascended saves or make missing content available.

## Run a disposable transfer test

1. Announce maintenance and take coordinated, stopped checkpoints of all participating map saves and existing transfer data.
2. Record the restrictions and relevant launch options before changing anything. Keep the checkpoint outside the shared working directory.
3. Use a disposable test character with expendable items. Verify the destination appears, the transfer completes, and the character can join and play.
4. Test the return direction independently. Check expected inventory, ownership and creature behaviour rather than assuming a successful connection proves all transfer types.
5. Only open transfers to ordinary players after documenting the supported route and recovery procedure.

## Respond to a failed transfer

Stop repeated uploads and downloads while investigating. Record source, destination, time, character identifier and the last successful step. Preserve both servers’ current saves and transfer state before another attempt. Restoring just one server while other cluster members continue accepting transfers can duplicate or lose state. Ask support to coordinate recovery across the affected maps rather than restoring a single character file at random.

Set a clear maintenance rule for the cluster: nobody transfers while a member is being restored or updated. Resume only after a second disposable test confirms the final arrangement. That rule matters as much as the initial configuration.

## Related guides

- [Coordinate an ASA backup and rollback](https://help.cloudexa-hosting.com/books/survival-games/page/restore-an-ark-ascended-checkpoint-with-consistent-player-and-tribe-data)
- [Move an ASA save safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-ark-survival-ascended-save-safely)

## Further reading

- [ARK cluster and transfer configuration](https://ark.wiki.gg/wiki/Server_configuration)
- [ARK transfer behaviour](https://ark.wiki.gg/wiki/CrossARK_Transfers)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Preserve a 7 Days to Die save when moving or changing worlds

## Distinguish the map from the saved game

A 7 Days to Die installation can store a generated map separately from the ongoing saved game that uses it. The map describes terrain and locations; the save records the particular playthrough and player progress. Copying only one side can produce a missing-world error or an apparently fresh game. Record both the selected world and the game/save name before moving data.

For random generation, the seed and size influence map creation. They are not a backup of an existing playthrough: regenerating a map from a seed does not restore buildings, containers, vehicles or characters. Generation can also change between game versions, so a seed alone is not a reliable substitute for preserving the original map files.

## Find the active data roots

The developer’s Windows guidance places user data under `%APPDATA%/7DaysToDie`, including `GeneratedWorlds` and `Saves`. Hosted Linux paths can differ, particularly where the launch command or configuration specifies a custom user-data directory. Check the active settings and log rather than treating a desktop path as the hosted destination.

Within the save data, preserve the entire relevant world/game folder and its contents, including player and region data. Include the matching generated-world folder when that map is not part of the standard server installation. If the files are outside your accessible file area, ask support to copy them; no root login is needed for ordinary hosted game administration.

## Move a stopped, consistent copy

Ask players to leave and stop the source cleanly before downloading. Keep an untouched archive of the map, save and server configuration. Record the exact game build and mods as well as total copy size. A copy made while the server writes data can mix different points in time even when the transfer finishes without errors.

Stop the destination, retain any existing destination data separately and upload the complete copy into the correct data root. Preserve folder names and case. Select the imported world through `GameWorld` and its existing saved game through `GameName`. Do not merge two worlds’ region files or rename arbitrary internal files to make the names look similar.

## Create a new world without sacrificing the old one

If you want to try another seed, use a clearly different world/save selection in a separate test instance or isolated copied data directory. Confirm storage and memory capacity first. Keep the original files and configuration offline and untouched. Do not delete the current save to force generation or reuse the only production save location for an experiment.

Before generation starts, check the installed version’s documented world names and generation settings. A typo in a world or game name may select a new playthrough instead of the intended one. Stop if logs show unexpected generation while you are trying to import an established game.

## Verify and retain rollback data

Join after the move and check a known base, game day and existing player progress. Save normally, stop, restart and reconnect to confirm persistence. Only then invite everyone back. Keep the original source stopped while testing to avoid progress diverging between copies.

For a version change, read the release notes and test a duplicate first. If conversion fails, restore the pre-change map, save, configuration and matching software as a set. Keep the failed copy for diagnosis and send support redacted logs rather than deleting evidence.

## Related guides

- [Edit 7 Days server configuration carefully](https://help.cloudexa-hosting.com/books/survival-games/page/edit-7-days-to-die-serverconfigxml-safely)
- [Keep an independent save backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Further reading

- [Developer save-location and migration guide](https://support.7daystodie.com/hc/en-us/articles/48520694260628-Locating-or-moving-your-save-file)
- [Official server property reference](https://7daystodie.wiki.gg/wiki/Server%3A_serverconfig.xml)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Protect administrator access on an ARK Ascended server

ARK administrator access can change the world, remove players and expose sensitive operational information. Give it only to trusted maintainers. The password players use to join is a different purpose from the server administrator password; sharing one credential for both makes later access control difficult.

## Start with the in-game route

Back up the active configuration and confirm the server is ARK: Survival Ascended. Set a strong, unique `ServerAdminPassword` through the supported configuration method, while the server is stopped. Do not publish that value in a server description or put it into a support screenshot. Coordinate the normal restart needed to load the change.

Join using an ordinary player account. Consult the ASA console instructions for your platform, then use `enablecheats` with the configured administrator password locally. That entry is a secret: avoid screen sharing or recording it. Verify access using a harmless supported information command before attempting moderation. Do not test access by spawning, destroying or transferring live assets.

## Confirm RCON support before enabling it

RCON instructions copied from Survival Evolved are not reliable evidence for an ASA build. The shared wiki covers both games, and not every row applies equally. Check the current ASA release and CloudExa installation support before relying on `RCONEnabled`, an assigned TCP port, or a particular client. An option appearing in an old example does not establish that the running build provides the listener.

If supported RCON is needed, ask support for a protected management path first. Traditional RCON does not provide a safe public encrypted administration channel. A game allocation is not a firewall policy. Use an approved private network or authenticated tunnel, with access restricted to maintainers; do not expose the listener to everyone simply to make a desktop client connect.

## Test the path without weakening it

1. Confirm the actual administration endpoint and transport with support. The public game address and game UDP port are not automatically the RCON endpoint.
2. Connect from the authorised management path using a maintained compatible client. Keep credentials out of command history and exported connection profiles.
3. Run a harmless information request. Confirm it reaches the intended server and does not broadcast secrets to players.
4. Test that an unauthorised network cannot use the administration endpoint. Ask support to perform this check when you cannot inspect the network policy.

## When an administrator leaves

Rotate the shared administrator password and remove their tunnel, panel and subuser access separately. A password change alone does not revoke a panel login or copied credentials elsewhere. Keep a short record of who has administration rights and why. If authentication fails, distinguish a timeout from a rejected password: the first suggests reachability or listener support, while the second suggests credential or protocol mismatch. Repeated retries and opening every port rarely resolve either safely.

## Related guides

- [Choose the correct ASA configuration section](https://help.cloudexa-hosting.com/books/survival-games/page/choose-the-correct-ark-ascended-configuration-file-and-section)
- [Diagnose ASA connection failures](https://help.cloudexa-hosting.com/books/game-hosting/page/diagnose-ark-survival-ascended-connection-failures)

## Further reading

- [ARK console commands](https://ark.wiki.gg/wiki/Console_commands)
- [ARK server configuration reference](https://ark.wiki.gg/wiki/Server_configuration)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Read Palworld crash and memory evidence before changing resources

A Palworld server disappearing does not prove it ran out of RAM. Application exceptions, container limits, host pressure, storage failures and a planned restart can all look like an abrupt disconnect to players. Collect the first useful evidence before changing resources or repeatedly starting the same failing process.

## Preserve a short incident record

Write down the disconnect time and timezone, player count, recent update or configuration changes, and whether the panel showed a normal shutdown or an unexpected stop. Save output from before the failure and the next startup. The final line alone may omit the event that caused the failure several minutes earlier.

If logs include player identifiers, addresses or access tokens, keep the full copy private. Share a redacted excerpt with the relevant timestamp. Do not post complete configuration files publicly. Ask support for host or container evidence when it is not available in your account; customers do not need host-root access to report a useful incident.

## Recognise the evidence boundaries

- **Application exception:** a crash message or call stack may identify an engine or mod failure. Start with the first error and recent changes.
- **Memory pressure:** steadily rising memory and a recorded limit event support a memory diagnosis. A displayed exit code of 137 alone is not proof of an out-of-memory kill; other forced terminations can produce similar symptoms.
- **Storage problem:** save-write errors, a full quota or insufficient temporary space can interrupt normal operation. Compare actual usage with the service limit.
- **Clean stop:** an orderly shutdown sequence suggests an action, schedule or controlled restart rather than an unexplained crash.

## Choose one safe test

Preserve a stopped checkpoint before altering a live world. If failures began after an update or mod change, record the previous combination and ask whether an isolated reproduction is possible. Never delete the world, reset player files or disable all protections as an initial troubleshooting step.

For suspected memory pressure, compare idle usage after a completed load with usage during a repeatable gameplay session. Record the peak, limit and duration. Increasing configured base or creature limits can increase load; review recent changes rather than assuming every world requires the same RAM. A restart may temporarily reduce usage but does not establish the underlying cause.

## Know when to stop retrying

If each start immediately fails at the same save-load step, stop the restart loop and keep the checkpoint intact. Repeated forced exits can add noise and risk while providing no new evidence. Give support the build, affected world, first error, timing, resource graph and last known working state.

After an agreed fix, test loading, joining, normal gameplay and a save cycle. Observe long enough to cover the original failure pattern, then check the next clean restart. Call the issue resolved only when the evidence matches the proposed cause and the server remains healthy under comparable use.

## Related guides

- [Prepare a reversible Palworld update](https://help.cloudexa-hosting.com/books/survival-games/page/update-palworld-while-preserving-a-recoverable-save-checkpoint)
- [Review Palworld settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)

## Further reading

- [Pocketpair server requirements](https://docs.palworldgame.com/getting-started/requirements/)
- [Pocketpair configuration parameters](https://docs.palworldgame.com/settings-and-operation/configuration/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Restore an ARK Ascended checkpoint with consistent player and tribe data

An ARK: Survival Ascended restore should return a coherent point in time. Replacing only the map can leave characters, tribes or transfer data from another moment. Plan the checkpoint before touching the live files, and keep a separate copy of the current state even when you believe it is broken.

## Define the recovery point

Record the affected map, approximate incident time, server build and mod list. Decide what progress will be lost and tell players before restoring. A backup timestamp describes when an archive was created; it does not prove every file inside was captured consistently. Prefer a checkpoint made after a normal save and clean stop.

Identify the actual active save directory through the file manager or support. ASA installations can have map-specific save locations, and Windows server builds under a Linux compatibility layer do not follow a universal Linux-native path. Include the map state and its associated player and tribe files. Keep configuration, startup information and the mod list with the checkpoint so recovery is reproducible.

## Stop writes before copying

1. Announce maintenance and prevent players from joining during the recovery window.
2. Request a supported normal save and stop the server gracefully. Wait until the process has exited rather than assuming a disconnected console means it stopped.
3. Download or create a named pre-recovery archive. Verify that the archive opens and contains plausible file sizes and the intended map.
4. Preserve the selected backup separately. Work from an extracted copy, keeping the original archive unchanged.

If the server belongs to a cluster, also freeze transfers and coordinate the affected members. Transfer data cannot safely be treated as unrelated temporary files. A one-map rollback while characters keep moving through the cluster can introduce losses or duplicated state.

## Validate before replacing the live checkpoint

Where possible, restore to an isolated test installation with the matching game and mod combination. Keep it inaccessible to ordinary players and disconnected from live cluster transfers. Loading an older save with newer game code can upgrade it; preserve the untouched archive before testing. Do not assume an upgraded save will load again under older binaries.

Check the map, several established characters, tribe membership, base ownership and important creatures. For a modded world, verify representative mod content. Perform a normal save, stop and second start to check that the recovered state persists. Creating a new survivor when an existing one is expected is a signal to stop and investigate, not proof the restore finished.

## Reopen and retain a fallback

Apply the validated checkpoint during maintenance and repeat the important checks. Resume cluster transfers only after support confirms consistency. Keep both the pre-recovery archive and restored checkpoint until players confirm normal operation. Record the chosen timestamp and expected lost progress so later reports can be evaluated accurately.

If restoration fails, leave both archives intact and send support the first startup error, map, build and file inventory. Do not delete player profiles, overwrite tribe files individually or run a world wipe to make the error disappear.

## Related guides

- [Plan a safe ASA cluster](https://help.cloudexa-hosting.com/books/survival-games/page/plan-an-ark-ascended-cluster-without-risking-character-transfers)
- [Move an ASA save safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-ark-survival-ascended-save-safely)

## Further reading

- [ARK dedicated-server file layout](https://ark.wiki.gg/wiki/Dedicated_server_setup)
- [ARK administrative commands](https://ark.wiki.gg/wiki/Console_commands)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Set up TShock accounts and grant limited administrator permissions

## Confirm TShock and the supported Terraria version

TShock adds accounts, groups and permissions to Terraria. Its account system is separate from your CloudExa panel login and from a shared server-join password. Confirm that the service actually runs TShock, then note the installed TShock and Terraria versions. A vanilla Terraria server will not recognise TShock account commands.

Use documentation for that release. Older TShock guides use an `/auth` setup flow, while newer releases use `/setup`. Do not mix the two or replace the server software just to match a tutorial. Read the setup instruction printed by your running server and consult its bundled command help.

## Back up accounts as well as the world

Before changing access, keep a complete stopped backup containing the world, TShock configuration, account/group database and any plugins. If this installation uses an external database, ask support for a consistent database backup alongside the files. A world file alone cannot restore accounts or group permissions.

Do not delete the TShock database or setup lock to recover an account. That can remove users and reopen initial setup. If setup is already complete but the owner account is inaccessible, use a trusted existing administrator or support-assisted recovery while retaining all current data.

## Complete first setup privately

For an unconfigured server whose startup explicitly requests `/setup`, join the server and follow that release’s displayed code workflow. Keep the one-time setup code private; it grants temporary powerful access. The exact account-registration step varies by release, so use the current prompt rather than assuming every version creates the same owner group.

The TShock `/user` command supports account management; its help documents `/user add username password group` and `/user group username group`. Replace placeholders with a unique account name, strong password and an existing appropriate group. Only an authorised administrator should run these commands. Never paste real passwords into a shared support conversation.

## Give staff only the permissions they need

Create individual staff accounts instead of sharing the owner login. Start with an ordinary group and add only the documented permission nodes needed for a task, using the installed release’s group help. Group inheritance can grant permissions indirectly, so inspect the parent group too. Avoid granting a wildcard merely to silence a single “permission denied” message.

A superadmin can bypass protections that ordinary players must follow. Keep that role for trusted owners and use narrower roles for moderation. Server-side character settings and building protections may have special bypass permissions; test them with an ordinary account because a superadmin’s success is not proof that normal access is configured correctly.

## Verify login, limits and persistence

Log out and sign in with the intended staff account, then test the specific action you granted. Also test a prohibited action and a normal player account. Check the server response for the exact command and permission rather than repeatedly broadening the role.

Complete the setup-locking step prescribed by the running release and confirm the setup code no longer grants access. After a normal restart, verify the account and group still work. Keep a private role-change record. If anything behaves unexpectedly, restore the recorded group membership or configuration rather than resetting users or replacing the world.

## Related guides

- [Upload a Terraria world and verify connection settings](https://help.cloudexa-hosting.com/books/survival-games/page/upload-a-terraria-world-and-verify-the-server-connection)
- [Control access to the hosting panel separately](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)

## Further reading

- [TShock project documentation](https://github.com/Pryaxis/TShock/wiki)
- [TShock command implementation](https://github.com/Pryaxis/TShock/blob/general-devel/TShockAPI/Commands.cs)
- [TShock permission definitions](https://github.com/Pryaxis/TShock/blob/general-devel/TShockAPI/Permissions.cs)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Transfer a Valheim world without losing the original

## Prepare the world and a recovery copy

Transfer the world separately from the Valheim program files. Before changing anything, note the source game build, whether it uses mods, the selected world name and the destination server build. Keep the original world available but offline during the move. Running both copies invites players to build progress in two different places.

Ask players to leave, stop the source normally and wait until its process has exited. Download a complete copy of the selected world data and keep an untouched copy outside the game server. Include metadata and associated files, not just the largest file. Record the copy date, total size and file count so an interrupted upload is easier to detect.

## Find the active save location

Valheim can use a custom save directory through `-savedir`. Check the running configuration before assuming a default location. On a personal Windows installation, the usual save root is `%USERPROFILE%/AppData/LocalLow/IronGate/Valheim`; use the game’s world-management controls to make a local copy if the world is stored in Steam Cloud. Do not edit synchronising cloud files while the game is open.

For builds using paired saves, retain both `WorldName.db` and `WorldName.fwl` from the same stopped save. If your installed build uses a different directory-based layout, copy its complete world dataset instead. Do not flatten folders or assume that an older two-file tutorial describes every build. Ask support to identify the destination save directory if it is outside your visible file area.

## Upload and select the existing world

Stop the destination before uploading through the file manager or SFTP. Keep any destination world in a separate backup rather than overwriting it. Upload into the active world-save location, preserving folder structure and filename case. Compare transferred sizes with the local copy and check that files are not nested inside an extra archive folder.

Set the startup world selection to the existing world identifier. Valheim’s dedicated-server argument is `-world`; this is distinct from the public server name. A spelling mismatch can create an empty world. If your hosting configuration does not expose this selection, give support the exact world identifier rather than renaming internal files experimentally.

## Verify before inviting everyone back

Start once and read the log for the selected world and successful server connection. Join with a compatible client, visit a familiar building and check terrain, containers and progression. A character inventory alone is not proof that the correct world loaded because characters and worlds are separate saves.

If the world is new or incomplete, stop immediately and compare the selected name, save root and upload structure. Preserve the failed attempt for diagnosis. Roll back using the untouched source copy and its matching game/mod versions. Keep the old server offline until the owner confirms the transferred world is correct; only then resume ordinary play.

## Related guides

- [Create and verify a game-server backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Check Valheim crossplay and connection ports](https://help.cloudexa-hosting.com/books/survival-games/page/connect-to-valheim-using-steam-or-crossplay-networking)

## Further reading

- [Valheim dedicated-server guide](https://valheim.com/support/a-guide-to-dedicated-servers/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Update Palworld while preserving a recoverable save checkpoint

A Palworld update can change both server files and the format of saved data. A safe plan preserves the state before the update and defines how success will be checked. An old executable plus a newly saved world is not automatically a usable rollback.

## Prepare a matched checkpoint

Record the current server version, client versions, startup options, active configuration and any mods. Announce a maintenance window and ask players to disconnect. Use a normal save and graceful shutdown, then wait for the process to exit before creating the checkpoint. A live file transfer can capture files from different moments.

Preserve the complete active world save and its associated player data together. Include the active configuration and a private note identifying the version and mod combination. Keep the original archive unchanged, and verify it opens and contains the expected files. A small empty archive or a backup of the wrong world identifier is not a recovery plan.

## Separate backup from rollback availability

A save backup does not guarantee that an older compatible server build or mod release remains available for installation. Confirm the available recovery options with support before scheduling a risky update. Do not promise players an instant downgrade until those prerequisites are known.

Built-in world backups can provide useful additional checkpoints, but they reside within the game’s save arrangement and consume disk space. They should not be your only copy before a version change. Keep a verified copy outside the active update target, with enough free storage for extraction and testing.

## Update once and validate deliberately

1. Use the supported update workflow for this installation. Avoid a reinstall action that replaces configuration or selects a fresh world.
2. Read the update output and confirm the new server build. Do not repeatedly launch updates while the first task is still running.
3. Start the server with the intended world identifier and configuration. Watch for conversion, missing-content or save-load errors.
4. Join with a compatible client and verify established characters, guild ownership, bases, inventory and representative mod features.
5. Perform a normal save, clean stop and second start. Confirm the checked state survives that cycle.

## If the update fails

Stop writes and preserve a separate copy of the failed updated state and logs. Keep it distinct from the original checkpoint. Do not overwrite the pre-update archive with files that have already been opened and saved by the new version.

Ask support whether recovery should use a corrected current build or a matching earlier environment. If a downgrade is appropriate, restore the corresponding pre-update save, configuration and compatible mod combination together. Loading an upgraded save with older code can be unsupported, even when the filename is unchanged.

Keep the maintenance window open until validation succeeds. Record the final version, chosen recovery point and any lost progress, then tell players what changed. Retain the original checkpoint until a normal period of play confirms that the updated world is stable.

## Related guides

- [Move a Palworld world safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-existing-palworld-world-safely)
- [Collect useful Palworld crash evidence](https://help.cloudexa-hosting.com/books/survival-games/page/read-palworld-crash-and-memory-evidence-before-changing-resources)

## Further reading

- [Pocketpair dedicated-server deployment](https://docs.palworldgame.com/getting-started/deploy-dedicated-server/)
- [Pocketpair configuration and built-in backups](https://docs.palworldgame.com/settings-and-operation/configuration/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Upload a Terraria world and verify the server connection

## Match world format and server software

Check whether the destination runs vanilla Terraria, TShock or tModLoader and record its exact supported game version. These are different software environments. A modded world may depend on companion data and installed mods; uploading its vanilla world file alone does not guarantee that mod content survives. Test a duplicate with the matching software rather than converting the only copy.

On your own computer, identify the intended world through the game’s world selection and storage settings. Steam Cloud and local storage can hold different copies. Make a local copy using the supported game controls if needed, and close the game before collecting files so synchronisation and saving are finished.

## Keep the world and recovery data together

Terraria’s main world file uses `.wld`. Preserve its corresponding backup files where available and any companion files required by your modded environment. Player character files are separate from the world; moving the world does not automatically move personal inventories or character progress. TShock server-side characters add another database-backed case that needs a separate consistent backup.

Stop the hosted server normally before changing its files. Download the existing hosted world and relevant configuration first, even if you believe it is unused. Keep the source world untouched outside the service. Compare upload size with the original and confirm that an archive extraction has not produced an extra nested directory.

## Select the imported file explicitly

Upload the complete copied dataset into the destination’s configured world location through the file manager or SFTP. Preserve the filename and case. The vanilla dedicated-server configuration supports a `world=` path selecting an existing file; hosting startup settings or TShock arguments may control that selection instead. Check the actual active startup configuration before editing a sample file.

Point selection to the uploaded world and avoid automatic new-world generation during an import. A displayed world name is not always its disk filename. If startup asks you to create a world or logs a different selection, stop and correct the path. Do not overwrite your source copy or remove the hosted backup to make the import appear cleaner.

## Use the assigned TCP game endpoint

Terraria’s documented default game port is TCP 7777, but a shared host can assign another number. Configure the server to use the TCP port allocated to your service and give players that exact address and port. Do not choose a neighbouring number or assume an example default belongs to your server.

Home-router port forwarding does not control a rented server’s network. If the assigned port cannot be reached after the game reports it is listening, send support the server identifier, endpoint and timestamp. Keep administrative interfaces and SFTP private. A DNS name alone does not remove the need to enter the correct port in the client.

## Test the world before normal play resumes

Join with a compatible client and visit a familiar structure, chest and progression landmark. Verify the expected difficulty and world size. Test an ordinary player as well as a TShock administrator because bypass permissions can hide access restrictions. Save normally, stop, restart and reconnect to confirm persistence.

If the map is wrong, stop immediately and compare the active world path, software version and uploaded filenames. Restore the previous configuration and untouched world copy when necessary. Keep any failed conversion separately; do not open it repeatedly in different server types. Invite everyone back only after the owner confirms the right world is running.

## Related guides

- [Set up TShock staff accounts safely](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Make a recoverable game-server backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Further reading

- [Official Terraria server reference](https://terraria.wiki.gg/wiki/Server)
- [Official Terraria dedicated-server guide](https://terraria.wiki.gg/wiki/Guide%3ASetting_up_a_Terraria_server)
- [TShock command-line documentation](https://github.com/Pryaxis/TShock/wiki/Command-line-parameters)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Use Palworld administration without exposing RCON publicly

Palworld administration can save or stop the world and remove players. Protect it separately from ordinary joining. Current Pocketpair documentation marks RCON as deprecated and scheduled to stop working in a future update, so a new administration setup should not depend on legacy RCON remaining available.

## Separate the two passwords

The server join password admits players; the administrator password grants privileged operations. Use different, unique values. Keep the administrator value restricted to trusted maintainers and store it in a password manager. Do not publish it in a server description, joining instructions or a screenshot of the full configuration.

Back up the active configuration before changing credentials. Stop normally, change the supported setting through the installation’s configuration method, then restart during an announced window. Make sure you edited the active file rather than the default example. Do not ask a player to send their private account password to obtain server administration.

## Verify in-game administration

Pocketpair documents `/AdminPassword` for obtaining administrator privileges after the server administrator password is configured. Enter the value privately in game using the documented command for the installed release. Avoid broadcasting it through a public chat bridge or recording the entry on stream. Test a harmless information operation before using commands that affect players or the world.

In-game access is sufficient for many occasional tasks. A separate remote-control listener is unnecessary just because an older guide includes one. Check the current command reference rather than copying a command list written for an early access release: availability and behaviour can change.

## If an automation needs remote access

Prefer the supported REST API where the installed version provides it. Pocketpair states that its administration APIs are intended for LAN use, not direct Internet exposure. Ask support to arrange an approved private network or authenticated tunnel. Do not add a publicly reachable administration port as a shortcut, and do not treat changing its port number as access control.

Inventory existing RCON tools before changing anything. Record what each tool does, who owns its credentials and whether it supports the current API. Test a replacement with read-only requests first. Keep a manual in-game administration route available during the transition. Disable the legacy listener once its consumers have migrated and support has confirmed the replacement works.

## Diagnose without opening everything

1. A timeout suggests the management route or listener is unavailable; verify the protected path with support.
2. An authentication rejection suggests credentials or client configuration; rotate exposed secrets rather than posting them.
3. A command failure after authentication may reflect changed command support. Check the installed release and current documentation.
4. Confirm the response identifies the intended server before saving, kicking or shutting anything down.

When a maintainer leaves, revoke their panel access and private-network access as well as rotating shared administration credentials. Review automation secrets separately. Keep a short access list so future password changes do not silently break an unknown monitoring job.

## Related guides

- [Use a private Palworld REST connection](https://help.cloudexa-hosting.com/books/survival-games/page/use-palworld-rest-administration-through-a-private-connection)
- [Edit Palworld settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)

## Further reading

- [Pocketpair administration commands](https://docs.palworldgame.com/settings-and-operation/commands/)
- [Pocketpair RCON deprecation notice](https://docs.palworldgame.com/api/rcon/)
- [Pocketpair REST API introduction](https://docs.palworldgame.com/api/rest-api/palwold-rest-api/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Use Palworld REST administration through a private connection

Palworld provides an official REST administration API, but Pocketpair explicitly advises against exposing it directly to the Internet. It can perform powerful operations. Plan a protected connection and the smallest required set of actions before attaching a dashboard, bot or monitoring service.

## Confirm support and the management route

Check the API documentation for the installed server release. The current introduction documents enabling REST access and HTTP Basic authentication. Authentication does not itself encrypt traffic or provide per-action permissions. A password-protected public HTTP endpoint can still expose credentials and administrator operations.

Ask support whether this service has an approved private network, authenticated tunnel or restricted management gateway. The game’s public address is not an instruction to publish the REST listener there. An extra panel allocation does not establish network restrictions. Enable the feature only after the protected route is confirmed, and coordinate any required restart.

## Begin with server information

Use the documented read-only `GET /info` operation through the approved route. Confirm the API base path, local forwarding address and authentication details for your installation rather than copying a localhost example onto an unrelated machine. Localhost always refers to the machine making the request.

Use a trusted client that prompts for credentials or reads them from an appropriately protected secret store. Keep passwords out of URLs, shell history, screenshots and exported request collections. Verify the returned server identity and version before testing any write operation. A successful HTTP response from the wrong service is not a successful administration test.

## Limit what an integration can do

Decide whether the integration truly needs player lists, settings, saving or shutdown. These have different consequences and privacy impact. Do not give an untrusted browser widget unrestricted administrator credentials. The settings response can reveal operational information, and player responses may contain identifiers that should not appear in public status pages.

Do not assume the native API supplies scoped tokens or separate read-only roles unless the installed release documents them. If an integration needs only health information, ask support for a restricted gateway that permits the specific read-only path and method. Keep the administrator secret server-side, restrict callers and use encrypted transport. A route allowlist must not accidentally include shutdown, kick or other state-changing endpoints.

## Test failures and ongoing use

1. Verify an approved request succeeds from the authorised path.
2. Verify missing or incorrect credentials fail without disclosing secrets.
3. Have support confirm the native listener is unreachable from unauthorised public networks.
4. Use a conservative polling interval and back off after repeated failures. Avoid loops that overload a struggling server.
5. Log the time, operation and result without logging the authentication header or complete sensitive responses.

Revoke access when the integration is removed, and rotate credentials after accidental disclosure. For troubleshooting, distinguish a route timeout, an authentication rejection and an unsupported endpoint. Keep the server ID, installed version and redacted response; do not post the administrator password to prove that authentication was configured.

## Related guides

- [Protect Palworld administrator access](https://help.cloudexa-hosting.com/books/survival-games/page/use-palworld-administration-without-exposing-rcon-publicly)
- [Interpret Palworld health evidence](https://help.cloudexa-hosting.com/books/survival-games/page/read-palworld-crash-and-memory-evidence-before-changing-resources)

## Further reading

- [Pocketpair REST API introduction](https://docs.palworldgame.com/api/rest-api/palwold-rest-api/)
- [Pocketpair server information endpoint](https://docs.palworldgame.com/api/rest-api/info/)
- [Pocketpair settings endpoint](https://docs.palworldgame.com/api/rest-api/settings/)

Looking for another game? [Browse game server setup and troubleshooting guides](https://help.cloudexa-hosting.com/books/game-hosting/page/find-setup-and-troubleshooting-guides-for-your-game-server).

# Set Valheim world modifiers without changing the world

Use world modifiers to change the rules of your existing Valheim world without choosing a new world name. You need access to the server’s startup settings and a planned restart. This guide covers the options in Iron Gate’s dedicated-server manual; check that your installed build and CloudExa startup template expose them before editing anything.

## Record the current rules

Open the game panel and record the world identifier, game version, existing startup arguments and any preset or modifier fields. Save a copy of the current startup configuration outside the panel. Keep the existing world name and save location unchanged throughout this procedure.

Tell players which rule you intend to change. A resource multiplier can affect the economy of a long-running community, even when you preserve the buildings. Agree a short test window and decide whether progress made during that window will count.

## Apply one deliberate configuration

1. Ask players to leave, stop the server through the panel and wait for the stopped state. Take a completed backup before editing startup settings.
2. Use the panel’s modifier fields if your template provides them. If it exposes an additional-arguments field, confirm with support that the field accepts these dedicated-server options.
3. For a defined baseline, choose a supported preset such as `-preset Normal`. A preset overwrites earlier modifier choices, so record any existing custom rules first.
4. Place individual modifiers after the preset. For example, `-preset Normal -modifier raids none` selects the normal baseline and then disables raids. This is an illustrative policy, not a recommendation for every community.
5. Save the configuration and start the server. Read the startup log before inviting players back.

## Check the result in the right place

Connect to the existing world and check familiar terrain and structures. Confirm the intended world rules through the game’s available world information or an administrator’s supported inspection method. Do not wait for a random raid as your only check: an absence of raids over a few minutes proves little.

If the panel appears to ignore a setting, compare the saved field with the effective startup configuration. A template can insert another preset later in the command. Send support the modifier arguments and a redacted startup excerpt if you cannot see the final command. Keep server passwords out of screenshots.

## Revert rules without restoring the whole world

If players dislike the change, stop the server and restore the previous startup arguments. Restart and check the rules again. Restoring arguments keeps the progress made during the test; restoring a world backup also rewinds that progress. Choose between those outcomes with the group before performing a restore.

Do not invent a value because a similarly named option exists in a mod. Use Iron Gate’s supported modifier names and values for the installed build. Test mod-provided rules separately so you can identify which component changed the behaviour.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Preserve a Valheim world during a transfer](https://help.cloudexa-hosting.com/books/survival-games/page/transfer-a-valheim-world-without-losing-the-original)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Valheim dedicated-server options](https://valheim.com/support/a-guide-to-dedicated-servers/)

# Tune Valheim automatic world backups and save intervals

Valheim has its own world-save and automatic-backup settings in addition to the backups you create in the CloudExa panel. Use this guide to choose native retention and check that the expected files appear. You need startup-setting access, visibility of the configured save directory and enough disk space to retain the copies.

## Understand the two schedules

Iron Gate documents `-saveinterval` in seconds and separate automatic-backup options: `-backups`, `-backupshort` and `-backuplong`. The backup count covers a short-interval copy and subsequent long-interval copies. These settings control Valheim’s native files; they do not change your panel backup allowance.

Record the current values before changing them. Also record the active world name and save-directory override, if present. A correct interval with the wrong directory in view can look like a failed backup, so find the files the running instance actually updates.

## Choose a retention budget

1. Inspect the size of the current world files and existing native backup files in the file manager. Leave space for growth and temporary writes.
2. Decide how much recent progress the group can accept losing. Choose a save interval with that aim, while leaving room for the server to finish each save.
3. Pick short and long backup intervals for the periods you want to cover. For example, a short copy can help with a recent mistake while longer-spaced copies cover an older problem.
4. Schedule a restart, stop the server and preserve the current world with a completed independent backup.
5. Edit only the native backup fields or supported startup arguments. Keep their units in seconds and retain the same world and save directory.
6. Start the server and check for parsing, write or storage errors.

## Verify files over time

Record a timestamp after a normal save, then inspect the world directory after the selected intervals have elapsed. Check both names and modification times. A file that predates your change does not prove the new schedule ran. Expect the retention pattern to develop over time rather than appear as a full history at the first startup.

Download one completed native backup for inspection, keeping its paired world metadata where applicable. Do not rename a running world’s files to test restoration. Use a separate test environment if you want to prove that a copy loads.

## Keep a separate recovery path

Native copies share the server’s storage and quota. They help with a bad in-game event but do not replace an independent backup of the service. Keep a panel backup or downloaded copy before a major update and check the backup job’s completion status.

If disk use rises faster than expected, revert to the recorded retention settings and inspect the actual backup sizes. Download any recovery points you need before deleting surplus copies. Ask support to check unexplained growth rather than removing files whose role you cannot identify. Never delete the active world to make room for its backups.

## Related CloudExa help

- [Schedule backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Investigate a full game-server disk](https://help.cloudexa-hosting.com/books/game-hosting/page/investigate-and-recover-from-a-full-game-server-disk)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [Valheim save and backup arguments](https://valheim.com/support/a-guide-to-dedicated-servers/)

# Find which Project Zomboid sandbox profile your server actually loads

If a Project Zomboid sandbox change disappears after a restart, first identify the profile the server loads. Editing a convincing-looking file with the wrong prefix will not affect the active instance. You need file-manager access and startup logs; this procedure does not require deleting the world or changing its identity.

## Establish the build and profile

Record the complete server build and the client build, including the selected Steam branch. Build 41 and Build 42 installations can expose different settings and behaviour. Do not paste an entire sandbox file from a guide written for another build. The old official multiplayer FAQ establishes the profile naming pattern, but its historical examples are not a current list of valid settings.

1. Open the game panel’s startup settings and find the server-profile name, if exposed. Record it exactly, including capitalisation.
2. Read the beginning of a recent startup log for the profile or configuration paths. Ask support to identify the effective profile argument if your template hides it.
3. Locate the matching profile files. The sandbox file follows the `PROFILE_SandboxVars.lua` naming pattern; use the prefix reported by your instance.
4. Download the existing sandbox file and the matching server settings file. Keep their names in your notes so a later restore uses the same profile.

## Change one supported setting

Before testing, ask players to leave, stop the instance and take a completed backup. Use the configuration generated by your installed build as the starting point. If you need the game’s settings editor to generate a reference, use a separate local test profile on the same build and compare only the relevant setting.

Edit one setting you can observe without destroying progress. Preserve Lua syntax, including commas, quotation marks and the enclosing table. Keep a copy of the exact original line. Do not change the profile name, world identifiers or mod lists as part of this test.

Start the server and check for Lua parsing errors. Reopen the file after startup to see whether a panel template or another configuration process rewrote it. If the value changed back, investigate that writer before making repeated manual edits.

## Distinguish an ignored setting from existing-world behaviour

Check the effect in the place and circumstances the option controls. A world-generation rule may affect newly created content rather than rewriting an existing map. Read that setting’s description in your installed build before using old terrain as proof that it failed.

If the file remains correct but behaviour differs, test the same setting in a separate, unmodded profile on the identical build. Keep the production save untouched. Capture the expected outcome, actual outcome, build, profile prefix and relevant log section for support.

## Undo the test

Stop the server and restore the recorded line if the change was unsuitable. Restart and confirm the previous rule. A configuration rollback preserves current world progress; restoring the full backup rewinds it. Treat those as separate decisions, particularly when players returned during testing.

## Related CloudExa help

- [Preserve a Project Zomboid server identity](https://help.cloudexa-hosting.com/books/survival-games/page/move-a-project-zomboid-save-and-preserve-its-server-identity)
- [Match Project Zomboid Workshop mods to the build](https://help.cloudexa-hosting.com/books/survival-games/page/configure-project-zomboid-workshop-mods-for-the-correct-build)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [The Indie Stone multiplayer FAQ and SandboxVars naming](https://theindiestone.com/forums/topic/6016-multiplayer-faq/)

# Protect a TShock spawn with a bounded region

Use a TShock region to protect a defined spawn area while leaving the rest of the world available for building. This guide requires TShock, an account with region-management permission and an existing world backup. Native Terraria without TShock does not provide these commands.

## Plan a small boundary

Walk around the spawn and decide which tiles need protection. Include the actual entrance, floor and walls, but avoid enclosing an unrelated player base. Write down a unique region name such as `spawn_lobby` and keep a screenshot or coordinates showing the intended corners.

Check your installed TShock version and run `/region help`. The official documentation includes older examples; the installed command help is your reference if a subcommand differs. Region-management commands affect access rules, so use a maintenance window if players are building nearby.

## Create and protect the rectangle

1. Run `/region clear` to discard any unfinished corner selection.
2. Run `/region set 1` and touch or edit the tile at the first intended corner using the selection method supported by TShock.
3. Run `/region set 2` and select the diagonally opposite corner. Check the vertical extent as well as the width.
4. Run `/region define spawn_lobby` using your chosen name.
5. Run `/region protect spawn_lobby true` and inspect `/region info spawn_lobby`.
6. If a named builder needs access, use `/region allow PLAYER spawn_lobby` with their TShock account name. Do not grant a broad bypass permission just to edit this area.

## Verify with a normal player

Use an ordinary account without administrator or region-bypass permissions. Try one harmless tile edit inside the boundary, one outside and one at each edge. Restore the outside test tile afterward. An administrator’s successful edit cannot prove that visitors have the same access.

Test the named builder separately. They should have the intended access within the region, while an unlisted normal account should remain restricted. Check doors and any protected interaction your community depends on; a tile-build test alone does not establish every interaction rule.

## Correct mistakes without exposing the spawn

If the rectangle is wrong, inspect its recorded dimensions before changing it. Use the installed help for region expansion or contraction and adjust one edge at a time. Keep protection enabled while you refine the boundary, then repeat the ordinary-account checks.

Remove temporary builder access with `/region remove PLAYER spawn_lobby` after the work ends. Record the final region name and authorised accounts in your staff notes. If a player can still build where you expect a restriction, check overlapping regions and their group permissions before blaming the world file.

For a larger redesign, keep the current region until you have planned its replacement. Deleting all regions or disabling global protection as a troubleshooting shortcut can expose areas unrelated to spawn. Share the specific region information with support if you cannot explain the access result.

## Related CloudExa help

- [Set up TShock accounts and limited administrator permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Invite a teammate to your game server](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)

## Official references

- [TShock basic region management](https://tshock.readme.io/docs/basic-region-management)
- [TShock advanced region management](https://tshock.readme.io/docs/advanced-region-management)

# Resolve overlapping TShock regions without removing protection

A player can have unexpected building access where two TShock regions overlap. Diagnose the region selection and its access list before removing protection. You need region-management permission and a normal test account; keep a backup of the world and TShock data before changing an established layout.

## Capture one reproducible location

Choose one tile where the result differs from your expectation. Record the player account, group, coordinates and attempted action. Compare that with a nearby tile that behaves correctly. This keeps the investigation focused on a boundary rather than an entire world.

Run `/region list` and inspect likely regions with `/region info NAME`. Save the region names, dimensions, allowed users and allowed groups before editing. A region named after an old building can still cover the test tile, so inspect its coordinates rather than trusting its name.

## Find the active overlap

1. Run `/region name` and use the tile-interaction method described by the installed command help at the affected location.
2. Where supported, use the `-u` and `-z` inspection flags to include unprotected regions and inspect z-index information.
3. Compare the boundaries of the regions covering that tile. The TShock documentation states that a smaller z-index takes precedence over a larger one.
4. Check whether the affected player belongs to an allowed group or has a protection-bypass permission. A SuperAdmin account makes a poor test subject.
5. Write the intended policy in plain language, for example: visitors cannot edit the lobby, while the builders group may edit the workshop inside it.

## Make a narrow correction

Choose whether the inner or outer region should take precedence. Record the old z-index, then use `/region z NAME NUMBER` with the planned value. Avoid assigning matching values and assuming an undocumented tie-break rule. Make one change and repeat the same tile test.

If the mistake is an oversized rectangle, use the installed region expansion or contraction command to adjust the relevant edge instead. Preserve the original dimensions in your notes. Do not change both geometry and precedence at the same time; you would lose a clear explanation of the result.

## Verify the neighbouring areas

Test the problem tile, each side of the overlap and a tile outside both regions. Use the normal account first, then an account that should have explicit access. Record each result. Check a second protected building as a quick guard against accidentally changing a shared group permission.

If the edit does not produce the intended result, restore the old z-index or boundary and inspect permissions again. Do not delete regions one by one until access changes. That approach can leave a protection gap while giving you incomplete evidence.

After a successful change, save staff notes with the region names and intended precedence. Remove any temporary test access. If support needs to investigate, send the region inspection output and a redacted screenshot of the affected area rather than a full database containing account information.

## Related CloudExa help

- [Set up TShock accounts and limited administrator permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [TShock overlap, region inspection and z-index commands](https://tshock.readme.io/docs/advanced-region-management)

# Trial TShock server-side characters without risking player inventories

TShock server-side characters, or SSC, give the server control over character progress for that community. Enabling SSC changes what players bring into a session. Trial it in an isolated copy before deciding how an established group will move, especially if members have valuable inventories.

## Define what the trial should prove

The TShock documentation explains that players start with fresh server-side characters and that their separate single-player characters remain unaffected. That does not mean you can switch a live community back and forth without planning. Decide whether your future server should require fresh progression or use an explicit, reviewed migration process.

You need a separate test instance with its own world copy and TShock data, plus permission to create that test instance. If your plan has no spare server, ask support for an isolated test route. Do not overwrite the production world or use the production account database as a shared writable database.

## Prepare the isolated copy

1. Stop the source during a planned window and take a completed backup covering the world and TShock data. Keep that recovery point unchanged.
2. Have the test copy use its own assigned connection details and storage. Confirm that the source service remains distinct before starting it.
3. Open the test copy’s generated `tshock/sscconfig.json`. Match the path to your template if the working directory differs.
4. Record the current file and change the existing `Enabled` field to `true`. Preserve JSON syntax and leave unrelated settings alone.
5. Start the test service and check for configuration or database errors.

## Use an ordinary account for the inventory check

Join with a disposable test character and a normal TShock account. Note its starting inventory, health and mana. Make a small, recognisable amount of progress, leave and reconnect, then restart the test server and reconnect again. Record whether the same server-side state returns.

SuperAdmin can bypass SSC through `tshock.ignore.ssc`, so testing only with that account can give the wrong impression. Use a normal account for proof rather than changing a powerful staff group just for this exercise. Keep the trial’s credentials private.

Check the character-save interval against your installed configuration. A world save and a character-data save are different recovery concerns. Your planned backup must cover the data your installation actually uses, including an external database if you configured one.

## Make the production decision separately

Record the test version, starting rules, reconnect result and restart result. Explain to players what will happen to their inventory on the SSC server before scheduling a live change. Do not promise an automatic import unless you have verified a supported process for your exact TShock version.

For a failed trial, stop the test instance and retain the logs. The source server should need no rollback because you did not change it. If you later enable SSC in production, take another recovery point and agree how you will handle progress made after that cutover. A full restore can rewind both the world and player data.

## Related CloudExa help

- [Set up TShock accounts and limited administrator permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [TShock server-side character configuration](https://tshock.readme.io/docs/server-side-character-config)

# Keep the TShock REST API disabled unless you need it

TShock’s REST API lets external programs interact with the server. A normal Terraria player does not need it to join. If you have no approved integration using that interface, leave it disabled and avoid exposing another management path.

## Check whether anything depends on it

Open the game panel and record the installed TShock version. Download the generated TShock configuration as a private recovery copy. Configuration can contain credentials and tokens, so do not attach the full file to a public Discord message or publish it in a guide.

Ask whoever manages your website, bots or statistics tools whether they call TShock REST. Write down the integration name and the person responsible. A tool that reads a console log may not use REST at all. Confirm the dependency rather than enabling the API for a vague requirement.

The upstream REST documentation warns that parts of its endpoint list are old. Use the generated configuration and your installed version as the authority for supported fields. This guide disables an unneeded interface; it does not provide a public API deployment recipe.

## Disable the listener

1. Choose a short maintenance window, notify players and stop the game server through the panel.
2. Find the generated TShock `config.json`, keeping it distinct from Terraria’s own configuration file.
3. Locate `RestApiEnabled`. If the existing field is `true` and no approved integration needs it, change it to `false`.
4. Preserve the other fields, commas and data types. Do not insert the same key twice.
5. Start the game server and inspect its startup log for configuration errors and REST-listener messages.

## Verify both access paths

Join Terraria through the game address and port allocated to your service. Confirm ordinary gameplay and staff login still work. Disabling REST should not require changing the game’s assigned port or editing the host firewall.

If you have an authorised way to test the former REST address from outside, confirm that it no longer serves the API. A timeout by itself cannot identify whether TShock stopped listening or a network rule blocked it. Ask support to verify the process listener if the panel’s logs do not make that clear.

## Handle old integrations and secrets

Update your staff notes so a later plugin setup does not re-enable the API without review. Check automation for saved REST credentials or application tokens. Remove unused secrets from those tools using their supported settings, and rotate any token you exposed in a ticket or screenshot.

If an approved integration breaks, keep the recorded configuration and error message. Re-enable the listener only after reviewing its authentication, permissions and restricted network path with support. Do not open a guessed port to the whole Internet as a quick test.

A working token can grant powerful actions depending on its account group. Restrict that group to the integration’s required actions. Keeping a spare SuperAdmin token for convenience increases the impact of a leak and makes later access reviews harder.

## Related CloudExa help

- [Keep your CloudExa account secure](https://help.cloudexa-hosting.com/books/billing-support/page/keep-your-cloudexa-account-secure)
- [Set up TShock accounts and limited administrator permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [TShock REST setup and token cautions](https://tshock.readme.io/reference/rest-api-endpoints)

# Block a specific item with TShock item bans

Use a TShock item ban when your server rules prohibit a specific Terraria item. Item bans offer a narrower control than removing a player’s building permissions. This guide covers TShock’s built-in commands; plugins can add separate restrictions, so record which system owns the rule.

## Agree the item and intended exception

You need an account with the `tshock.admin.itemban` permission and a backup before changing an established ruleset. Record the exact item name as recognised by the installed Terraria and TShock versions. Similar names or translated display names can identify the wrong item, so verify the command’s response.

Tell players what the rule means before enabling it. The upstream documentation describes an item ban as restricting use or bringing the item into the server. Do not treat it as a promise that every interaction or plugin-created item will behave the same way on every release.

## Add a narrow rule

1. Run `/itemban list` and save the current list. Check whether the item already has a rule.
2. Use the installed command help to confirm syntax for your release.
3. For an illustrative ban, run `/itemban add "Dynamite"`. Replace that item only after deciding your community’s actual rule.
4. Read the response and list the bans again. Stop if the command selected an unexpected item.
5. If a specific staff group needs the item for an approved task, use `/itemban allow "Dynamite" GROUP` with the existing, limited group name.

## Test the two account types

Use a normal test account without item-ban bypass permissions. Test the prohibited action in a disposable area or isolated world so a successful action cannot damage a player build. Keep valuable inventories out of this test. Record the exact message and result rather than assuming the absence of a kick means unrestricted access.

Then test the group exception with an account in that group. Confirm that the exception applies to the chosen item while another normal account remains restricted. An administrator with broad bypass privileges cannot establish whether your limited group rule works.

## Remove an exception or reverse the policy

Use `/itemban disallow "Dynamite" GROUP` to remove that group’s exception. Use `/itemban del "Dynamite"` to remove the item ban itself. Those actions solve different problems: removing an exception preserves the wider rule, while deleting the ban permits the item under other applicable rules.

Keep the original list and note the date, reason and approving staff member. If the ban behaves inconsistently, inspect the affected account’s groups and installed plugins before adding broader restrictions. Do not grant SuperAdmin as a workaround.

After a planned restart, repeat the list check and a safe normal-account test to confirm your installation retained the rule. Report version numbers, the command response and the specific observed behaviour to support if persistence differs from your expectation. Leave account passwords and database contents out of the report.

## Related CloudExa help

- [Set up TShock accounts and limited administrator permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [TShock item-ban subcommands and group exceptions](https://tshock.readme.io/docs/group-item-bans)

# Enable a Factorio whitelist without locking out your group

A Factorio whitelist controls which named players can join your factory. Set it up from a management session you can recover through the game panel, then test both an allowed account and an unlisted account. Hiding a server from the public browser alone does not provide the same restriction.

## Keep a recovery route open

You need access to your own game panel console and permission to change the server’s configuration. Record the exact Factorio usernames your group uses. Do not substitute their billing email addresses or Steam display names without checking the identity the game reports.

Save a private copy of your current server settings and whitelist. Note any startup options that select an alternative whitelist path or explicitly enable whitelist use. Factorio exposes separate `--server-whitelist` and `--use-server-whitelist` options; a template may manage them for you.

## Populate the list before enforcing the policy

1. Check the installed command syntax with the game’s help and inspect the existing list using `/whitelist get`.
2. Add your own known game identity with `/whitelist add PLAYER`, replacing the placeholder with the exact username.
3. Add one trusted tester and the remaining approved players. Inspect the list again for spelling errors.
4. Check the template’s whitelist enable setting. Where the panel exposes a corresponding switch, save the intended enabled state. Ask support to inspect hidden startup options if necessary.
5. Keep the panel console available while the tester reconnects. Do not close your only management session before the access test.

## Verify admission and rejection

Ask the listed tester to leave and rejoin through the allocated game address. Confirm that the server accepts them and that the log reports the expected identity. Then use an authorised unlisted test account to check rejection. A successful test needs both results.

An empty list is a special case: the upstream console documentation says an empty whitelist disables whitelist functionality. Do not clear the list as a way to lock everybody out. Use the panel’s maintenance controls if you need to keep the game unavailable during work.

If an unlisted account still joins, inspect the effective enable setting, selected file and any account-specific bypass behaviour in your installed version. Do not assume a saved JSON file proves that the running process loaded it.

## Recover and maintain the list

If a legitimate player cannot join, check their exact game username before changing the overall policy. Add the missing identity from the panel console and have them retry. Restore the recorded configuration if your template change prevents startup.

After a planned restart, inspect the list and repeat the allowed-account check. Keep a small staff record of who approved each addition. Remove departed members by name using `/whitelist remove PLAYER`, leaving the other entries intact. For a public event, decide how you will admit guests before advertising the address rather than disabling access controls in a rush.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Keep your CloudExa account secure](https://help.cloudexa-hosting.com/books/billing-support/page/keep-your-cloudexa-account-secure)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio whitelist commands](https://wiki.factorio.com/Console)
- [Factorio whitelist startup options](https://wiki.factorio.com/Command_line_parameters)

# Choose Factorio autosave and empty-server pause behaviour

Factorio’s autosave interval and empty-server pause policy solve different problems. Autosaves create recovery points during play; the empty-server rule determines whether the factory continues running when nobody is connected. Choose both around how your group plays, then verify the actual server configuration.

## Find the active settings

You need ownership or administrator access to the Factorio service. Record the installed version, current save name and the server-settings file selected by the startup template. If several JSON files exist, use the startup configuration to identify the active one.

Read the example settings shipped with your installed Factorio version before editing. The historical release notes document the `autosave_interval`, `autosave_slots` and `auto_pause` fields, but defaults and available options can change. Keep the generated example as your version-specific reference.

## Choose the policy

1. Ask the group whether unattended factory progress is desirable. Consider resource depletion and production goals before deciding whether to pause while empty.
2. Choose an autosave interval that limits acceptable lost progress. Factorio’s console configuration documentation gives the autosave interval in minutes.
3. Choose the number of retained autosave slots using your installed settings example. Leave room for the current save, rotating autosaves and a separate backup.
4. Record the existing settings and take a completed backup before changing the policy.
5. Use the supported administrator configuration interface for live settings, or stop the server and edit the active JSON file. Preserve booleans as booleans and numeric values as numbers.

## Test saves and empty-server behaviour separately

Start the server and check for JSON or startup errors. During an ordinary session, note the time and wait through the configured autosave interval. Inspect the log and resulting save timestamps. Wait long enough to observe rotation before assuming that the slot limit works as intended.

For the empty-server test, record a recognisable factory state or game-time observation. Ask all players to leave, allow a short agreed interval and reconnect. Check the progression that your chosen pause policy predicts. Keep a staff observer out of the server during the empty period; their connection would invalidate that test.

If the outcome differs, check whether a scenario, mod or startup template overrides the behaviour. Restore one original value at a time rather than changing save timing and pause rules together again.

## Keep independent recovery points

Autosaves rotate. They can replace an older good state after a mistake goes unnoticed, and they share the service’s storage. Maintain an independent panel backup or downloaded copy before major work. Do not treat a short autosave interval as protection against every kind of loss.

For a large factory with noticeable save pauses, record when the pause happens and share the save size and timestamps with support. Increasing the interval can reduce how often you notice a pause, but it also increases the progress at risk between saves. Make that trade with your players rather than disabling saves.

## Related CloudExa help

- [Schedule backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Investigate a full game-server disk](https://help.cloudexa-hosting.com/books/game-hosting/page/investigate-and-recover-from-a-full-game-server-disk)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [Factorio configuration commands and interval units](https://wiki.factorio.com/Console)
- [Historical introduction of server-settings save and pause fields](https://wiki.factorio.com/Version_history/0.14.0)
- [Selecting the active server-settings file](https://wiki.factorio.com/Command_line_parameters)

# Resolve Factorio mod and startup-setting mismatches

A Factorio client can have the right mod names and still fail to match the server. Compare the exact versions and startup settings before replacing files. This guide covers a mismatch when joining an existing factory, with the aim of preserving its save and agreed mod set.

## Capture the mismatch first

Record the full game version on the client and server. Save the join error and the first relevant server-log message. Make a list of enabled mods with their versions, including the expansion-related components your game uses. A name-only list misses the information needed to reproduce the session.

Download a recovery copy of the current save and mod configuration before changing the server. Treat a mod migration as a change to the factory: removing a content mod can affect entities or recipes when the save loads. Do not accept an automatic server-side change simply because one client has a different collection installed.

## Synchronise the client to the agreed server

1. Confirm that the server’s current mod set is the intended one. If the whole group lost access after maintenance, inspect the server change first.
2. Use Factorio’s offered multiplayer mod synchronisation when joining. The upstream modding guide explains that it selects the server’s exact mod versions and can synchronise startup settings.
3. Allow the client to complete any required game restart. Recheck the enabled set before reconnecting.
4. If a download fails, verify account access to the official mod portal and the named mod version. Do not fetch an executable or altered ZIP from an unrelated download site.
5. Compare the next error with the original. A resolved mod mismatch can reveal a separate game-version or authentication issue.

## Investigate a server-side mismatch

If startup logs report missing dependencies or incompatible mods, stop the instance and compare the installed files with the recorded configuration. Look for a partial upload, duplicate version files or a template that updated the game but retained an older mod set.

Keep the official mod ZIP files in the form expected by Factorio. Do not unpack and edit a mod to force it to accept another version. Local modifications can change checksums even when the visible mod version remains the same.

For a planned change to startup settings, test a copy of the save with the exact proposed mod set and game version first. Use that copy to check whether the factory loads, key production chains remain present and a second client can join.

## Recover without mixing states

If the proposed set fails, restore the saved mod configuration and compatible save as a matched pair. Avoid loading a save already migrated by a newer mod set with older files and assuming it will reverse those changes.

Send support the exact game version, mod names and versions, mismatch text and a redacted startup excerpt if you remain blocked. Keep portal tokens and account credentials private. Tell the group which combination is the approved baseline so another client update does not restart the same investigation.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Fix a console that will not connect](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-a-game-console-that-will-not-connect-or-shows-a-504-error)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio mod dependencies and multiplayer synchronisation](https://wiki.factorio.com/Modding)

# Preview a Factorio map before starting a new factory

Choose a Factorio map in the local game’s map-generation screen before scheduling a new season on your hosted server. A preview lets the group review its starting area without replacing the live factory. You need a matching local game version and the same content and mods planned for the server.

## Keep the current factory out of the experiment

Record the live save name and startup selection, then leave them unchanged while you compare candidates. Create local test saves with distinct names such as `season_candidate_a`. Do not reuse the production filename or upload over the existing archive.

Agree what matters to the group: starting resources, water access, terrain or enemy pressure. A larger resource setting can change the intended challenge. Write a short candidate checklist instead of adjusting sliders until the preview merely looks attractive.

## Generate and record a candidate

1. Open a new game in the same Factorio version and intended mod set. Confirm which expansion content you have enabled.
2. Choose a preset and inspect its settings before changing individual values. In Space Age, the official map-generator documentation notes that presets affect Nauvis.
3. Enter a candidate seed or generate one. Use the preview controls to inspect the starting area and nearby resources.
4. Record the seed and export the map exchange string. Keep the entire string, including its enclosing markers.
5. Create a separate local save and play a short sample with the group’s intended settings. Check for an overlooked starting constraint that the overview did not reveal.

## Understand what the string preserves

A map exchange string describes map-generation settings. It does not carry your factory’s buildings, player inventories or completed research. Sharing that string is useful for comparing a fresh map, but it is not a substitute for the actual save archive when preserving progress.

Keep the game version, enabled content and mod list beside the string. A seed number on its own is a poor record of a modded candidate. Avoid promising that a future release will reproduce the same terrain from an old note without checking it.

## Approve the candidate before cutover

Ask another group member to import the recorded exchange string into a matching local installation and compare the preview. Confirm that they obtain the intended candidate. Have players review the short sample save if starting conditions are important to the season.

Only after approval should you plan the hosted-server change. Take a completed backup of the existing factory, keep its original save archive and agree a rollback window. Use a distinct new save name and have support confirm the template’s selection process if the panel does not expose it.

If the candidate disappoints, discard that local experiment and create another. The existing service needs no rollback because you did not change it. Retain the approved string and settings with your season notes so later staff can explain how the map was chosen.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Schedule backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio map preview and generation settings](https://wiki.factorio.com/Map_generator)
- [Factorio map exchange string format](https://wiki.factorio.com/Map_exchange_string_format)

# Collect a useful Factorio desync report

A Factorio desynchronisation means the server and a client disagree about the simulated game state. Preserve the report before changing mods or restarting repeatedly. A useful report gives the developer or support team a specific state to investigate without requiring you to experiment on the live factory.

## Confirm that the symptom is a desync

Write down the exact on-screen message. A delayed action, low update rate or failed connection does not by itself establish a desync. The official Factorio documentation distinguishes simulation disagreement from network latency and performance problems.

Record the time with its time zone, the affected players, the game version and the enabled mod versions. Ask whether the same action preceded the problem, such as entering a particular area. Describe the observation without declaring that the action caused it.

## Preserve the generated evidence

1. Let the affected client finish creating its desync report. The game may download additional data before presenting the result.
2. Use the game’s offered report-location option, or find the report in the client’s Factorio user-data directory for that installation.
3. Copy the complete report archive to a safe location. Keep the original filename and note the incident time beside it.
4. Download the server log covering the same period through your game panel. Avoid trimming away the startup version and mod list.
5. Take a completed backup of the current server state before any troubleshooting change.

## Describe a reproducible sequence

Write short numbered steps for the actions that preceded the disconnect. State whether one player or several players desynced and whether they could reconnect. Mark uncertain details as uncertain. A screenshot of the final dialog helps identify the symptom, but it does not replace the report archive.

The upstream documentation explains that reports contain client and server game-state data and can be large. Treat them as private service data. They may reveal the factory layout and player information, so share them through the support route or the developer’s requested reporting channel rather than an open chat.

## Avoid destructive or expensive probes

Do not remove content mods from the production save to see whether the error stops. Test that question on a separate copy after recording the original combination. Keep your untouched incident backup so you can return to the state the report describes.

Do not enable heavy diagnostic modes during normal play without a developer’s plan. Such modes can disrupt the session and generate substantial files. Check available storage and the exact requested procedure before collecting extra diagnostics.

## Hand over evidence and record recovery

Send the report, relevant log, version and mod list, plus your reproduction notes. Explain any restart or configuration change already made. If a restart lets players rejoin, record it as a workaround rather than proof that the underlying cause disappeared.

After a proposed fix, repeat the documented sequence on an isolated copy first. Reopen production access after you have an agreed change and recovery point. Keep the incident record so a recurrence can be compared with the same facts.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Fix a console that will not connect](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-a-game-console-that-will-not-connect-or-shows-a-504-error)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio desync reports and investigations](https://wiki.factorio.com/Desynchronization)

# Give Factorio players limited actions with permission groups

Factorio permission groups let you choose which in-game actions a set of players may perform. Use them for a limited guest role or a controlled event without giving those players administrator access. These groups apply inside the factory; they do not grant access to your CloudExa account or panel files.

## Define the role before editing

You need an administrator account in the current save and a completed backup. Record the installed Factorio version. Action names and the available controls can change between versions, so use the interface provided by your installed game rather than copying an old action list from a forum.

Write a small access checklist. For example, guests might need to move and chat while you restrict a particular building action during a guided tour. Include the actions they should retain, not just the one you intend to block. Overly broad restrictions can make a player unable to interact with the session.

## Create a separate group

1. Open the permissions interface with `/permissions` using your administrator account.
2. Inspect the existing groups and note the default group’s current rules. Keep that shared baseline unchanged for this trial.
3. Create a clearly named test group through the interface, or use `/permissions create-group TourGuests` if your installed command help supports it.
4. Inspect the new group’s current action states. Do not assume it starts with the exact policy you want.
5. Change the specific action controls for your role and assign one consenting test player to the group.

## Verify from the player’s session

Ask the tester to perform the allowed actions, then attempt the restricted action in a safe area. Confirm the visible result together. An administrator testing with their own session can miss restrictions or bypass behaviour that affects a normal account.

Check the tester’s group membership after reconnecting. Make sure the normal players remain in their original groups. Record the affected control names and outcomes so another administrator can review the policy.

Factorio’s runtime API describes each permission group as an action policy with assigned players. That model helps explain why promoting someone to admin is a separate decision. Do not promote a player merely to solve a group rule that blocks one needed action.

## Keep a narrow rollback

If the test prevents an essential action, restore that control to its previous state or return the tester to their recorded original group. Avoid resetting the whole permission system to fix one guest role. A global reset can remove restrictions that other staff rely on.

Once the policy works, assign the intended players and record who maintains the group. Remove temporary event memberships when the event ends. Keep a fresh recovery point before making a larger group redesign.

If you need scripted permission management, use the API documentation matching the installed release and test away from production. This guide uses the supported interface and management commands; it does not require running Lua cheat commands that could affect the save’s achievement eligibility.

## Related CloudExa help

- [Invite a teammate to your game server](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)
- [Keep your CloudExa account secure](https://help.cloudexa-hosting.com/books/billing-support/page/keep-your-cloudexa-account-secure)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [Factorio permission-group model](https://lua-api.factorio.com/latest/classes/LuaPermissionGroup.html)
- [Factorio permissions interface and commands](https://wiki.factorio.com/Console)

# Plan a Factorio server update around save compatibility

Before updating a long-running Factorio server, preserve a save that the current game version can still load. A rollback needs a compatible game, save and mod set together. Replacing the executable alone does not undo changes made when a newer release loads and saves the factory.

## Record the current baseline

Write down the full server version, client version and selected release branch. Record enabled expansion content and every enabled mod version. Save the active configuration and startup selection alongside that list.

Check the target release notes for compatibility changes and known issues relevant to your factory. Use a specific target version rather than the word “latest” in the maintenance plan. Give players that version so their clients do not update to a different branch during the cutover.

## Preserve a usable rollback set

1. Schedule the maintenance window and ask players to leave before the final pre-update save.
2. Stop the service through the panel and wait for it to finish. Take a completed backup covering the save, mod files and relevant configuration.
3. Download or retain that recovery point separately from rotating autosaves. Label it with the source version and date.
4. Confirm with support how the template selects a specific Factorio version. Do not use a reinstall button merely because it is the only visible update control.
5. Prepare an isolated test copy for the proposed game and mod combination before changing the live service.

## Test compatibility before opening access

Load the copied save in the proposed version and inspect the full startup log. If the game says the save is too old, stop and read the supported conversion route. The official installation guide explains that very old saves may need an intermediate game version and a resave before a newer release can load them.

Perform conversions only on copies. Give each intermediate output a distinct name and preserve the untouched original. Do not edit a save archive’s version metadata to bypass a loader check.

Join the test server with a matching client, review familiar production areas and check any mod-dependent recipes or entities that matter to the group. Have another player join if multiplayer compatibility is part of your concern. These are checks you should perform, not a claim that CloudExa has already tested your factory.

## Cut over with an agreed rollback window

Once the copy passes review, apply the planned version and mod set to the service using the supported update route. Load the intended save and confirm the server identity, connection allocation and startup log before inviting players back.

If you roll back, restore the pre-update save with its compatible original game and mod set. A newer save may not load in an older executable. Tell players that restoring the old checkpoint also loses progress made after it.

Keep the pre-update recovery point until the group has checked a normal session. Record the final running version and any conversion steps so the next update starts with a clear baseline.

## Related CloudExa help

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Schedule backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio older-version installation and save conversion](https://wiki.factorio.com/Install_guide)
- [Factorio developer explanation of newer-save incompatibility](https://www.factorio.com/blog/post/fff-353)
- [Official Factorio release history](https://wiki.factorio.com/Version_history)

# Restrict Factorio RCON access to an approved management path

Factorio RCON lets a remote tool send management commands to the server. Enable it only for a defined integration with an approved connection path. Your allocated game connection and an RCON management listener serve different purposes; making the game reachable does not establish that RCON should be public.

## Identify the actual requirement

Write down which tool needs RCON and which commands it will send. If you only need to use the game panel console yourself, check whether that already meets the requirement. Avoid adding another listener for a tool nobody maintains.

You need ownership of the service and access to its startup settings. Network restrictions and extra allocations may require support. A game-panel customer should not attempt host firewall changes or bind to an unassigned port.

Factorio’s upstream command-line reference lists separate RCON bind, port and password options. The exact fields exposed by your CloudExa template can differ. Ask support to confirm the effective command if the panel only shows a subset.

## Plan the route before enabling it

1. Record the integration’s trusted source and whether it can use a private management network or another approved restricted path.
2. Ask support to confirm the permitted destination address, allocation and source restrictions. Do not assume a default port belongs to your service.
3. Generate a strong, unique secret using a password manager and store it in the integration’s secret field.
4. Keep screenshots, command examples and support messages free of the password. A startup command can reveal secrets if you paste it in full.
5. Schedule a restart if the startup configuration needs changing. Preserve the previous configuration before making the change.

## Verify management access without changing the factory

After startup, inspect the log for binding errors. Use the approved management client to send a harmless information or help request supported by your installed version. Record the response and time. Do not test with a destructive command, an arbitrary script or a password-reset action.

Have support verify that an unauthorised source cannot reach or authenticate to the management interface, using the agreed network policy. A failed connection from one laptop does not prove the listener has no other public path.

Confirm that normal players can still connect through the game allocation and that the integration can reconnect after a planned server restart. If a tool retries aggressively, set a reasonable retry delay through its supported options so an outage does not create unnecessary load.

## Retire unused access

If the integration is no longer needed, remove or disable its RCON startup configuration using the template’s supported controls. Restart during a maintenance window and ask support to verify that the listener stopped. Revoke the secret in the external tool as well.

For a failed rollout, restore the recorded startup configuration and keep the connection error for support. Do not broaden the bind address or remove source restrictions until the team identifies the failed part of the route. Document who owns the integration and when to review its access again.

## Related CloudExa help

- [Keep your CloudExa account secure](https://help.cloudexa-hosting.com/books/billing-support/page/keep-your-cloudexa-account-secure)
- [Invite a teammate to your game server](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

## Official references

- [Factorio RCON bind, port and password options](https://wiki.factorio.com/Command_line_parameters)

# Restrict ARK Ascended admission with an EOS allowlist

Use an admission allowlist when you want an ARK: Survival Ascended community to accept named accounts. A shared password can reach people outside your group. An identity list lets you approve individual accounts, but a mistaken identity or startup option can also lock out your organisers. Arrange a short admission test with two volunteers before you invite the community.

## Check identity support first

Wildcard documented an ASA fix for `PlayersJoinNoCheckList.txt` with `-exclusivejoin`, specifying EOS IDs. Do not populate that list with an old Survival Evolved Steam-only list. Ask your host how the installed ASA build exposes the relevant EOS identities and which existing file the server reads. Keep player identities out of public screenshots and support posts.

Open your panel's startup page and record its present options. Download the current admission file, if one exists. You need permission to edit both the startup configuration and the file; file access alone cannot prove that the admission mode is enabled. If the panel hides the required flag or file location, request the change through support rather than renaming unrelated files.

## Run an approved and an unapproved test

1. Tell your volunteers the test window. Choose one account to approve and one to leave outside the list. Record their exact identities through the method supported by your build.
2. Stop the server through its normal panel control and wait for the process to exit. Save copies of its startup configuration and existing admission list.
3. Add the approved account to the server's actual `PlayersJoinNoCheckList.txt`. Preserve the format expected by the installed server. Remove accidental spaces around identities and check that the editor has not changed the filename extension.
4. Enable `-exclusivejoin` through the supported startup setting. Keep the map, save location, ports and mod selection unchanged. Start the server and watch for configuration or startup errors.
5. Have the approved account make a fresh connection. Then ask the unapproved volunteer to attempt a fresh connection using the same advertised route. An existing session does not test a new admission decision.

## Confirm the result before adding more names

Record both outcomes and the server build. The approved player must reach the expected character and world; the other volunteer must fail admission. A browser listing alone proves neither condition. If both accounts join, inspect whether the panel retained the flag and whether the server loaded the intended list. If neither joins, check the recorded identities before adding unrelated networking changes.

## Recover without altering the world

Use the panel to stop the process and restore the previous admission file and startup options if you lose access. Restart and repeat the original joining check. You do not need a new map, a reinstall or a player-data reset for this configuration rollback. Keep a named owner responsible for future additions and removals, and retest admission after a template or major server update.

## Related help and sources

- [Diagnose ARK Survival Ascended connection failures](https://help.cloudexa-hosting.com/books/game-hosting/page/diagnose-ark-survival-ascended-connection-failures)
- [Choose the correct ARK Ascended configuration file and section](https://help.cloudexa-hosting.com/books/survival-games/page/choose-the-correct-ark-ascended-configuration-file-and-section)

[Wildcard ASA patch notes](https://survivetheark.com/index.php?/forums/topic/708761-asa-pc-patch-notes-client-v947-updated-09302026/).

# Control custom cosmetics on an ARK Ascended server

ARK: Survival Ascended custom cosmetics and gameplay mods need separate decisions. If your community wants fewer cosmetic downloads or a controlled visual environment, change the cosmetic policy without dismantling the gameplay mod list. Start by writing down the exact symptom: an unwanted cosmetic, a download delay, or a rendering problem. Those need different evidence.

## Choose the scope of the change

Wildcard documents `-DisableCustomCosmetics` as a startup parameter for disabling the custom cosmetic system. Its patch notes also describe `CosmeticWhitelistOverride` in the `[ServerSettings]` section of `GameUserSettings.ini` for a custom approved-list URL. Check the current build notes before using either mechanism. A copied gameplay mod ID list is not a cosmetic policy.

For a first diagnostic trial, disabling the cosmetic system has fewer moving parts than creating and hosting an approved-list service. If you need a custom URL policy, ask support to confirm the current expected response format and reachability before deployment. Do not invent a JSON layout or point the setting at a web page containing a list of mod names.

## Make a reversible cosmetic-only trial

1. Ask a volunteer to record the affected cosmetic, client platform and visible problem. Take screenshots that show the symptom without exposing account details.
2. Download the current configuration and copy the panel's startup options. Preserve the map, gameplay mod IDs, ordering and save path in your change record.
3. Schedule a brief restart and stop the game through the panel. Enable `-DisableCustomCosmetics` through the supported startup control. If the panel does not expose additional arguments, ask support to apply this single change.
4. Start the server and wait for its normal ready state. Ask the volunteer to reconnect, then check the same area and cosmetic interaction. Compare the result with the recorded symptom.
5. Confirm that gameplay content and the existing player character still load. Do not accept a successful process start as evidence that the intended world and gameplay mods loaded.

## Separate policy from troubleshooting

If the symptom persists, capture the first relevant client or server error and restore the previous cosmetic setting for the next investigation. Disabling cosmetics cannot establish that every download or startup failure comes from a cosmetic. If the trial resolves the reported issue, tell players which visual features you intend to restrict and keep that policy alongside the server rules.

Test an approved-list policy with one allowed item and one item outside the list before inviting the group. Check client behaviour on the platforms your community uses. Avoid promising that cached client files will disappear, or that every cosmetic behaves alike after a policy change.

## Roll back the setting

Stop the server, restore the recorded startup options and configuration value, then restart. Compare gameplay mod IDs once more so a cosmetic rollback does not hide a second change. Retain the original symptom report and trial result. That evidence helps support investigate a build-specific cosmetic problem without requesting a reinstall or removing content from a valued world.

## Related help and sources

- [Choose an ARK Survival Ascended map and CurseForge mods](https://help.cloudexa-hosting.com/books/game-hosting/page/choose-an-ark-survival-ascended-map-and-curseforge-mods)
- [Investigate ARK Ascended mod updates and startup conflicts](https://help.cloudexa-hosting.com/books/survival-games/page/investigate-ark-ascended-mod-updates-and-startup-conflicts)

[Wildcard cosmetic configuration notes](https://survivetheark.com/index.php?/forums/topic/708761-asa-pc-patch-notes-client-v947-updated-09302026/).

# Change ARK Ascended cryopod release rules with a reversible trial

Agree on cryopod release rules before changing an established ARK: Survival Ascended world. Players may depend on a fridge requirement or nearby-enemy restriction for base defence. A small configuration edit can change those expectations. Test the proposed rules with expendable creatures and staff volunteers, away from a live raid or an irreplaceable tame.

## Identify the rule you want to change

Wildcard lists three independent options under `[ServerSettings]` in `GameUserSettings.ini`: `DisableCryopodEnemyCheck`, `AllowCryoFridgeOnSaddle` and `DisableCryopodFridgeRequirement`. Their names describe separate controls. Allowing a fridge on a raft or saddle does not mean you have also removed the fridge requirement for release.

Check the installed ASA build and current publisher notes because later game changes may affect an older rule. Write a plain-language target, such as retaining the fridge requirement while allowing mobile fridges. Record existing explicit values and whether a key is absent. An absent key and an explicit false value deserve separate entries in your rollback record.

## Change one condition at a time

1. Download the active configuration and take a recoverable world checkpoint. Identify an empty test location and a tame you can afford to lose. Do not use a player's prized creature to discover an unexpected release condition.
2. Stop the server through the panel. Find its existing `[ServerSettings]` section and change only the option relevant to your agreed policy. Avoid adding several copies of the same key.
3. For an illustrative mobile-fridge trial, set `AllowCryoFridgeOnSaddle=True` while retaining the other recorded rules. This example is a test plan, not a recommended PvP balance setting.
4. Start the server and ask staff to test the intended placement or release condition. Record location, creature, surrounding conditions and the message the player receives.
5. Test a condition that should remain restricted as well. A successful placement alone cannot prove that an unrelated enemy or release rule remained intact.

## Check with players before adopting the result

Compare behaviour against your written policy and inspect the active file after the restart. Some panel templates regenerate configuration from startup fields. If your edited value has reverted, fix the authoritative panel setting rather than repeating the file edit. Ask support which setting wins if both controls exist.

Publish the chosen rule with an effective date and a short example players can understand. For a competitive community, make the change outside an ongoing event and let players adjust their defences. Keep the same values across relevant maps when your published cluster rules promise consistent behaviour; verify each server instead of assuming one file controls them all.

## Undo an unsuccessful trial

Stop the process and restore the recorded keys or remove only keys that you introduced. Restart and repeat the original restricted-condition check. A configuration rollback does not undo player actions that took place during the trial, so keep the test small. If a valued creature goes missing, preserve logs and checkpoints and follow the separate recovery guide before loading an older world.

## Related help and sources

- [Choose the correct ARK Ascended configuration file and section](https://help.cloudexa-hosting.com/books/survival-games/page/choose-the-correct-ark-ascended-configuration-file-and-section)
- [Restore an ARK Ascended checkpoint with consistent player and tribe data](https://help.cloudexa-hosting.com/books/survival-games/page/restore-an-ark-ascended-checkpoint-with-consistent-player-and-tribe-data)

[Wildcard cryopod configuration notes](https://survivetheark.com/index.php?/forums/topic/708761-asa-pc-patch-notes-client-v947-updated-09302026/).

# Check an ARK Ascended save before adopting usestore

ARK: Survival Ascended can store player and tribe data inside the world save through the `-usestore` mode documented by Wildcard. Treat a change to this mode as a save-format migration. Checking a box or copying one map file without understanding the current layout can leave you with a misleading recovery plan.

## Inventory the present save mode

Download or record the complete startup configuration, server build, map, save location and mod list. Look for `-usestore` and `-converttostore` in the effective startup arguments, including options the hosting template supplies. Do not infer the active mode from a filename alone: Wildcard notes that conversion leaves the old profile and tribe files in place.

The publisher describes `-converttostore` as importing existing player and tribe data into the world save, with `-usestore` selecting that storage method. Those flags have different purposes. Do not add a conversion flag to a production restart as a routine optimisation. Ask support to confirm the actual current mode if you cannot inspect the effective arguments.

## Prepare evidence before proposing a conversion

1. Stop the original server through its normal control and capture a complete checkpoint containing the world, player and tribe files plus configuration. Keep this original outside the test location.
2. Write a small verification list with at least two established characters, their tribes, representative structures and a few known tames. Avoid publishing private player identifiers in that list.
3. Arrange an isolated test server or support-assisted test with the same build and gameplay mods. Give it separate allocations and save storage. Prevent test characters from interacting with the live cluster.
4. Ask the operator to apply Wildcard's documented conversion sequence to that copy. Record the exact first-start and later-start arguments. Do not run a second writer against the original save directory.
5. On the copy, verify the listed characters, memberships, ownership and inventories. Save, stop and start the copy again using the intended ongoing configuration, then repeat the checks.

## Prove that recovery still works

Take a checkpoint from the converted test and restore it to a separate stopped test location. Confirm that the expected character and tribe state comes back with the world. Record the storage mode with the archive so a future operator does not combine instructions for two layouts. A successful launch without established-player checks leaves the most important part of the migration unverified.

Do not remove old `.arkprofile` or `.arktribe` files during this evaluation. They may belong to your original recovery set, and their presence alone does not establish which copy the running server uses. Storage housekeeping can wait until you have an agreed retention policy and a verified recovery copy.

## Return to the original if the trial fails

Keep the production server on its recorded startup mode and untouched checkpoint while you investigate. For a failed conversion after a planned cutover, stop writes before restoring the complete pre-conversion save and its matching arguments. Record any gameplay since cutover before choosing a rollback. Ask support to review unclear ownership or identity results rather than repeating conversion attempts against the only original.

## Related help and sources

- [Move an ARK Survival Ascended save safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-ark-survival-ascended-save-safely)
- [Restore an ARK Ascended checkpoint with consistent player and tribe data](https://help.cloudexa-hosting.com/books/survival-games/page/restore-an-ark-ascended-checkpoint-with-consistent-player-and-tribe-data)

[Wildcard usestore save-system notes](https://survivetheark.com/index.php?/forums/topic/708761-asa-pc-patch-notes-client-v947-updated-09302026/).

# Prevent Palworld inactivity cleanup from removing an absent guild

A Palworld player returning from a holiday should know whether their guild's buildings and base Pals will still exist. Review inactivity cleanup before you enable it on a long-running friends server. This setting can remove gameplay state; increasing storage or restarting the process will not recover items that the game has already removed.

## Understand the two linked controls

Pocketpair documents `bAutoResetGuildNoOnlinePlayers` as the switch for deleting structures and base Pals after a guild remains inactive. `AutoResetGuildTimeNoOnlinePlayers` controls the offline period and has no effect while that switch is false. Check the documentation for your installed version before selecting a duration. Do not assume the unit from a similarly named setting or an old forum post.

Record the current switch and timer from the active configuration, then ask whether your panel regenerates those values. Keep this task separate from decay, raids and death penalties. If players report missing structures, collect the affected guild, approximate last login and earliest known disappearance before concluding that inactivity cleanup caused it.

## Choose a policy that fits the group

1. Ask guild owners about expected absences and publish a proposed retention rule. Include whether an entire guild must be absent and how players can request help before a long break.
2. Download the current configuration and make a recoverable save checkpoint. Preserve existing archives while you investigate any reported disappearance.
3. Stop the server through the normal panel control. To prevent this specific automatic guild reset, set `bAutoResetGuildNoOnlinePlayers=False` in the existing options record, preserving its surrounding syntax.
4. Retain the recorded timer for reference unless you have a separate reason to change it. Changing both fields makes a later investigation harder and does not help verify the disabled switch.
5. Start the server and check that the active file still contains the chosen value. Ask a guild owner to inspect a known base and confirm existing Pals and structures.

## Verify without sacrificing a guild

Do not shorten the live inactivity timer to force a destructive test. Check the effective configuration and use a disposable test world if you need behavioural confirmation for a particular build. Record the test guild, intended timing and outcome. Keep real players out of that test so a login does not invalidate the absence condition.

Watch disk usage and base growth after disabling cleanup. You may need a documented manual review process for abandoned communities, but that does not justify silently enabling deletion later. Agree a notice period and keep player communication with your server rules. A world checkpoint from before a policy change provides a recovery option; it does not make automatic deletion harmless.

## Respond to a suspected earlier cleanup

Turning the setting off prevents future use of this rule; it does not reconstruct a removed base. Stop unnecessary changes, preserve current saves and logs, and ask support to help assess a dated backup. Restoring an older world can roll back other guilds' progress. Obtain a clear recovery decision before replacing live state, and keep a copy of the present world in case the older checkpoint does not contain the expected base.

## Related help and sources

- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

[Pocketpair configuration parameters](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Set a Palworld death policy without surprising existing players

Write your Palworld death rules in player language before editing the server. “Keep inventory” does not explain whether equipment, team Pals or the character itself survives. Existing players may carry valuable items while they test a changed rule. Use a disposable character on a separate test world whenever your proposed policy includes permanent loss.

## Separate the three decisions

The current Pocketpair reference lists `DeathPenalty` options for retaining or dropping items, equipment and team Pals. It also documents `bPalLost` for permanent Pal loss on death and `bHardcore` for the inability to respawn. Read those controls together before assuming that one inventory setting describes the whole death outcome.

Check the version selector in the official documentation and compare the supported keys with your installed build. A newer reference may describe features your server does not yet support. Record the existing values, including `bCharacterRecreateInHardcore` if your build supports it. Do not toggle Hardcore on a valued world to discover what happens to established characters.

## Document and test the intended outcome

1. Make a short policy table covering normal inventory, equipped items, team Pals and respawning. State what players should expect for each category. Share it with the group before the maintenance window.
2. Back up the active configuration and complete world save. Use your existing configuration guide to locate the authoritative options record; do not replace it with a small fragment containing only death settings.
3. On the separate test world, apply the proposed supported values while the process is stopped. For a no-drop policy, review `DeathPenalty=None` alongside the permanent-loss and Hardcore switches rather than assuming the first value overrides everything.
4. Join with expendable items and no valuable Pals. Record the test character's state, perform one controlled death and inspect the resulting respawn, inventory and any dropped bag.
5. Repeat the relevant test after a clean restart. Compare what happened with every row of your policy table before proposing the live change.

## Apply the agreed policy

Schedule the live edit outside a boss attempt or community event. Stop the server, change only the confirmed values, and start it again. Check that the panel preserved them. Tell players the effective time and describe the observed outcome without claiming that a test covers every mod or unusual death circumstance.

Keep temporary event rules distinct from permanent server rules. If you plan to restore the previous policy after an event, record the exact values and the planned time. Ask players to store valuable gear before either transition. Avoid combining the change with difficulty, raid or crossplay adjustments, which would complicate an unexpected result.

## Recover from a mismatch

If behaviour differs from the agreement, stop the experiment and restore the recorded settings. Restoring a rule cannot return items or Pals already lost. Preserve the current save before assessing an older checkpoint with support, and consider the progress other players would lose in a world rollback. Do not promise item recovery until someone has checked a suitable archive.

## Related help and sources

- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)
- [Update Palworld while preserving a recoverable save checkpoint](https://help.cloudexa-hosting.com/books/survival-games/page/update-palworld-while-preserving-a-recoverable-save-checkpoint)

[Pocketpair death and Hardcore parameters](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Control Palworld Global Palbox imports and exports

Decide whether your Palworld community permits Pals from outside its world before players begin transferring collections. Global Palbox import and export are separate choices. A group may allow players to take a copy outward while keeping incoming Pals restricted. Announce the policy in plain language and apply it consistently before a competitive event.

## Check the installed feature set

Pocketpair's configuration reference documents `bAllowGlobalPalboxImport` and `bAllowGlobalPalboxExport`. Compare the documentation version with your running build and its supplied defaults before editing. These settings govern the named Global Palbox feature; do not assume they implement a complete prohibition on every other transfer mechanism, mod or future game feature.

Record both current values from the active server options. Ask a volunteer how they currently use the feature and whether any transfer remains in progress. Arrange the test with a disposable Pal. Testing with a rare bred Pal adds risk without improving the evidence you need for an admission policy.

## Define each direction before editing

1. Write down two explicit answers: may players import from the Global Palbox, and may they export to it? Include any event exceptions and who can approve a change.
2. Download the current configuration and take a dated world checkpoint. Keep the transfer policy beside that checkpoint so you can interpret older saves later.
3. Stop the game through its normal panel control. Edit the existing import and export values in the active options record, preserving other options and the file's punctuation.
4. Start the process and inspect the active configuration after startup. If the panel restores old values, change the relevant startup field or ask support to identify the authoritative control.
5. Have the volunteer test the permitted and restricted directions with expendable data. Record the client message and outcome for each direction rather than treating one successful interaction as proof of both.

## Check the wider player experience

Ask a second player to confirm the same result using a normal account. Keep administrator powers out of the test unless your question concerns an administrator-specific path. Record the server and client build, then check that players still reach their established characters and bases. Keep unrelated transfer and crossplay options unchanged during this trial.

Tell the group which direction you restricted and when the rule took effect. Disabling imports does not establish where existing Pals originated, nor does it automatically remove Pals that arrived before the change. Investigate a historical dispute through records and backups rather than repeatedly switching these options or resetting player data.

## Roll back a configuration error

Stop the server and restore the two recorded values if the result differs from your policy. Retest both directions after restarting. Avoid a world rollback just to undo a boolean setting: an older world can remove unrelated progress and cannot establish the state of every external service. If an attempted transfer leaves a Pal missing, preserve the timestamps and visible messages and seek support before moving more copies between locations.

## Related help and sources

- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)
- [Move an existing Palworld world safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-existing-palworld-world-safely)

[Pocketpair Global Palbox parameters](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Plan Palworld base and worker limits before expanding a guild

Increasing a Palworld guild's bases or active workers changes the workload players can create. Plan the expansion around a representative base rather than treating a larger limit as a performance fix. You need a recoverable save, a known busy period and a volunteer who understands which base will act as the test case.

## Record separate capacity controls

The current Pocketpair reference distinguishes total server bases, bases per guild and workers per base through `BaseCampMaxNum`, `BaseCampMaxNumInGuild` and `BaseCampWorkerMaxNum`. Its current guidance warns that larger guild-base and worker limits increase processing load. Check the reference for your installed build instead of copying maximum values from another server.

Count the group's existing bases and workers before editing. Record concurrent players and representative resource use from the panel, including whether the server has recently restarted. A quiet, empty server provides little evidence about a busy production base. Save the current configuration and note any template fields that could overwrite it.

## Run a bounded expansion trial

1. Choose one bottleneck: an additional guild base or additional workers. Agree a small increment with players and write the original limit beside the proposed limit.
2. Schedule the change and take a complete save checkpoint. Stop the process and edit the single supported limit in the existing options record.
3. Restart and confirm that the panel preserved the value. Have the volunteer exercise the intended capacity without building several additional bases at once.
4. Observe the server during comparable play. Record active players, the test base, resource readings, noticeable delays and log errors over the same observation window.
5. Ask players at another base whether they notice new delays. Compare with your baseline before authorising another increment or changing a second limit.

## Interpret the result carefully

A rise in memory use after players join does not prove a leak, and a short quiet test cannot guarantee smooth peak-hour play. Investigate repeated errors and sustained resource pressure before making a capacity decision. Keep a dated record of approved limits so future staff can distinguish the purchased resources from the game's gameplay caps.

If the expansion works for your group, tell guild owners what you changed and discourage everyone from testing the new maximum at once. Arrange another review after a representative busy session. Do not combine a limit increase with new mods, randomizer settings or a major game update when you want evidence about that limit.

## Plan reductions before touching live settings

Lowering a cap after players use it may affect gameplay in ways a configuration-only rollback cannot reverse. First ask owners to reduce the relevant live usage through supported game actions, or test the reduction on a separate copy. Keep the complete pre-change checkpoint and present save. If the server becomes unstable, preserve evidence and ask support for a recovery plan rather than repeatedly cutting caps or deleting base data.

## Related help and sources

- [Read Palworld crash and memory evidence before changing resources](https://help.cloudexa-hosting.com/books/survival-games/page/read-palworld-crash-and-memory-evidence-before-changing-resources)
- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)

[Pocketpair base capacity and performance settings](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Introduce a Palworld randomizer on a separate test world

A Palworld randomizer changes what players can encounter, so evaluate it on a separate world before inviting your established community. You need a test installation that cannot write to the live save directory. A backup stored beside a running world does not provide that separation. Ask support for an isolated test if your plan has only one server slot.

## Check which options your build supports

Pocketpair's current reference documents `RandomizerType`, `RandomizerSeed` and `bIsRandomizerPalLevelRandom`. It distinguishes no randomization, regional randomization and full randomization. Check the documentation version and supplied defaults against your server build. Older templates may omit these options or expose an incomplete set of controls.

Record the proposed type, seed and level policy as one experiment. Keep the same game build, mods and unrelated world settings across trials. Otherwise you cannot tell whether a changed encounter comes from the randomizer or another change. Avoid promises that a seed guarantees identical behaviour across future builds.

## Create a safe trial

1. Preserve a complete live checkpoint and its configuration. Provision a separate test world with its own save storage and assigned ports, clearly named as a test so players do not confuse it with production.
2. Stop the test process and apply the supported randomizer options to its active configuration. Use the accepted values from your build's reference rather than translating the option names into another language.
3. Start the test and confirm its identity, save path and configuration. Join with a fresh test character; do not move an established production character to validate a random encounter.
4. Visit several recorded locations with volunteers. Note the mode, seed, location, encounter and level. Keep the observation route similar between trials.
5. Stop and restart the test using the same settings, then revisit your notes. If you change one setting for comparison, give the new experiment its own dated record.

## Decide what your community will accept

Ask players whether early progression, dangerous routes and access to desired Pals match the experience you intend. A randomizer policy can affect expectations even when the process runs without errors. Write a short description of the intended challenge rather than promising a precise list of encounters that your small test cannot establish.

Keep the trial separate from decisions about applying settings to an existing world. The configuration reference alone does not promise how every existing spawn or saved creature will respond. Test any proposed existing-world change on a copy of that world. Inspect established characters and bases as well as encounters before scheduling production maintenance.

## Keep recovery simple

If the trial disappoints, restore the previous test settings or retire the test through your normal account controls. Your original live world should remain untouched. For a later production launch, keep the pre-change checkpoint and record when players began new progress. Reverting settings may not undo gameplay effects that occurred while they were active; decide with your community before rolling back the whole world.

## Related help and sources

- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

[Pocketpair randomizer options](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Restrict selected Palworld technologies with a tested deny list

Use a technology deny list when a Palworld event or community ruleset should restrict particular unlocks. Begin with one technology and a disposable test character. Restricting an unlock does not establish what happens to existing crafted items or structures, so agree how your community will handle those before applying a live rule.

## Use the official technology identifier

Pocketpair documents `DenyTechnologyList` and links a technology-ID reference from the configuration page. Use that internal identifier, including its spelling and case, rather than the translated item name shown in your client. Check the documentation version against the installed server because identifiers and supported settings can change.

Record the current list and download the full active configuration. This option contains an array inside the broader configuration syntax. Preserve the surrounding record, quoting and parentheses. Do not paste an isolated example over all of `PalWorldSettings.ini`, or combine fragments from different versions without checking the supplied defaults.

## Build the smallest useful test

1. Choose a technology that a test character has not unlocked. Write down its official ID and intended restriction, along with what players should still be able to unlock.
2. Back up the world and configuration, then stop the test server through the panel. Add that one ID to the existing `DenyTechnologyList` using the array form documented for your build.
3. For example, `DenyTechnologyList=("RepairBench")` names one technology; it is only a field fragment, not a replacement configuration file. Check matching quotes, commas and parentheses in the complete options record. Avoid adding a second copy of the same setting later in the file.
4. Start the test and inspect startup messages. Confirm the active file retained the list and that the game loaded the expected world rather than a fresh default.
5. Join with a normal test account. Check the intended unlock and a nearby unrestricted technology. Record the visible result and any error message.

## Check the rule's boundaries

Repeat the check with a character that already knows the technology on an isolated copy if you need to understand that case. Examine crafting and existing items separately. Do not infer item deletion or structure removal from a rule described as disabling technologies. Document any uncovered behaviour as a limit of your test rather than a guarantee.

Add further restrictions in small groups and retain the last known working list. Tell players the effective date and the exact gameplay restrictions they should expect. For a temporary event, record the planned end time and preserve the pre-event list so another organiser can restore the same policy.

## Recover from syntax or policy mistakes

If startup fails after the edit, stop the process and restore the recorded configuration before investigating the first parsing error. Do not reset the save or run an installer to fix a list typo. If players can still perform the restricted action, check the technology ID and the authoritative panel setting first. Escalate with a redacted list, build number and test result; keep passwords and private player data out of the report.

## Related help and sources

- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

[Pocketpair technology deny-list reference](https://docs.palworldgame.com/settings-and-operation/configuration/); [Pocketpair technology identifiers](https://docs.palworldgame.com/settings-and-operation/technologyids/).

# Manage Palworld chat limits and player visibility

Review Palworld chat and presence settings before opening a public community. A busy chat, unwanted join announcements and player-list visibility involve different controls. Changing a visibility setting does not grant moderation powers or erase information players already know. Write down the experience you want for an ordinary player before editing.

## Separate chat rate from presence information

The current Pocketpair reference documents `ChatPostLimitPerMinute`, `bIsShowJoinLeftMessage` and `bShowPlayerList`. Check that your build supports the same keys. Select a chat limit around your community's actual use and the documented behaviour for your version; do not assume a special value such as zero means unlimited.

Ask a moderator to collect a short description of the problem without reposting private chat. Is someone sending repeated messages, or do players simply want fewer arrival announcements? Keep evidence of abusive messages private and follow your moderation policy. Disabling a player list does not replace account moderation.

## Apply one policy change

1. Record the current three values, the build and any relevant panel fields. Choose the single control that addresses the reported problem.
2. Download the active configuration. Schedule a short restart, stop the process and update the selected setting inside its existing options record.
3. Start the server and confirm the panel kept the value. Ask two volunteers to join with normal accounts, leaving their administrator privileges unused during the test.
4. For a chat-limit trial, agree a brief controlled sequence with the volunteers. Stop when they reach the expected restriction and record the client response. Avoid flooding a live community to discover a limit.
5. For visibility settings, check the ordinary player's player-list interface and a volunteer's join and leave events. Record what remains visible rather than assuming you have made players anonymous.

## Explain the outcome to players

Publish the resulting chat rule and show moderators how a legitimate user can report a false restriction. Keep enough room for normal conversation, especially when players need help during an incident. If automation or a mod also changes chat, document that second layer and test it separately so staff know which restriction produced a message.

Review the policy after a representative community session. Collect specific reports with times and client messages. A successful quiet test does not tell you whether players will find a limit comfortable during an event. Adjust one setting at a time and keep a dated record of decisions for the next moderator.

## Restore the previous behaviour

If the change blocks ordinary conversation or hides information your moderators require, stop the server and restore the recorded value. Restart and repeat the same normal-account test. A configuration rollback does not require a world reset, file deletion or reinstall. For an ongoing abuse problem, preserve relevant evidence and use supported moderation controls rather than sharing the administrator password with more volunteers.

## Related help and sources

- [Use Palworld administration without exposing RCON publicly](https://help.cloudexa-hosting.com/books/survival-games/page/use-palworld-administration-without-exposing-rcon-publicly)
- [Edit Palworld server settings safely](https://help.cloudexa-hosting.com/books/game-hosting/page/edit-palworld-server-settings-safely)

[Pocketpair chat and player-list settings](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Separate Palworld local save history from off-server backups

Palworld's local backup saves can help with a recent gameplay mistake, but keep a separate copy outside the game server. A lost disk, full account or inaccessible node can affect both the live world and local history together. Review where each copy lives before promising players that their world has an off-server recovery path.

## Identify the two backup layers

Pocketpair documents `bIsUseBackupSaveData` for creating backup data beneath the save location and warns that enabling it increases disk load. Check the current official reference for its retention schedule. Do not copy an old schedule into a panel task and assume you have changed the game's internal history behaviour.

In the file manager, identify the live world directory and any local `backup` directory without renaming or moving them. Record approximate sizes and dates. Then inspect your panel's backup page separately: check whether a completed archive exists, its timestamp and whether you can download it. A directory named backup proves only that files exist at that location.

## Establish a recoverable checkpoint

1. Record the server build, world identity and relevant configuration. Ask players to leave for a short maintenance window and stop the server through its normal control.
2. Create a panel backup covering the complete required save and configuration. Wait for a completed result rather than treating a queued or running job as finished.
3. Download a recovery copy or confirm the plan's off-server backup arrangement with support. Keep a note of its size, completion time and location without placing credentials in the filename.
4. Start the original server and verify established characters and bases. Inspect disk use after the next period of normal activity so you can see whether local history is accumulating as expected.
5. Arrange an isolated restoration check when possible. Use separate storage and allocations, and prevent the test world from accepting ordinary players as if it were production.

## Budget storage for history

Compare live saves, local backup history, logs and panel archives as separate categories. Keep free space for normal saves and maintenance rather than filling the account to its published limit. If local history grows unexpectedly, record the directory sizes and contact support before deleting files you do not recognise. Do not remove an archive while a backup or restoration task is using it.

Choose retention around how long players may take to notice a problem. Several recent copies can all contain the same unwanted change. Keep dated older checkpoints when your storage plan permits, and document which copies you have verified. Avoid claiming that the game setting automatically exports files to another machine.

## Recover with the correct copy

Before restoring, preserve the current world and choose a complete checkpoint from before the incident. A rollback can remove progress from other players, so agree the recovery point with the group. If a panel task fails or stays running, preserve its request details and seek support. Repeatedly starting restorations can make it harder to identify which copy reached the live directory.

## Related help and sources

- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Move an existing Palworld world safely](https://help.cloudexa-hosting.com/books/game-hosting/page/move-an-existing-palworld-world-safely)
- [Investigate and recover from a full game server disk](https://help.cloudexa-hosting.com/books/game-hosting/page/investigate-and-recover-from-a-full-game-server-disk)

[Pocketpair local backup-save documentation](https://docs.palworldgame.com/settings-and-operation/configuration/).

# Keep a Don't Starve Together cluster token private

A Don't Starve Together dedicated cluster uses a Klei token for online operation. Treat that token as an account secret when you upload settings, share logs or ask someone to help with the server. You do not need to post its contents to prove that you placed it in the expected cluster.

## Find the cluster the process actually uses

Klei documents a cluster path assembled from `-persistent_storage_root`, `-conf_dir` and `-cluster`. Hosting templates can change these options. Record their effective values from your panel or ask support for the active location. Editing a similarly named directory elsewhere can leave the server reading an older token.

The official command-line guide allows a token argument as an alternative to `cluster_token.txt`. Prefer your panel's supported secret or file workflow. A token pasted into a visible startup field may appear in screenshots or shared diagnostic output. Ask who can view that field before using it, and avoid including it in public change notes.

## Upload settings without exposing credentials

1. Sign in to the official Klei account service using your own account. Use its game-server settings workflow to obtain the token or configuration for the intended server. Keep the downloaded archive private.
2. Stop the dedicated cluster through the hosting panel. If it has multiple shards, check the relevant controls rather than stopping only the window currently on screen.
3. Locate the cluster directory identified by the effective startup options. Upload the token through the supported file or secret control, preserving the expected filename and avoiding extra editor formatting.
4. Review game-panel subusers and remove unnecessary file or startup access through normal permission controls. Do not take away a co-owner's access without an agreed responsibility change.
5. Start the cluster, inspect its logs for authentication errors and ask a volunteer to join the intended world. Redact tokens before sharing any diagnostic material.

## Keep useful evidence without the secret

Record the cluster name, server build, startup time and whether authentication completed. Those details let support compare a failed attempt without seeing a full token. If a log includes account material, share it through a private support channel and mark the sensitive section. Do not replace every token-looking string in the live file just to make a screenshot safe; redact a separate copy.

Backups of the cluster may also contain the token. Keep downloaded archives in private storage and check a sharing link's access before sending it. If your team keeps settings in version control, exclude the real token and store a placeholder that explains where operators retrieve the secret.

## Respond to accidental disclosure

Use Klei's current account controls to replace the exposed token where available, then update the active cluster during a short maintenance window. Remove public copies that you control and review who could access the archive or startup field. Ask Klei or CloudExa support for the supported replacement process if the account interface is unclear. Reinstalling the game or creating a new world does not address an exposed credential.

## Related help and sources

- [Keep your CloudExa account secure](https://help.cloudexa-hosting.com/books/billing-support/page/keep-your-cloudexa-account-secure)
- [Invite a teammate to your game server](https://help.cloudexa-hosting.com/books/getting-started/page/invite-a-teammate-to-your-game-server)

[Klei command-line and token documentation](https://support.klei.com/hc/en-us/articles/360029556192-Dedicated-Server-Command-Line-Options-Guide); [Klei account service](https://accounts.klei.com/).

# Connect Don't Starve Together Master and Caves shards

A Don't Starve Together world with forest and caves runs multiple dedicated server processes. Treat the Master and Caves shards as parts of one cluster while keeping their process identities and ports separate. A forest that accepts players does not prove that the caves process exists or can communicate with it.

## Check the supported cluster layout

Klei's command-line guide describes a shared `cluster.ini` with a separate `server.ini` beneath each shard directory. Its two-level example uses the same cluster name with `-shard Master` and `-shard Caves`. Your hosting template may use different storage paths, so inspect its effective options before copying files into a guessed directory.

Use settings generated through Klei's supported server configuration workflow as your starting point. Keep the shared settings and each shard's local settings together. Do not overwrite an established world's configuration with a newly generated world just to repair a cave connection. Preserve the original files and saves before making an adjustment.

## Compare identities and allocations

1. Record the cluster name and storage root used by each process. Both should point to the intended cluster, with the appropriate separate shard directory. Ask support if your panel presents the shards as separate services or split servers.
2. Download the shared configuration and each shard's settings. Inspect the current generated shard configuration as a pair, including its communication settings, without publishing passwords or tokens.
3. Compare the assigned game ports with the effective startup values. Klei requires distinct listening ports for servers on the same machine and documents separate Steam-related ports as well. Use only allocations the panel assigns; request additional ones if needed.
4. Stop both shards for configuration changes. Correct the specific mismatch you found and keep the rest of the established cluster unchanged.
5. Start the cluster through its supported controls. Inspect both shard logs for successful startup and connection errors before asking players to travel.

## Verify travel in both directions

Use a volunteer with expendable inventory to enter the caves through an ordinary world entrance and return to the forest. Record the time and outcome for both transitions. Inspect the logs from both shards around that time. A lobby listing or a successful direct connection to one process cannot establish that shard-to-shard travel works.

Watch resource use with both processes active. Klei warns that hosting forest and caves together needs more computing capacity. Avoid a large mod change during this test, since a mod error could resemble a travel problem. If only one player fails, collect their client error before changing the whole cluster.

## Recover from an unsuccessful edit

Stop both processes and restore the saved configuration pair if travel regresses. Keep current world data and logs intact. Do not regenerate caves or delete a shard directory as a connection fix; that can replace part of an established world. Escalate with redacted startup options, allocated ports and both timed logs so support can inspect the actual communication path.

## Related help and sources

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

[Klei shard layout and port options](https://support.klei.com/hc/en-us/articles/360029556192-Dedicated-Server-Command-Line-Options-Guide); [Klei forest and caves hosting guidance](https://support.klei.com/hc/en-us/articles/360029557132-Does-Don-t-Starve-Together-have-caves-or-ruins-content).

# Back up a Don't Starve Together cluster as one checkpoint

Back up a Don't Starve Together forest and caves cluster together. Players can move between shards, so a copy of only the forest directory may omit state needed for a coherent recovery. Arrange a short stopped interval for both processes and preserve the shared configuration alongside the shard data.

## Map the live cluster before copying

Klei defines the active storage path through the startup options for persistent storage, configuration directory, cluster and shard. Record those effective values for both processes. The usual names Master and Caves help describe a layout, but a hosting template may place the cluster elsewhere or use custom names. Find the live files before choosing what your panel backup should include.

Check which directories the backup feature actually covers. If the shards live in separate services, a backup action on one service may not include the other. Ask support for a paired checkpoint method when your available controls cannot cover the full cluster. Keep token-containing configuration private when you download or share an archive.

## Capture a single maintenance checkpoint

1. Tell players the planned pause and ask them to leave. Record the game build, mod set, cluster identity and time. Keep notes of representative player state in the forest and caves for later verification.
2. Stop both shards through their supported panel controls and wait for each process to exit. Do not copy one shard while players continue changing the other.
3. Create the complete cluster archive or the documented paired archives. Include the shared settings and the relevant shard data. Label separate files as one checkpoint with the same date and maintenance reference.
4. Wait for each backup job to finish. Record completion status and size, then retain an off-server copy or confirm that your plan stores the completed archives on the backup service.
5. Start both shards and verify ordinary joining and travel. A backup maintenance task should leave players on the original world unless you have separately agreed a restoration.

## Check recovery on an isolated copy

Use separate storage and ports for a restoration rehearsal. Stop its processes before loading the checkpoint, restore the shared settings and matching shard data, then adapt only the test-specific access and network details. Prevent ordinary players from confusing the rehearsal with production. Verify known characters, world progress and travel in both directions.

Keep your recovery notes with the archive. Include the build, required mods and the relationship between paired files. A successful download proves that you retrieved bytes; it does not establish that the checkpoint can load or that it includes the caves. Record any part of the verification you could not perform.

## Handle a real rollback carefully

Preserve a fresh copy of the current cluster before restoring an older checkpoint. Stop both shards and choose the agreed pair together. Restoring only one shard can create mismatched progress, so involve support if one archive is missing or damaged. Tell players the chosen recovery time and the progress they may lose. Do not delete the current cluster while you are still establishing whether the older copy is complete.

## Related help and sources

- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

[Klei cluster and shard path documentation](https://support.klei.com/hc/en-us/articles/360029556192-Dedicated-Server-Command-Line-Options-Guide); [Klei shard-specific log locations](https://support.klei.com/hc/en-us/articles/360029881191-Logs-and-Useful-Information-for-Bug-Reports-for-Don-t-Starve-Together).

# Prepare Don't Starve Together dedicated server mods for both shards

Subscribing to a Don't Starve Together Workshop mod on your own computer does not prove that a hosted dedicated cluster has downloaded or enabled it. Review the mod's server requirements and test both forest and caves before inviting players. Keep the working world and its previous mod settings recoverable throughout the trial.

## Separate client and server requirements

Klei's mod guidance distinguishes Server and Client mods in the game's hosting interface. Read the Workshop author's installation instructions to determine which category applies and whether the mod supports dedicated servers and caves. Record the Workshop item, version information available to you and any required dependencies. Avoid substituting a similarly named mod.

Ask support which dedicated-mod workflow your panel template supports. It may expose a mod download list and separate activation settings, or expect files prepared through the game's own hosting interface. Do not assume the template reads the same personal Workshop folder your desktop client uses. Keep this distinction clear when reporting a missing mod.

## Prepare a controlled two-shard test

1. Download the current cluster configuration and make a full checkpoint of forest and caves. Record the working mod list and preserve any existing mod-specific data.
2. Create an isolated test cluster or arrange a maintenance trial with expendable data. Stop both shards before changing their configuration.
3. Add one compatible server mod through the panel's supported download and activation controls. Follow the mod author's documented shard requirements; do not assume that enabling it on Master automatically configures Caves.
4. Start the test and inspect each shard's log for the mod load and the first error. A download-complete message does not establish that Lua configuration parsed or that the mod activated.
5. Join with the required client setup, exercise the intended feature in the forest, travel to the caves and repeat the relevant check. Record where behaviour differs.

## Keep diagnostics specific

Collect the first relevant error from each affected shard and the client's message at the same time. Klei identifies separate server-log locations for Master and Caves. Redact tokens and private account details before sharing them. If a dependency fails, record that failure before adding more mods or changing unrelated world options.

Check with an ordinary player as well as an organiser. Client-only interface behaviour can look different from a server feature, and an administrator account may conceal a permissions problem. Keep the original working set written down, including activation options, so you can compare a later update without relying on memory.

## Remove a trial without losing world data

Read the author's removal instructions before disabling a mod that adds entities, characters or persistent mechanics. Use a copied world to assess that removal if the live world already contains its content. Klei notes that mods can prevent dedicated-server startup, but disabling everything on a valued save is not a complete recovery plan. Restore the recorded configuration and matching checkpoint when necessary, and preserve the failed test logs for support.

## Related help and sources

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Open a support ticket](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket)

[Klei client and server mod guidance](https://support.klei.com/hc/en-us/articles/360029556512-How-do-I-download-mods-for-Don-t-Starve-Together-Steam); [Klei diagnostic log guidance](https://support.klei.com/hc/en-us/articles/360029881191-Logs-and-Useful-Information-for-Bug-Reports-for-Don-t-Starve-Together); [Klei mod-related startup failures](https://support.klei.com/hc/en-us/articles/4407489414548-Getting-a-Dedicated-Server-Failed-To-Start-Error-Message).

# Configure an ARK Survival Evolved server and verify the first connection

ARK: Survival Evolved and ARK: Survival Ascended are separate games. Start by checking the installed server title and your client edition. An Ascended map name, mod instruction or crossplay assumption is not a reliable setup instruction for Evolved.

## 1. Record the existing deployment

Open your game service and record its public address, assigned game port, server build and selected map. Check whether it already contains a world before changing anything. For an existing community, arrange a maintenance window and keep a completed backup of the saved data and configuration. Do not use reinstall or create a replacement world just to rename the server.

If you are joining from a different storefront or console, confirm that the actual dedicated-server deployment supports that platform combination. The fact that two products share the ARK name does not establish compatibility.

## 2. Identify the configuration in use

For standard Linux Evolved installations, the INI directory is `ShooterGame/Saved/Config/LinuxServer/`; Windows uses `WindowsServer` in the corresponding location. Your panel template may generate these files or supply launch options, so check its existing startup values before editing a second copy.

Stop the game normally before editing configuration and wait for it to finish. Download the current file first. Most basic settings belong in `GameUserSettings.ini`, while more advanced gameplay settings can belong in `Game.ini`. Keep the existing sections and unrelated values intact.

## 3. Change only the intended identity settings

A minimal name example in `GameUserSettings.ini` is:

```
[SessionSettings]
SessionName=CloudExa Evolved Community
```

Change the existing entry rather than adding competing copies. The join password and administrator password are different settings: `ServerPassword` and `ServerAdminPassword` under `[ServerSettings]`. Use distinct private values and do not include them in screenshots. Renaming the advertised session is not a request to change its map.

## 4. Check the assigned port set

Evolved's reference defaults are UDP 7777 for gameplay, its associated UDP peer port at game port plus one, and UDP 27015 for Steam queries. Optional RCON is a separate TCP endpoint. These are reference defaults, not permission to claim unassigned ports. Use the actual allocations and template mappings supplied for your service. Ask support if the required companion allocation is missing; do not guess another customer's port.

## 5. Start and verify

Start the game once and watch for startup errors before asking players to join. Test with a compatible ordinary player account using the supplied connection details. Confirm the displayed name, intended map and password behaviour. A server-browser listing alone does not prove the world finished loading.

If old settings reappear, compare the edited file with the running template's configuration source. Restore only the changed values if the test fails. Send support the server ID, build, allocated ports and redacted startup error; preserve the world while the configuration source is checked.

## Related CloudExa guides

- [Protect game files before changing settings](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Follow the game connection checks](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## Official references

- [ARK Official Community Wiki: dedicated server setup](https://ark.wiki.gg/wiki/Dedicated_server_setup)
- [ARK Official Community Wiki: server configuration](https://ark.wiki.gg/wiki/Server_configuration)

# Diagnose ARK Survival Evolved startup and joining failures without wiping

Separate an Evolved server that never finishes starting from one that starts successfully but refuses a player. Wiping a world cannot repair a missing network allocation or incompatible client. Keep the failure evidence and current save while finding which stage breaks.

## 1. Capture one attempt

Record the UTC time, client edition and storefront, server build, selected map and exact error. Save the first relevant startup error, not only the final shutdown line. If the process remains running, avoid repeatedly pressing start: loading a large world or completing a mod update can take time, and repeated interventions obscure the original event.

A panel websocket failure is a separate symptom. If the console itself cannot connect, report that alongside the game status instead of assuming a blank console proves the game stopped.

## 2. Check startup before networking

Review the existing startup configuration for a changed map, missing content or a mistyped file path. Confirm that the installation is ARK: Survival Evolved, not Ascended. Compare the current configuration with your last working copy and any recent changes. Do not replace all INI files with a template from another game.

Check available storage and the timestamps of the current configuration. A failed update or inability to save needs investigation before more restarts. Keep the active save directory, player data and mod data together in your recovery copy; do not remove unfamiliar files to make an error disappear.

## 3. Distinguish discovery from gameplay

The Evolved reference setup uses a UDP game port, an associated UDP peer port at game port plus one, and a separate UDP query port for Steam's browser. RCON uses TCP and is not a player's joining endpoint. Compare the actual panel allocations and startup mappings, not just the familiar default numbers.

If the server appears in a browser but joining times out, query visibility has proved only part of the path. If it is absent from the browser but the supplied direct connection method works, focus on discovery, filters and the query mapping. Do not disable the firewall or publish every port as a diagnostic shortcut.

## 4. Compare client and content compatibility

Check that the player is launching the correct ARK title and a compatible build. Record the configured mod IDs and their order before comparing them with the client's required content. A modded community may have additional storefront restrictions; verify those against the exact deployment rather than promising crossplay from a server name.

Use an isolated test service if you need an unmodded comparison. Removing mods from the only production copy and loading its world can affect mod-provided content. A controlled test must use separate save data and a separate assigned endpoint.

## 5. Verify and escalate

After one identified correction, make one new connection attempt and compare its timestamp with the server log. Confirm the expected world loads and that an existing player retains the expected character and ownership. Successful process startup alone is incomplete verification.

Send CloudExa support the service ID, failure stage, client platform, server build and redacted relevant log lines if the cause remains unclear. State which changes preceded the incident. Do not delete the world or reinstall while support is correlating the error with its network and startup configuration.

## Related CloudExa guides

- [Protect game files before changing settings](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Follow the game connection checks](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## Official references

- [ARK Official Community Wiki: dedicated server network requirements](https://ark.wiki.gg/wiki/Dedicated_server_setup)
- [ARK Official Community Wiki: Evolved and Ascended configuration distinctions](https://ark.wiki.gg/wiki/Server_configuration)

# Claim and connect to a Satisfactory dedicated server safely

Satisfactory's in-game Server Manager is where you connect to and administer a dedicated factory. Your CloudExa panel account and the game's administrator password have different roles. Work through one owner connection before inviting everyone, especially if the service already contains an imported factory.

## 1. Confirm the server you are opening

Open your service in the game panel and record its assigned address, standard game port and any separate reliable-messaging allocation. Check the console for a completed startup rather than assuming that a running status means a factory has loaded. Compare the server and client release branches; do not switch a live factory to an experimental branch just to make a connection attempt.

For an existing service, take a completed backup before changing sessions or configuration. Note the current session name and save timestamp. If you expected an established factory but see a first-time setup screen, stop and confirm the address and save selection instead of creating a replacement world.

## 2. Add the service in the game

1. Open Satisfactory and select **Server Manager** from the main menu.
2. Add the address and standard port assigned to your service.
3. If this is a genuinely new, unclaimed server, follow the claim process to choose its name and set a unique administrator password.
4. Use the manager to select the intended session or create the first factory only when the service is meant to be empty.

Keep the administrator password in a password manager. Player access protection is a separate choice: set a player password when you want an invitation-only factory, and share that credential rather than the administrator credential.

## 3. Understand the network allocations

For the documented 1.1-and-later networking model, the standard port carries TCP and UDP traffic, and reliable messaging uses another TCP port. Defaults are 7777 and 8888, but your assigned allocations take precedence. These numbers describe the game, not permission to use unallocated ports on a shared host.

Older instructions mentioning only the former 15000 and 15777 ports do not describe this current layout. If the service lacks a required allocation or the advertised reliable port does not match its public mapping, ask support to check the template. Avoid editing host firewalls or copying a home-router forwarding recipe into a managed service.

## 4. Verify the factory before sharing it

Join with an ordinary player connection and check the session name, expected buildings and player access. Make a small permitted change and confirm that normal saving succeeds. Then disconnect and reconnect once; an administrator screen alone is not a gameplay test. Review the intended auto-load session and save behaviour before relying on unattended restarts.

Keep administrator, session and backup details private when posting screenshots. If connection or claiming fails, send support the server ID, client/server versions, assigned ports, timestamp and exact error. Do not delete server settings or save files to force the claim screen to reappear.

## Related CloudExa guides

- [Protect game saves before changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Follow connection diagnostics](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## References

- [Coffee Stain dedicated-server support](https://www.satisfactorygame.com/support/)
- [Developer-recommended Satisfactory dedicated-server wiki](https://satisfactory.wiki.gg/wiki/Dedicated_servers)

# Diagnose Satisfactory Server API errors and stalled joins

A Satisfactory service can appear in Server Manager yet fail when you join. The manager, gameplay traffic and reliable messaging do not all test the same network path. Start by identifying the last step that works, so a port problem does not lead to an unnecessary factory reset.

## 1. Save the exact symptom

Record whether the server cannot be added, reports a Server API failure, rejects a password, or remains on a loading screen after joining. Include the UTC time and whether every player is affected. Copy the displayed wording rather than describing all four cases as “offline”. Keep the service address and server ID together to avoid investigating another instance.

Check the game-panel console separately. An unavailable web console can be a panel connection fault; it does not establish that the Satisfactory process has crashed. Read a fresh startup log if one is available and note whether it names the expected session.

## 2. Compare the connection paths

Check the standard-port allocation and reliable TCP allocation against the startup configuration and current server log. Being visible to the manager does not prove the reliable channel is reachable. A TCP-only external checker cannot establish that UDP gameplay traffic works, either.

If the service recently moved, have support compare the public mapping with the advertised reliable port. Do not repeatedly increase client timeouts to hide a missing route. Use assigned ports; opening a broad range or changing the default port without updating the template can introduce another fault.

## 3. Separate version, credentials and session state

1. Compare client and dedicated-server versions and release branches. Record a mismatch before planning an update.
2. Confirm that the entered password is the required player or administrator password for that action.
3. Check whether the manager reports the intended factory as loaded, rather than merely showing a reachable server.
4. Try one other authorised player on a different connection to distinguish a local issue from an instance-wide failure.

Do not share an administrator password as a workaround for ordinary joining. If only one player fails, collect that player's exact error and platform details before changing a working server for everyone.

## 4. Investigate load or crash evidence

For a join that stalls while the factory loads, compare console progress, memory use and the last useful log entry. A large factory can take time; a repeated crash or unchanged error requires investigation. Avoid rapid stop/start attempts, which can interrupt the same load repeatedly and obscure the original sequence.

If a configuration change preceded the incident, compare it with your saved copy and reverse only that change through a controlled maintenance step. Do not clear the save directory, remove server identity files or reinstall to test whether the network works. Keep a recoverable checkpoint before any repair.

## Confirm recovery

A useful result is a successful manager connection followed by an ordinary player joining the correct factory, moving normally and reconnecting. Send support the failing stage, timestamp, assigned ports, versions and redacted startup excerpt if the distinction remains unclear. Coffee Stain's support page points operators to its dedicated-server wiki and issue-reporting route; hosting-specific mapping still needs CloudExa investigation.

## Related CloudExa guides

- [Diagnose a panel console connection](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-a-game-console-that-will-not-connect-or-shows-a-504-error)
- [Keep a game backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## References

- [Developer-recommended dedicated-server troubleshooting](https://satisfactory.wiki.gg/wiki/Dedicated_servers)
- [Satisfactory configuration reference](https://satisfactory.wiki.gg/wiki/Dedicated_servers/Configuration_files)
- [Coffee Stain support and issue reporting](https://www.satisfactorygame.com/support/)

# Set up and join a DayZ server without changing its existing world

Start with a small DayZ configuration change and a successful player connection before adding mods or changing the mission. This guide covers a PC dedicated service. A client for a different platform or release branch should not be assumed compatible. The paths shown by the game panel depend on the installed server template.

## 1. Record the service and preserve its state

1. Open the correct game service and note its assigned address, game port and any separate query allocation.
2. Record the current server build, selected mission and startup settings.
3. If the service already contains player progress, take and verify a backup before editing. Keep the current configuration and the mission's persistent data together.

A server that appears new to you may already contain somebody's characters or bases. Do not replace its mission folder with a downloaded starter folder, rename its persistence directory, or use an installation action as a setup shortcut.

## 2. Locate the configuration actually used

DayZ selects its configuration through the startup `-config` argument. A file called `serverDZ.cfg` is common, but editing that filename will do nothing if startup points elsewhere. Check the configured path rather than creating a second file with a familiar name.

For an initial identity change, adjust the existing `hostname` entry. The joining password and administrator password serve different purposes; use different secrets and keep the administrator value private. Preserve the rest of the file and its syntax. Do not copy an entire internet example over a working configuration just to change the name.

## 3. Keep game and query endpoints distinct

The startup `-port` value controls the server listening port; `steamQueryPort` is a separate configuration setting for browser queries. Use the values assigned to your service rather than assuming a default or claiming a neighbouring port. If startup and allocations disagree, ask support to reconcile them before changing networking.

The DayZ client needs the game's connection endpoint. A query result, RCON login or working browser console is not a substitute for a player joining. You do not need to change your home router's port forwarding to connect to a hosted server.

## 4. Start and validate a normal player session

Apply changes during an agreed maintenance window using the service's supported stop/start procedure. Bohemia recommends graceful shutdown to protect character and storage saves; avoid a forced kill. Read the fresh startup output for the expected mission, then join using the assigned address and game port.

Confirm the advertised name, joining password and intended world with an ordinary player account. On an existing world, check known progress rather than assuming an empty-looking spawn is correct. If the mission differs, stop before further play changes that state.

## When to ask for help

Send the service ID, build, assigned endpoints, startup configuration path and exact failure time. Redact passwords. A first connection failure does not justify deleting persistence or reinstalling; preserve the current state while support checks the failing stage.

## Related CloudExa guides

- [Back up game files before changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Follow the player connection checks](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## Official references

- [Bohemia: DayZ server configuration](https://community.bistudio.com/wiki/DayZ:Server_Configuration)
- [Bohemia: graceful server shutdown](https://community.bistudio.com/wiki/DayZ:Server_Messages)

# Diagnose DayZ startup, mod and joining failures without wiping persistence

A DayZ service can be running while a particular client cannot enter it. First distinguish a server process that exits, a connection that never reaches the game, and a player rejected during login. Each needs different evidence; deleting the world's storage can destroy progress without fixing any of them.

## 1. Preserve the complete error

1. Copy the full client error code, message and any named file. Save the UTC time of one attempted connection.
2. Record whether every player is affected or only one person, and whether the problem followed an update or mod change.
3. Check fresh server output from that same attempt. Keep a private copy before another restart overwrites useful context.

Bohemia's error reference separates connection problems, server rejections and kicks. A code alone is less useful than the code plus its additional text. Avoid repeatedly retrying while the server is deliberately shutting down or updating.

## 2. If the process does not remain running

Start with the first substantive startup error, not the final message saying the process stopped. Check the configuration path selected by `-config` and the profile directory selected by `-profiles`. The profile directory is also where server logs are normally written; a template can choose its own location.

Look for a missing file, malformed configuration, failed mission load or a mod path that does not match the files present. Preserve the last known working startup settings for comparison. Do not clear all logs, replace the whole server folder, or treat a crash loop as proof of a damaged save.

## 3. If it runs but cannot be reached

Recheck the assigned game endpoint and any separately allocated query endpoint. A successful browser listing only proves that the query path returned information. Conversely, an absent listing does not prove that direct player traffic is impossible. Give support the exact address and port you tested rather than opening a broad port range yourself.

Compare client and server release branches and builds before troubleshooting mods. If another player can enter using the same endpoint, compare the failing client's build, enabled content and full rejection text instead of immediately changing the server.

## 4. If the error names a mod or signature

Match the named PBO and Workshop item to the intended server mod set. Bohemia documents mod loading through `-mod` and public signing keys in a mod's Keys folder. Review the affected mod's installation instructions and dependencies on a test copy before changing production.

Do not disable signature verification, BattlEye or authentication to make the error disappear. Do not delete every mod and reinstall the collection over a live world. Some content changes affect stored items or scripted systems, so keep the matching world and mod-data checkpoint before a controlled correction.

## Verify one correction at a time

Repeat the same player's connection and check that the expected character and world remain intact. Escalate with the first startup error or full rejection, UTC time, server build and recent changes. Share raw logs privately because they can contain player identifiers and server paths.

## Related CloudExa guides

- [Choose the next safe startup check](https://help.cloudexa-hosting.com/books/game-hosting/page/game-server-will-not-start-choose-the-next-safe-check)
- [Separate a panel-console fault from game availability](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-a-game-console-that-will-not-connect-or-shows-a-504-error)

## Official references

- [Bohemia: DayZ error-code reference](https://community.bistudio.com/wiki/DayZ:Error_Codes)
- [Bohemia: launch configuration and profile logs](https://community.bistudio.com/wiki/DayZ:Server_Configuration)
- [Bohemia: DayZ mod structure](https://community.bistudio.com/wiki/DayZ:Modding_Structure)
- [DayZ staff: reporting connection errors](https://forums.dayz.com/topic/259833-error-codes-pc-official-servers/)

# Configure and join an Unturned server using its assigned connection method

Unturned supports several connection methods, so a server's assigned public address, Steam Server Code and Fake IP should not be treated as interchangeable. Confirm how your service is configured before publishing an address to players. This guide covers the PC dedicated server, not an assumed console crossplay setup.

## 1. Identify the existing server instance

1. Open the correct CloudExa game service and record its assigned endpoint and startup identity.
2. Find the corresponding directory beneath `Servers`. A default local installation may use `Servers/Default`, but a hosted template can use a different name or working directory.
3. Preserve the existing instance folder and verify a backup before editing a service with progress.

Do not rename the server identity or switch maps to make a first connection work. Those changes can make the service load different state and hide the world you intended to keep.

## 2. Make a small configuration change

Basic settings belong in the instance's `Server/Commands.dat`. For example, this identity-only line illustrates the format; retain your existing file and other settings:

```
Name CloudExa Friends
```

Commands are separate lines rather than JSON properties. Check the active instance before editing. Gameplay configuration uses `Config.txt` on newer server folders; older installations may originate from `Config.json` and generate difficulty-specific text files. Follow the format your server actually loads instead of creating a competing file.

## 3. Choose the connection path already provisioned

For direct public-IP access, use the service's assigned port configuration. Unturned's direct networking uses a consecutive UDP pair: the configured base is used for queries and the next port for gameplay. Both need the correct hosting allocations; do not assume you own the next port just because it is numerically adjacent.

A Server Code can instead be entered in the client's Connect Directly interface. It is a 17-digit code shown after loading and can change between sessions unless linked through a login token. Fake IP is another Steam-relayed method and advertises its own address. Ask support which method your template uses if the panel endpoint and console information differ.

## 4. Protect the login token and world

Internet listing requires the server's Game Server Login Token. SDG documents creating it for app ID `304930` and configuring it through `Login_Token` or the startup `GSLT` command. Treat it as a secret and never post it with a connection guide or screenshot.

Before maintenance, use the supported save-and-shutdown process. The base server does not provide built-in autosaving, so verify any panel or plugin schedule rather than assuming progress is being saved automatically. A completed file backup and an in-game save serve different purposes.

## Verify player access

After a controlled start, wait for level loading to complete and test the intended connection method with a normal player. Check the server name and existing progress. If it fails, send support the method used, current advertised endpoint, server ID and error text, keeping tokens and passwords private.

## Related CloudExa guides

- [Protect existing game files](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Work through player connection checks](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## Official references

- [SDG: server setup, configuration and saving](https://docs.smartlydressedgames.com/en/stable/servers/server-hosting.html)
- [SDG: current and legacy configuration formats](https://docs.smartlydressedgames.com/en/stable/servers/server-configuration.html)
- [SDG: direct networking ports](https://docs.smartlydressedgames.com/en/stable/servers/port-forwarding.html)
- [SDG: Server Codes](https://docs.smartlydressedgames.com/en/stable/servers/server-codes.html)
- [SDG: Game Server Login Tokens](https://docs.smartlydressedgames.com/en/stable/servers/game-server-login-tokens.html)

# Troubleshoot an Unturned server missing from the list or rejecting players

Unturned being absent from the Internet list is not the same as its process being offline. A service can accept a Server Code connection while remaining anonymous, and a listed server can still reject a particular client. Test the intended access method before changing network settings or deleting files.

## 1. Check whether the level finishes loading

1. Save the first relevant error from a fresh startup and the time it occurred.
2. Identify whether startup is still loading a level or downloading content, whether it exits, or whether it becomes ready but a client cannot enter.
3. Note the last configuration or Workshop change. Compare with the preserved working settings before making another change.

Do not force-stop a server merely because a large content download is quiet for a short period. If output stops progressing, provide the last lines and elapsed time to support. A working web console does not establish that the game has completed its own startup.

## 2. Separate listing identity from connectivity

A server without a configured Game Server Login Token is anonymous and hidden from the Internet list. Check the token configuration privately; a valid token is not a password to distribute to players. Review any authentication failure in startup output and consult the SDG server-standing information if a listing warning appears.

Do not rotate tokens repeatedly or reuse a working server's token as a quick experiment. A change to server identity can confuse players who already have a saved connection method. Preserve the original non-secret settings and have the token owner correct the relevant account configuration.

## 3. Re-test the correct connection method

For a Server Code, obtain the current code from the running instance rather than an old message. Codes can change after restart. For Fake IP, use the currently advertised Fake IP and port; SDG notes that this endpoint changes between restarts and differs from the VPS's real address.

For direct IP joining, confirm the service's public address and configured consecutive UDP allocations with support. Query replies and gameplay traffic use different ports in the pair. Do not disable the firewall, forward your home router, or claim an unassigned neighbouring port to investigate a hosted service.

## 4. If the client fails while loading content

Review the instance's `WorkshopDownloadConfig.json` against the intended collection. SDG uses its `File_IDs` list for Workshop downloads, with required content handled during startup and client joining. A Workshop item ID is not the same thing as the map name selected by the server.

Read the named item or dependency error before changing the list. Preserve the file and matching save checkpoint. Avoid removing all Workshop content, switching maps or clearing player data as a broad test: stored items and world content may depend on the removed package. If needed, reproduce with a separate test instance and a separate save.

## Confirm recovery and escalate

Repeat the original join using the same method and a normal player, then confirm the expected world and inventory. Send support the service ID, startup stage, connection method, UTC attempt time and redacted error. If only one client fails, include its build and content differences; never include the GSLT or private account credentials.

## Related CloudExa guides

- [Investigate a stopped or failed game process](https://help.cloudexa-hosting.com/books/game-hosting/page/game-server-will-not-start-choose-the-next-safe-check)
- [Troubleshoot the panel console separately](https://help.cloudexa-hosting.com/books/game-hosting/page/fix-a-game-console-that-will-not-connect-or-shows-a-504-error)

## Official references

- [SDG: loading and Workshop configuration](https://docs.smartlydressedgames.com/en/stable/servers/server-hosting.html)
- [SDG: anonymous servers and login tokens](https://docs.smartlydressedgames.com/en/stable/servers/game-server-login-tokens.html)
- [SDG: Fake IP endpoints](https://docs.smartlydressedgames.com/en/stable/servers/fake-ip.html)
- [SDG: Server Code lifecycle](https://docs.smartlydressedgames.com/en/stable/servers/server-codes.html)
- [SDG support: missing server listings](https://support.smartlydressedgames.com/hc/en-us/articles/16050989363732-Why-isn-t-my-server-visible-on-the-server-list)

# Authenticate a Hytale server and check the first connection

A newly started Hytale process needs a valid runtime, complete server files, an authorised server session and a reachable game endpoint before players can join. Follow the current Hytale documentation for your installed release; do not reuse Minecraft startup arguments or an older installation recipe.

## 1. Check the installed service before changing it

1. Open your Hytale service in the game panel and note the assigned address, game port and current startup output.
2. Confirm that this is the intended server and that no existing world is about to be replaced. Keep a completed backup before altering an established installation.
3. Check the runtime against the current official manual. At this guide's review, Hytale specifies Java 25. Ask support to confirm the template if the console shows an unsupported-runtime error.

The publisher's self-hosting download instructions are not a request to run an installer inside an existing hosted server. Preserve the launcher and directory layout provided for the service.

## 2. Establish who manages authentication

The publisher supports both interactive console authentication and hosting-provider session management. First inspect the console: if authentication is already supplied by the host, do not replace tokens or sign it out. Ask support which method the service uses when the status is unclear.

For a server explicitly using your own interactive authentication, the documented console check and device flow are:

```
/auth status
/auth login device
```

Use the login command only when that method is appropriate for your service. Follow the fresh verification address and code shown by your own console, approve the intended account, then wait for confirmation. Treat the device code and resulting credentials as secrets. Never approve a code someone sent without establishing what session it authorises.

## 3. Verify the correct network endpoint

Hytale gameplay uses QUIC over UDP. Check the port assigned to this service rather than substituting the manual's default. A successful TCP-only port checker cannot establish that this game's UDP path works. Managed game hosting does not require you to change the hypervisor firewall or forward ports on CloudExa's router.

Use the connection address supplied for this server, including its non-default port where required. Avoid adding a proxy or DNS workaround until a direct test of the assigned endpoint has succeeded.

## 4. Make a controlled first join

Keep the client and server on compatible releases. Start with the provided configuration and leave additional mods out of the first baseline test. Watch the console while an ordinary player joins; record whether the failure happens before authentication, during joining or only while the world loads.

Once connected, verify movement and normal interaction rather than relying on a brief loading screen. Let another authorised player test, then retain the working configuration. Before a later update or restart, check the service's backup and authentication arrangements so a recovery copy does not expose session credentials.

## When to ask support

Send the server ID, build information, exact redacted error and UTC test time if authentication or the assigned endpoint is uncertain. Do not paste tokens into tickets or switch to offline authentication to bypass a failed session. No reinstall or world reset is required merely to collect this evidence.

## Related CloudExa guides

- [Keep a recoverable game-server backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Choose the next connection or startup check](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks)

## Developer references

- [Hypixel Studios Hytale server requirements and networking](https://support.hytale.com/hc/en-us/articles/45326769420827-Hytale-Server-Manual)
- [Hypixel Studios server authentication methods](https://support.hytale.com/hc/en-us/articles/45328341414043-Server-Provider-Authentication-Guide)

# Diagnose Hytale authentication, UDP and world-loading failures

“Cannot connect” and “the world never loads” do not identify the same fault. A server may fail to start, lack an authenticated session, reject an incompatible client or accept a player whose network then struggles with world traffic. Record where the failure happens before changing the installation.

## 1. Capture a reproducible case

1. Note the server ID, assigned connection address, UTC time and complete client error.
2. Read the console around that attempt. Keep the first relevant startup error if the process never becomes ready.
3. Check whether one player, one network or everyone is affected. Compare another authorised player's normal join without asking anyone to share account credentials.

If only the game panel's console is broken, use the separate console troubleshooting guide. A browser websocket failure does not establish that Hytale itself stopped.

## 2. Separate runtime and authentication errors

For a startup failure, compare the configured runtime and complete server payload with the requirements for the installed Hytale release. Preserve the host's startup script instead of replacing it with a command copied from a different build. A Java error should be recorded before changing memory or runtime settings.

If logs point to authentication, use the documented `/auth status` console check. Provider-managed sessions and owner-managed device login are different workflows. When the provider supplies authentication, ask support to inspect that path. When you deliberately manage your own session, follow the publisher's current device-flow instructions from your own console.

Do not publish tokens, repeatedly sign a working server out, or disable authentication. A failed external session needs its underlying response investigated rather than a world reset.

## 3. Check UDP with the assigned allocation

Hytale's game connection uses QUIC over UDP. Compare the service's actual assigned endpoint with the address players entered. A TCP probe, a working website on the same IP or a successful connection to another server is not a test of this UDP route.

Give support the destination, protocol and incident time if the mapping is uncertain. Do not request broad firewall removal or alter the node's network settings. If the client and server were updated separately, record their build information and investigate compatibility before changing ports.

## 4. When the player connects but the world stalls

Hypixel documents a Windows network-adapter issue that can make server worlds load very slowly even when single-player and ordinary internet use appear healthy. This is a specific client-side possibility, not a diagnosis for every delayed join.

Compare a second device or a known-good adapter where available. If the symptom follows one Windows adapter, use the publisher's dedicated troubleshooting article with the device owner. Record original driver settings before any proposed change, test one adjustment at a time and preserve a way back. Avoid applying an entire list of adapter changes to every player or changing a remote management interface.

## Verify the result

After one supported correction, repeat the original join and confirm movement, interactions and sustained world loading. If only a modded installation fails, reproduce the comparison on a separately backed-up test copy rather than removing production mods blindly. Send support the failure stage, affected clients, build information and redacted log excerpt. Keep the original world and credentials intact.

## Related CloudExa guides

- [Keep a recoverable game-server backup](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Choose the next connection or startup check](https://help.cloudexa-hosting.com/books/game-hosting/page/game-server-will-not-start-choose-the-next-safe-check)

## Developer references

- [Hypixel Studios server manual](https://support.hytale.com/hc/en-us/articles/45326769420827-Hytale-Server-Manual)
- [Hypixel Studios authentication checks](https://support.hytale.com/hc/en-us/articles/45328341414043-Server-Provider-Authentication-Guide)
- [Hypixel Studios Windows slow-world-loading investigation](https://support.hytale.com/hc/en-us/articles/45419578597403-Slow-Connection-World-Not-Loading-on-Server)

# Choose a supported Palworld dedicated-server mod installation

A Palworld mod working in a player's game does not establish that it can run on your dedicated server. Start by identifying the server operating system, game build and mod distribution method. Keep your live world unchanged while you establish a supported combination.

## Check the platform before uploading anything

Pocketpair's [dedicated-server mod guide](https://docs.palworldgame.com/settings-and-operation/mod/) currently limits its server-side mod workflow to the Windows dedicated server. A native Linux service should not be treated as compatible simply because its files are accessible. Ask CloudExa to confirm the actual runtime if your template does not identify it.

UE4SS is a separate loader with its own requirements. Its [upstream documentation](https://docs.ue4ss.com/) describes Windows DLL loading and warns that compatibility is not automatic. A Windows DLL is not a Linux server extension. A Lua script or a file ending in `.pak` also does not establish dedicated-server support; inspect the author's requirements, dependencies and supported builds.

## Prepare a recoverable trial

1. Record the running game version, platform, existing loader and every installed mod. Save the mod authors' release links and version numbers.
2. Make a separate, downloadable backup of saves and configuration. Keep an unmodified checkpoint outside the directory used for the trial.
3. Read each author's server instructions. Identify whether players also need the mod and whether their platform can install it. Stop if those requirements are unclear.
4. Arrange a separate test installation and disposable world. Do not discover compatibility by opening your established world with missing content mods.

## Use the managed Windows workflow when applicable

For a supported Windows installation, Pocketpair documents Workshop packages under `Mods/Workshop` beside `PalServer.exe`. Each package folder must expose its `Info.json` directly. The enable list in `Mods/PalModSettings.ini` uses the manifest's `PackageName`, not the folder name. Check for server installation rules and required dependencies before enabling one package.

Have CloudExa confirm file access and the supported installation method before modifying executable or loader files. There is no universal panel button that makes every Palworld mod compatible. Keep an existing manual loader separate from a proposed managed installation until its migration requirements are understood.

## Validate one change at a time

Stop the test server cleanly, apply the selected package through its documented method, then start it and retain the complete startup log. A successful process start is only the first checkpoint: connect with a prepared client, exercise the mod's advertised feature, save the disposable world and confirm it survives a clean stop and start.

If startup fails before a client joins, investigate the server package, loader and dependencies. If the server is healthy but only one client fails, compare that client's build and required mods. Neither symptom justifies deleting a save.

## Keep rollback usable

Retain the previous compatible package set and configuration alongside the pre-change checkpoint. If a trial writes modded content into a save, return to the corresponding checkpoint rather than assuming disabling the mod reverses its changes. Schedule production changes only after the trial passes.

Related: [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes) and [Palworld platform compatibility](https://help.cloudexa-hosting.com/books/survival-games/page/check-palworld-crossplay-platforms-and-dedicated-server-compatibility).

# Diagnose Palworld mod update failures and client mismatches

After a Palworld or mod update, separate a server that cannot start from a running server that rejects a client. Those failures need different evidence. Preserve the last working world and package list before repeated starts make the original sequence harder to reconstruct.

## Record exactly what changed

1. Write down the last successful connection time and the first failed attempt, including the time zone.
2. Compare the game build, operating system, mod versions and loader version before and after the update. Include dependencies, not just the main gameplay mod.
3. Save startup output from the beginning through the first error. Keep client errors separately and remove credentials before sharing logs.
4. Keep a copy of the current failed state as well as the last known working checkpoint. Do not overwrite your only recovery copy while testing.

If the service was recently moved between Windows and Linux, treat that platform change as a compatibility question. The official server-mod workflow remains [Windows-only in Pocketpair's current documentation](https://docs.palworldgame.com/settings-and-operation/mod/). File transfer success does not prove a Windows extension can execute on a native Linux server.

## Follow the failure stage

**No normal server startup:** inspect the earliest loader, dependency or package error. Generic connection timeouts are expected when the server has not reached a usable state. Adding RAM or changing firewall rules will not repair a missing module.

**Server starts, mod does nothing:** compare the intended package with the manifest and enabled list. Pocketpair documents a generated `Mods/ManagedMods/<PackageName>/InstallManifest.json` after deployment. Its presence is evidence of deployment activity, not proof the feature works correctly.

**Only some clients fail:** list each client's game build, platform and installed package versions. Ask the mod author which components belong on clients. Do not assume console, Steam and other clients share the same mod installation capabilities.

## Check updates without mixing installations

For managed Workshop mods, Pocketpair explains that a changed manifest `Version` triggers redeployment on restart. Confirm which release you actually downloaded and keep the previous package archived. Do not combine unrelated manual DLL instructions with the managed layout to silence an error.

The [upstream UE4SS project](https://github.com/UE4SS-RE/RE-UE4SS) and each mod's own release notes are the appropriate references for loader compatibility. Experimental ports are separate projects; a fork reporting success does not establish support for the upstream runtime or your hosting template.

## Reproduce safely

Use a separate disposable world and add the required dependency chain before the affected mod. Connect with one prepared client, exercise the failing action, then perform a clean stop and start. Add other packages individually until the smallest failing combination is identified. Keep the log for both the passing and failing attempts.

Do not load an established modded world without its content dependencies just to see whether startup improves. That can change the saved state and makes a clean comparison unreliable. A mod-free baseline belongs in a fresh test world.

## Rollback or escalate with evidence

Restore a matching game, loader, package and save checkpoint only where those versions remain obtainable and compatible. If an update migrated the save, stop and ask for recovery guidance before downgrading. Send support the server ID, build list, first error and minimal reproduction; never include access tokens or passwords.

Related: [Update Palworld with a recoverable checkpoint](https://help.cloudexa-hosting.com/books/survival-games/page/update-palworld-while-preserving-a-recoverable-save-checkpoint) and [game-file backups](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes).

# Choose and install Satisfactory mods for a dedicated server

Satisfactory dedicated-server mods need builds intended for the server, not just a copy of a player's mod folder. Choose the packages against the actual game build and server operating system, then prove the combination in a disposable factory before changing your established save.

## Check the dedicated-server target

The [Satisfactory Modding project](https://docs.ficsit.app/satisfactory-modding/latest/ForUsers/DedicatedServerSetup.html) documents dedicated support through SML and Satisfactory Mod Manager. That does not mean every mod supports every target. Inspect the mod's current release page for the Windows or Linux server target matching your service, plus its dependency and game-version requirements.

A client compatibility badge or a successful single-player session is insufficient evidence. Record the exact game build, SML version, selected mod releases and server platform. If a required target is absent, choose another mod or wait for a compatible release instead of uploading client binaries experimentally.

## Protect the existing factory

1. Arrange a clean stop and create a downloadable checkpoint of your saves and configuration.
2. Keep a record of the active mod profile and its versions, including dependencies selected automatically by the manager.
3. Prepare a separate test installation and new world. Do not use an established factory as the first compatibility test.
4. Read the author's notes about whether the mod changes saved buildings or items and whether clients must install it.

## Connect the manager to the correct installation

Satisfactory Mod Manager supports remote installations through suitable file access. Use the credentials and allocated file-transfer port supplied for your own service; a generic example port is not your allocation. Confirm support with CloudExa if executable access or the required installation files are restricted.

In the manager's own interface, add the remote server and locate the installation containing `FactoryServer.sh` or `FactoryServer.exe`. This is a mod-manager operation, not a promised CloudExa panel control. Keep its server profile clearly named so that a client profile is not accidentally applied to the remote service.

## Apply a small, supported package set

Stop the test instance before file changes. Select one compatible mod and its dependencies, review the proposed changes and apply them to the intended server installation. Check the mod author's client requirements independently rather than assuming that every client-only convenience mod belongs on the server.

The project's [manual installation documentation](https://docs.ficsit.app/satisfactory-modding/latest/ManualInstallDirections.html) recommends using the manager because manual installation is error-prone. Avoid old instructions that treat all packages as interchangeable folders or mix loader generations. A copied file existing on disk is not a compatibility test.

## Confirm the result and preserve a route back

Read the next startup log from the beginning. Connect using a client with the required matching packages, test the specific feature, save the disposable factory, then stop and start cleanly. Verify that the factory and added content remain usable after reconnecting.

If the manager cannot recognise the installation, check its selected root and file permissions before changing mods. If startup reports a missing dependency, resolve that package requirement before investigating the network. Keep the previous package profile and pre-change save checkpoint; do not assume removing a content mod repairs a world already saved with it.

Related: [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes) and [Connect to a Satisfactory dedicated server](https://help.cloudexa-hosting.com/books/survival-games/page/claim-and-connect-to-a-satisfactory-dedicated-server-safely).

# Fix Satisfactory mod version conflicts after an update

A Satisfactory update can leave the game, loader and individual mods on different compatibility timelines. A stalled join does not identify which component is responsible. Start with a version comparison and a protected checkpoint, then reproduce the problem outside your live factory.

## Build a before-and-after record

1. Record the exact server game build and branch. Compare them with the affected client's build.
2. Export or record both mod profiles, including SML and dependency versions. Include a release link for each package.
3. Identify the server operating system. A package available for one dedicated-server target may be unavailable for another.
4. Capture complete client and server startup logs for one failed connection, noting its time and time zone.

Keep both the last working checkpoint and a copy of the current configuration. Avoid updating every dependency again before recording the failure: that removes useful evidence about which change introduced it.

## Read compatibility claims precisely

Use the [SML release page](https://ficsit.app/mod/SML) and each mod's own release information to check the game version and supported targets. The newest package is not automatically the right one for a server that remains on an older build. Do not install development artifacts merely because they have a later version number.

The [upstream manual-install guide](https://docs.ficsit.app/satisfactory-modding/latest/ManualInstallDirections.html) requires an SML release compatible with the game. Its Linux manual instructions are explicitly incomplete, so old hand-copy recipes are a poor way to repair a managed Linux installation. Return to a coherent, supported manager profile rather than layering files from several tutorials.

## Separate startup and joining failures

If the server stops during loader initialization, compare dependencies and binary targets first. A missing library or incompatible package will not be repaired by changing the public port.

If the server reaches a usable state but a client cannot join, compare that client's required package set with the intended server profile. Client-only mods and server-capable mods are different categories; review the author's instructions before deciding that both folders must be identical.

If only a particular machine fails, reproduce with another prepared client on the same game build. If every client fails immediately after one package changed, that change becomes a useful lead, not proof that the world itself is damaged.

## Find the smallest failing combination

Prepare a separate new factory with a known-compatible baseline. Add the affected mod and its dependencies, restart cleanly, connect and test the failing action. Add other packages one at a time until the issue returns. Preserve logs and the profile at each meaningful checkpoint.

Do not perform this isolation by removing building or item mods from your established factory and saving it. A new test world answers the compatibility question without changing your production content. If the issue requires your real save to reproduce, keep that save isolated and ask support or the author before loading it with missing dependencies.

## Choose a safe recovery

Keep production on the last proven combination where supported, or wait for a compatible release. Roll back packages together with the corresponding configuration and save checkpoint when necessary. A game update that changed the save format can limit rollback; do not force a downgrade without checking.

Related: [Satisfactory API and stalled-join checks](https://help.cloudexa-hosting.com/books/survival-games/page/diagnose-satisfactory-server-api-errors-and-stalled-joins) and [backup preparation](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes).

# Install a compatible ARK Survival Evolved Workshop mod set

ARK: Survival Evolved uses a different mod ecosystem from Survival Ascended. Choose Workshop content explicitly intended for Evolved and your server platform. An Ascended CurseForge identifier is not interchangeable with an Evolved Steam Workshop ID.

## 1. Check the complete dependency set

Open each intended mod's original Workshop page. Record its numeric ID, author, required items, supported game branch and any warning about map conversion or existing saves. Check the author's documented order instead of assuming every collection supplies a safe sequence. A collection is a convenient inventory, not evidence that its members remain compatible.

Confirm that your client storefront supports this modded deployment. Do not promise modded crossplay merely because an unmodded connection worked. If a dependency or platform requirement is unclear, ask the mod author before allowing the production world to load with it.

## 2. Build a recovery checkpoint

Arrange a normal stop and retain the current save, player and tribe data, configuration and existing mod list together. Keep a copy of the current mod artifacts where licensing permits. A list of IDs alone may not recover an earlier Workshop release after its author updates it.

Use a separate test service with separate saves for a new content pack. A trial on the only production world can write new mod-owned objects before you know whether the pack is suitable. Confirm the available storage can accommodate the download, staging space and backup.

## 3. Identify download and activation controls

Your template may manage Workshop downloads. Verify that mechanism with the existing startup configuration or support; do not launch a second updater over the active installation. Obtaining the files and enabling them are separate tasks.

For Evolved, `ActiveMods` under `[ServerSettings]` in the active `GameUserSettings.ini` defines a comma-separated ordered list. Replace the placeholders with genuine verified IDs; this is configuration syntax, not a runnable command:

```
[ServerSettings]
ActiveMods=FIRST_WORKSHOP_ID,SECOND_WORKSHOP_ID
```

Edit the existing entry while stopped. Do not create competing copies or assume that changing an unused INI overrides template launch arguments. The Evolved `[ModInstaller]` mechanism in `Game.ini` uses individual `ModIDS` entries with `-automanagedmods`; only adopt it when it matches the supported deployment workflow.

## 4. Test before inviting players

Start the isolated copy once. Check that downloads finish, dependencies load and the intended map remains selected. Join with a matching client mod set and exercise a feature from each new mod. A server reaching a ready state does not prove an item, creature or crafting dependency works.

Stop and start the test copy normally, then confirm the test content persists. Keep the results and exact ordered IDs in your maintenance note before making the same controlled change to production.

## 5. Keep the rollback complete

If the trial fails, retain its logs and stop the test. Do not remove the mods and save over the original community world: mod-owned content may disappear. Restore a matching pre-change world and configuration only through a planned recovery. Send support the ordered IDs, template download behaviour and first startup error if activation remains unclear.

## Related CloudExa guides

- [Configure an ARK Survival Evolved server and verify the first connection](https://help.cloudexa-hosting.com/books/survival-games/page/configure-an-ark-survival-evolved-server-and-verify-the-first-connection)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [ARK Official Community Wiki: Evolved mod activation and installer settings](https://ark.wiki.gg/wiki/Server_configuration)
- [ARK Official Community Wiki: dedicated server deployment](https://ark.wiki.gg/wiki/Dedicated_server_setup)

# Update ARK Survival Evolved mods and diagnose a client mismatch safely

A Workshop update can leave an Evolved server and its players running different mod files. A failed join is not a reason to wipe the map or remove every mod. First distinguish a download failure, an activation error and a genuinely incompatible release.

## 1. Preserve the first useful evidence

Record the exact client message, UTC time, server build and whether the problem affects everyone or one player. Save the first relevant server error and the ordered Workshop IDs. Note what changed immediately before the incident: game update, mod update, new dependency or startup edit.

Check that the client is Evolved and that the selected storefront supports the modded setup. An Ascended installation cannot validate an Evolved Workshop pack. Browser visibility alone does not establish that the correct content loaded.

## 2. Compare three separate inventories

Compare the intended IDs in the active configuration, the files actually deployed by the supported updater, and the client content the player has loaded. `ActiveMods` is an ordered activation list; it is not proof that every required download completed. Installer entries can request content without activating it.

Read the updater's completion or failure messages. A folder timestamp can be a clue but is not a reliable release identifier by itself. Compare the affected author's release notes and required items. If the template provides an update check, use its documented workflow instead of running multiple download processes concurrently.

## 3. Plan one controlled update

Warn players, stop normally and keep a completed recovery checkpoint containing the matching world, player and tribe data, INI files and ordered mod list. Preserve permitted old mod artifacts if available. Workshop may serve only the newest release, so a backup of configuration alone does not guarantee a binary rollback.

Stage the update on a separate copy when the mod changes stored items, creatures or save formats. Keep the production service's active files intact until the test is useful. Do not silently change the map, total-conversion setting and ordinary mod set in the same maintenance window.

## 4. Interpret the failing stage

If the server fails before readiness, inspect the first missing dependency or initialization error. If only one player fails while matching clients join, have that player close the game, let the intended Workshop downloads finish and relaunch with the documented set. Do not ask them to delete all local saves.

If every client is rejected after an apparent successful update, compare the deployed server artifacts and ordered IDs again. A mod-author regression needs evidence from the author-supported release, not arbitrary changes to server passwords or network ports.

## 5. Isolate conflicts without saving away content

For a suspected interaction, create a separate test copy and change one dependency group at a time according to the authors' instructions. Keep its world distinct from the recovery copy. Removing a content mod from production and loading the same save can cause losses even if the process starts successfully.

After a correction, join with a normal account, inspect representative mod-owned content and test a normal save/restart cycle. Escalate with the first error, affected IDs, order, versions and the scope of the failure. If recovery is needed, restore the mutually compatible checkpoint as a whole rather than mixing old saves with unverified new artifacts.

## Related CloudExa guides

- [Diagnose ARK Survival Evolved startup and joining failures without wiping](https://help.cloudexa-hosting.com/books/survival-games/page/diagnose-ark-survival-evolved-startup-and-joining-failures-without-wiping)
- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)

## Official references

- [ARK Official Community Wiki: mod activation and installer configuration](https://ark.wiki.gg/wiki/Server_configuration)
- [ARK Official Community Wiki: server setup and platform requirements](https://ark.wiki.gg/wiki/Dedicated_server_setup)

# Install a DayZ mod set with matching client content and signature keys

DayZ PC mods can add content, change scripts or provide server administration. They are not interchangeable with console custom-server settings. Start with the author's published requirements and the exact server build, then test the complete set away from the active community's persistence.

## 1. Build an explicit mod inventory

Record each Steam Workshop ID, author, required dependency and supported game branch. Read installation notes for extra configuration or mission changes. A successful download does not prove the mod supports the current DayZ patch or the rest of your pack.

Separate client-required components from genuinely server-only tools using the author's instructions. A server-side label is a functional requirement, not a convenient way to avoid telling players about a required download. Keep paid or private package access within its licence.

## 2. Protect the existing world

Plan a normal stop and make a recoverable copy of mission data, profiles, configuration, persistence and the existing mod inventory. Check the active startup options because profile and storage locations can be overridden. Do not assume that copying only one familiar mission folder captures every dependency.

Use a test service with separate storage and integration credentials. Mods can add stored items or change schema; loading the community world once may write changes before a crash becomes visible. Keep the pre-change copy intact rather than using it as the test workspace.

## 3. Stage the package the author supplied

Deploy the complete release using the supported Workshop or file-transfer workflow. Preserve addon PBOs and their supplied signatures together. Bohemia's Linux compatibility guidance requires appropriate lowercase addon/key directory naming and addon files; confirm the package supports the deployed platform instead of batch-renaming an unfamiliar mod on production.

If you cannot identify the installed template's staging path, ask support. Avoid launching a second downloader over files used by the running server. Keep a record connecting each staged directory to its source ID.

## 4. Configure the active launch roles

DayZ accepts semicolon-separated mod folders in `-mod` and a separate `-serverMod` list for content not broadcast to clients. The following is only a placeholder illustration, not a replacement server launch command:

```
-mod=@RequiredFramework;@RequiredContent
-serverMod=@ServerOnlyTool
```

Use the template's existing quoting and dependency handling. Match actual folder names and the authors' required order; there is no universal order that makes every community pack compatible.

For signed client addon content, retain the matching signature files and deploy only the intended publisher's public `.bikey` to the server's trusted key location, normally its `keys` directory. Do not copy a private signing key or turn signature checking off.

## 5. Test content as well as joining

Start the isolated instance and inspect its current RPT/script logs. Join with a matching ordinary client mod set and test a representative item or action. If a mod needs mission or economy integration, merge only the author-documented additions into a saved copy; do not replace the entire existing mission with example files.

Verify a normal save/restart and expected persistence before a production change. A ready process alone does not prove loot, player state or mod configuration works. Preserve the original checkpoint and report source IDs plus the first error when requirements remain unclear.

## Related CloudExa guides

- [Set up and join a DayZ server without changing its existing world](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-and-join-a-dayz-server-without-changing-its-existing-world)
- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)

## Official references

- [Bohemia Interactive: DayZ server launch and profile/storage parameters](https://community.bohemia.net/wiki/DayZ:Server_Configuration)
- [Bohemia Interactive: packaged mods, signatures and Linux naming](https://community.bistudio.com/wiki/DayZ:Modding_Basics)
- [DayZ: supported PC modding and Workshop tools](https://dayz.com/faq)

# Diagnose DayZ mod updates, script conflicts and signature kicks safely

A DayZ update can expose a stale client download, an incomplete server package or a script incompatibility. Treat the actual error as a starting point. Removing all mods from the live service and loading its persistence can destroy the evidence and leave stored content unavailable.

## 1. Record the failure precisely

Note the UTC time, game build, affected player and exact kick or script message. Record whether the service fails during startup, rejects players before the lobby, or runs until a particular mod feature is used. Compare one other player where practical.

Preserve the current RPT and script-log excerpts from the active profile path. Startup options may relocate profiles, so a file in a familiar directory is not necessarily from the current run. Keep raw logs private when they contain player identifiers or access details.

## 2. Compare the deployed mod set

Check the active `-mod` and `-serverMod` entries against staged directories, author-required dependencies and the intended Workshop inventory. A newer download in a cache does not prove that the running service uses it. Do not infer version equality from folder names or timestamps alone.

Check whether the named component belongs on clients or only the server. A client-required package hidden in the server-only list is not repaired simply because the server starts. Respect the author's load-order and platform requirements rather than adding generic launch flags.

## 3. Follow the signature or script branch

For a signature rejection, inspect the named addon, its publisher-supplied `.bisign` and the trusted public `.bikey`. Compare packages from the same intended release. Keep signature verification and anti-cheat in place; disabling them masks the discrepancy and changes the security of everyone else's session.

For a script compile or missing-class error, read the first relevant log entry and check the author's supported DayZ build and dependency notes. Copying an old configuration sample over new files may conceal a required migration. If the author has not released a compatible version, repeated reinstalls cannot make it compatible.

## 4. Coordinate a controlled replacement

Warn players and stop normally. Keep a completed checkpoint of mission, profiles, actual persistence/storage, configuration and ordered mod IDs before updating through the supported deployment workflow. Preserve permitted release artifacts where possible; Workshop may no longer offer the exact previous binary.

Ask the affected player to close the game, let the intended downloads finish and relaunch the documented set. Do not ask them to erase local saves. Confirm server files have finished staging before accepting another connection attempt; do not run simultaneous updaters.

## 5. Test conflicts away from production

Use a separate test instance and separate persistence for dependency-group isolation. Removing a content mod can change what a save contains, so do not use the only recovery copy for that experiment. Retain the test logs and change one group at a time according to the authors' instructions.

After a correction, verify normal joining, the feature that failed and a normal save/restart with expected player and item state. Escalate with source IDs, launch roles, game/build comparison and the first redacted error if the result is unclear. Roll back a compatible pre-update dataset and artifacts together rather than combining an old database with an unverified new pack.

## Related CloudExa guides

- [Diagnose DayZ startup, mod and joining failures without wiping persistence](https://help.cloudexa-hosting.com/books/survival-games/page/diagnose-dayz-startup-mod-and-joining-failures-without-wiping-persistence)
- [Schedule game server backups and check retention](https://help.cloudexa-hosting.com/books/game-hosting/page/schedule-game-server-backups-and-check-retention)

## Official references

- [Bohemia Interactive: DayZ configuration and mod launch roles](https://community.bohemia.net/wiki/DayZ:Server_Configuration)
- [Bohemia Interactive: addon packaging and signature workflow](https://community.bistudio.com/wiki/DayZ:Modding_Basics)
- [DayZ: official modding support and tools](https://dayz.com/faq)

# Install 7 Days to Die mods into the active user-data folder

A mod can load successfully and still be unsuitable for your existing world. Before installing it, establish which game build it supports, whether players need matching files and whether it changes saved blocks, items or progression. “Latest” on a download page is not a compatibility guarantee.

## Prepare a recoverable change

1. **Record the current setup.** Save the server build number, startup arguments, active configuration and existing mod versions. Read the mod author's release notes for supported builds, required libraries, installation side and existing-world restrictions. Choose a release explicitly suitable for that build.
2. **Back up a stopped, saved instance.** Keep its world, player data, generated-world files, configuration and complete mod set together. Retain a separate copy of the downloaded releases. A backup without the old mod versions may be difficult to use later.
3. **Identify the effective user-data directory.** Check startup arguments, configuration and the launch log rather than assuming the game installation is the save location. The developer's [official mod-location statement](https://community.thefunpimps.com/threads/v1-x-developer-diary.35064/page-177) recommends a `Mods` directory inside `UserDataFolder`. Default desktop locations include `%AppData%\7DaysToDie` on Windows and `~/.local/share/7DaysToDie` on Linux; hosted templates can override these.
4. **Stage the mod on an isolated copy.** Extract the author's release while preserving its structure. A common check is `<active UserDataFolder>/Mods/<mod-folder>/ModInfo.xml`, rather than an extra archive wrapper directory. Follow the package's instructions if its layout differs. Do not change the live user-data path just to make this example fit.
5. **Install the documented dependencies and client files.** Server-only, client-only and both-side requirements belong to each mod's documentation. Do not assume that joining automatically distributes every mod. Keep required client and server releases aligned, including libraries.

## Handle anti-cheat requirements deliberately

Do not disable Easy Anti-Cheat to solve an unexplained launch error. Some code mods explicitly require a different launch arrangement: for example, [Gears documents its DLL, both-side installation and EAC requirements](https://s7092910.github.io/Gears/docs/players/getting-started/). That is a requirement for that package, not permission to change security settings for every mod. If a chosen package conflicts with your intended protected or cross-platform service, select a compatible alternative or ask support before proceeding.

## Prove the change and preserve rollback

Start the test instance and read the initial mod-loading messages. Confirm the expected package and dependencies appear once, with no XML or assembly errors. Join using a matching client, exercise the affected feature, then save and restart the test. Check existing inventory and a known structure as well as the new feature.

If the trial fails, keep its log and revert the isolated copy to the recorded package set. Do not open and save the only live world after removing content it relies on. Promote the tested set during a planned restart, retain the pre-change backup and tell players exactly which files they need.

Related: [edit serverconfig.xml safely](https://help.cloudexa-hosting.com/books/survival-games/page/edit-7-days-to-die-serverconfigxml-safely) and [preserve a 7 Days to Die save](https://help.cloudexa-hosting.com/books/survival-games/page/preserve-a-7-days-to-die-save-when-moving-or-changing-worlds).

# Trace a 7 Days to Die mod failure after an update

When a server stops working after an update, identify what changed before trying another update. A client connection failure, an XML patch error and a server that never loads its world need different checks. Reinstalling or deleting the world removes evidence and can turn a recoverable mod problem into lost progress.

## Capture the first failure

1. **Record the timeline.** Note the last successful start, the game build before and after, changed mod releases and whether every player or only one is affected. Save the complete startup log and an affected client's log, including lines before the first exception. Redact passwords and tokens before sharing them.
2. **Preserve the current state.** Stop the server cleanly when possible and copy its saves, player data, generated world, configuration and mod files. Keep this failed state separately from the last known working backup. Do not overwrite a good backup with repeated experimental starts.
3. **Compare exact builds and packages.** Check the full server/client build numbers and each mod's supported release. An unchanged folder name does not prove the files match. Compare author release versions and dependency requirements; check whether one player retained an older client package.
4. **Read the first relevant error.** An XML patch failure suggests a target or data-format change; a missing assembly suggests a dependency or incompatible code package. These are directions for investigation, not proof that the named mod is solely responsible. Preserve the first error before later failures obscure it.

## Check which mod files actually loaded

The developer's [mod-directory guidance](https://community.thefunpimps.com/threads/v1-x-developer-diary.35064/page-177) places user mods under the active `UserDataFolder/Mods`. A hosted template may set that folder through its startup or configuration. Compare the logged paths with the directory you updated. Inspect any additional mod location reported by your installed build for an older second copy; do not sweep the entire installation directory or remove publisher-supplied components.

A package can also be nested too deeply after extraction. Compare its layout against the author's archive, and check that required files are readable by the service. Avoid broad permission changes or renaming every mod to force an assumed load order.

## Isolate the change without risking the world

Make an isolated test instance using the backed-up configuration and recorded packages. First reproduce the failure. Then reverse the most recent change with its required dependencies as a group. If a minimal baseline is needed, use a disposable test world; do not load the production world without its required content.

For larger sets, test dependency-complete groups rather than arbitrary individual files. Keep a short table of the combination tested, first error and result. A successful empty-world start narrows the issue but does not prove the existing save is safe. For packages such as [Gears, whose author requires coordinated client/server versions](https://s7092910.github.io/Gears/docs/players/getting-started/), check both sides before blaming networking. Do not change anti-cheat settings as a generic diagnostic step.

## Validate or roll back

Before reopening access, join with a known matching client, inspect existing progress and repeat a save/start cycle. If rolling back, restore the compatible runtime, package set and appropriate pre-change save together; an older runtime may not accept a save written after migration. Ask support with the build numbers, sanitized first error and reproduction results if that compatibility is uncertain.

Related: [preserve the save](https://help.cloudexa-hosting.com/books/survival-games/page/preserve-a-7-days-to-die-save-when-moving-or-changing-worlds) and [choose the next startup check](https://help.cloudexa-hosting.com/books/game-hosting/page/game-server-will-not-start-choose-the-next-safe-check).

# Choose tModLoader mods or TShock plugins for a Terraria server

Terraria gameplay mods and administration plugins use different server software. Decide which type of change you need before uploading files. A package downloaded for one ecosystem will not become compatible simply because it is placed in another server's directory.

## Choose the correct software family

- **Vanilla Terraria:** the standard server for the base game. It does not load arbitrary tModLoader packages or TShock plugins.
- **tModLoader:** use this for its supported gameplay mods and corresponding clients. The [upstream usage guide](https://github.com/tModLoader/tModLoader/wiki/Basic-tModLoader-Usage-Guide) explains its mod workflow and separate save locations. A vanilla client is not a substitute for the required tModLoader client.
- **TShock:** a server administration and plugin ecosystem built on Terraria Server API. The [upstream API project](https://github.com/Pryaxis/TSAPI) loads server plugins from `ServerPlugins`. These DLL plugins are not `.tmod` gameplay packages. Check each plugin's supported Terraria, TShock and API releases.

Do not attempt a combined TShock/tModLoader installation unless a separately supported project explicitly provides that arrangement. CloudExa cannot infer compatibility from similar feature names.

## Prepare and install one compatible change

1. **Inventory the live service.** Record the executable family, exact release, startup configuration, selected world and active save paths. Identify whether any server-side character or account database is in use.
2. **Make a clean backup.** Save and stop normally, then preserve the complete world, player-related data, configuration, mods/plugins and any plugin databases. Keep both files of a tModLoader world, `.wld` and `.twld`, together; preserve complete player saves and their sidecar data too.
3. **Use an isolated test copy.** Select a package from its author's release page for your exact software family. Read dependency and migration notes before copying it. Keep credentials and production database connections out of the test environment.
4. **For tModLoader, transfer the intended enabled set.** Its current [Dedicated Server Utils documentation](https://github.com/tModLoader/tModLoader/blob/stable/patches/tModLoader/Terraria/release_extras/DedicatedServerUtils/README.md) describes exporting a mod pack and using `install.txt` plus `enabled.json`. Those instructions apply to that upstream layout; a hosted template may use different active paths. Confirm the service's configured mod directory instead of uploading to a guessed location.
5. **For TShock, follow the plugin's release instructions.** Place the compatible plugin in the active server's `ServerPlugins` directory, with documented dependencies. Keep existing TShock components intact. Grant only the permissions the feature needs.

## Check the feature and the existing data

Start the test and confirm the expected mod or plugin loads without dependency errors. For tModLoader, join with the matching branch and required mod set. For TShock, test a normal account as well as an administrator; unrestricted administrator access can hide permission mistakes.

Inspect an existing structure, inventory and the new feature, then save and restart. If the test fails, preserve its logs and restore the complete recorded combination on the test copy. Removing a content mod and saving the only live world is not a safe rollback. Schedule the live change only after the test passes, and retain the previous files.

Related: [upload a Terraria world](https://help.cloudexa-hosting.com/books/survival-games/page/upload-a-terraria-world-and-verify-the-server-connection) and [grant limited TShock permissions](https://help.cloudexa-hosting.com/books/survival-games/page/set-up-tshock-accounts-and-grant-limited-administrator-permissions).

# 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](https://github.com/tModLoader/tModLoader/wiki/Basic-tModLoader-Usage-Guide) 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](https://github.com/tModLoader/tModLoader/blob/stable/patches/tModLoader/Terraria/release_extras/DedicatedServerUtils/README.md) 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](https://github.com/Pryaxis/TShock/blob/general-devel/docs/command-line-parameters.md) 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](https://help.cloudexa-hosting.com/books/survival-games/page/trial-tshock-server-side-characters-without-risking-player-inventories) and [check player connections](https://help.cloudexa-hosting.com/books/game-hosting/page/players-cannot-join-follow-the-connection-checks).

# Add Unturned Workshop content or maintained server plugins safely

Unturned Workshop content and server plugins take different installation routes. A Workshop map or asset pack is not a plugin DLL, and copying a plugin into a Workshop directory will not load it. Choose the route your feature requires, then keep the server instance and its saves intact.

## Plan the package set

1. **Record the current instance.** Note the Unturned build, startup instance ID, selected map, enabled modules and current packages. Resolve the active `Servers/<instance-ID>/` directory from the service's actual startup. Hosted templates can relocate the installation root.
2. **Read the author's requirements.** Check supported game/framework releases, dependencies and any migration or client requirements. A Workshop item title is not its numeric file ID, and a plugin advertised for another framework is not automatically compatible with yours.
3. **Save, stop and back up.** Keep the instance configuration, world/player data, permission files, modules, plugins and plugin databases. Preserve the existing instance ID; starting under a new name can make a server appear empty while its original saves remain elsewhere.

## Install Workshop content

The developer's [server-hosting instructions](https://docs.smartlydressedgames.com/en/stable/servers/server-hosting.html) use the instance's `WorkshopDownloadConfig.json`. Add numeric Workshop item IDs to its `File_IDs` array, retaining valid JSON and existing settings. The item ID comes from its Workshop URL. On startup, the server obtains the configured content and dependencies; connecting players download required Workshop content.

Do this first on an isolated instance copy with separate allocations and storage. For a map, use the author's documented map name in `Server/Commands.dat`; the numeric download ID is not the map name. Confirm the map content finishes downloading before interpreting a load failure. Adding content to the list does not guarantee an existing world can safely change maps or remove old assets.

## Install a supported plugin framework

For the Rocket-compatible route, use the developer-maintained [Legally Distinct Missile (LDM) fork](https://docs.smartlydressedgames.com/en/stable/servers/rocket.html). SDG supplies its current module with the dedicated server, copied from `Extras/Rocket.Unturned` into `Modules`. The original Rocket projects include abandoned archives; their familiar names do not make arbitrary old downloads suitable.

Start the test framework and follow the chosen plugin author's instructions for its generated directories, dependencies and configuration. Install only the supported plugin release, then stop and start normally. Do not mix frameworks or replace bundled game assemblies to satisfy an unexplained error. DLL plugins execute server code: use identifiable upstream releases and keep database credentials private.

## Validate and keep the previous set

Read startup output for the expected map, module and package, then test the intended feature with an ordinary player account. For administrative plugins, confirm permissions restrict privileged commands. Inspect existing progress, save, restart and join again. A visible server listing alone does not prove content loaded correctly.

If the test fails, preserve its first error and return the isolated instance to the recorded combination. Keep pre-change data and packages together. Do not remove content from the only live save and save over it as a diagnostic shortcut. Promote the tested files during a planned restart and retain the rollback copy.

Related: [configure and join Unturned](https://help.cloudexa-hosting.com/books/survival-games/page/configure-and-join-an-unturned-server-using-its-assigned-connection-method) and [back up before changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes).

# Diagnose Unturned Workshop and plugin failures after updates

If Unturned worked before an update, separate content acquisition, world loading and player joining. A stalled Workshop download needs different evidence from a plugin exception. Start with the earliest failure and avoid deleting caches or saves as a blanket repair.

## Preserve evidence and identify the change

1. **Record the affected stage.** Does the process stop before the map loads, reach its ready state but reject players, or fail only when a plugin command runs? Keep the complete startup log and a client's exact message. Note the last successful session and any game, Workshop or plugin changes.
2. **Check the actual instance.** Confirm the startup instance ID and its active data directory. An unexpected new map or empty inventory may mean a different instance started. Preserve the original directory and stop investigating on the live world if the identity is uncertain.
3. **Create a recovery copy.** Save and stop normally when possible. Copy the instance data, configuration, module/plugin files and databases before changing anything. Retain the failed state separately from your last working backup.

## For Workshop download or asset errors

Inspect the active instance's `WorkshopDownloadConfig.json` for valid JSON, correct numeric IDs and unintended changes. Check each item's availability and required dependencies on its author's page. Record the failing item ID and the download error; a removed or inaccessible item is different from an invalid map name.

The [official hosting guide](https://docs.smartlydressedgames.com/en/stable/servers/server-hosting.html) explains that configured Workshop content is installed or updated during startup. Compare startup completion with the client's download or asset error before changing the firewall. Check available disk space and file permissions if output indicates write failures. Do not clear the entire Workshop tree or unsubscribe players from everything.

For map problems, compare the configured map name with the selected item's instructions. For one affected client, compare its game branch and specific content error with a working client. If a targeted client download repair is required, preserve local files first and follow the item's or Steam's relevant instructions rather than guessing which saved-data directories are disposable.

## For plugin or module exceptions

Record the framework, plugin and dependency versions. [SDG's maintained LDM fork](https://github.com/SmartlyDressedGames/Legally-Distinct-Missile) is the supported Rocket-compatible starting point; an archived original Rocket build is not an equivalent update source. Use the module supplied with the matching dedicated-server release, and check each plugin author's compatibility notes.

Do not repeatedly hot-reload a failing stack. LDM's [upstream changelog](https://github.com/SmartlyDressedGames/Legally-Distinct-Missile/blob/master/CHANGELOG.md?plain=1) records disabling the reload-all command because many plugins did not support it correctly. Prefer a controlled stop/start for a tested package change. Never paste database passwords or connection strings into a public error report.

## Test a reversible correction

Reproduce the problem on an isolated copy. Reverse the most recent change with its required dependencies and test the affected action again. Keep dependency-complete groups together when narrowing a conflict. Use a disposable world for content-removal experiments; do not save the only live world after removing assets it needs.

Success means the expected map and packages load, a matching client joins, existing progress is present and the feature still works after saving and restarting. For rollback, use a compatible game/module/plugin set and its appropriate backed-up data together. Keep logs and the package inventory for support if a publisher update prevents a reliable rollback.

Related: [Unturned joining checks](https://help.cloudexa-hosting.com/books/survival-games/page/troubleshoot-an-unturned-server-missing-from-the-list-or-rejecting-players) and [startup troubleshooting](https://help.cloudexa-hosting.com/books/game-hosting/page/game-server-will-not-start-choose-the-next-safe-check).

# Build and activate a tested Factorio mod collection

Prepare a mod collection away from your live factory, then activate the exact set you tested. This workflow is for installing a collection deliberately; use the related mismatch guide if an otherwise working multiplayer server simply rejects a player.

## Record the starting point

Write down the server's complete Factorio version, selected release branch and current save. Check whether the group uses Space Age features and whether every player has the required expansion. A collection described as compatible with “Factorio 2” still needs checking against the actual major version and its dependencies.

Before changing anything, take a complete backup and verify that the archive can be opened. Preserve the factory save, configuration and existing mod directory together. Keep the untouched copy outside the active server directory so a mistaken upload cannot overwrite your recovery files.

## Prepare a collection locally

1. Use a separate local game profile or test installation matching the intended server version. In Factorio's Mods menu, select the collection and let the game resolve required dependencies. Read each project's compatibility and release notes before adding optional extras.
2. Check required expansion features. The [official mod metadata reference](https://lua-api.factorio.com/latest/auxiliary/mod-structure.html) explains version compatibility and expansion feature requirements. Editing a mod's version declaration does not make incompatible code or unowned expansion content work.
3. Choose startup settings using the game's interface. Start a disposable test factory and exercise the features you expect players to use. Keep your existing production save out of this first test.
4. Keep the resulting mod files and the game's generated enabled-mod list together. Preserve `mod-list.json` and `mod-settings.dat` when present. The latter is a [binary settings file](https://wiki.factorio.com/Mod_settings_file_format), so do not edit it as JSON or rename it to a text format.

## Stage the upload

Find the service's actual mod directory before transferring anything. Factorio's [user-data location](https://wiki.factorio.com/Application_directory) can vary, and a [startup argument](https://wiki.factorio.com/Command_line_parameters) can select another mod directory. Ask support if the template makes this unclear; creating a second guessed folder can leave the running service unchanged.

Stop the test service normally and wait for it to finish. Upload the selected collection to that confirmed location. The [official installation instructions](https://wiki.factorio.com/Modding) say downloaded mod ZIPs can remain zipped. Keep their original filenames and avoid an extra outer archive folder. Do not replace the game executable, server credentials or unrelated saves.

## Verify before activation

Start the test service and inspect the first startup errors. Join using the tested client, confirm the intended mods are active, then build or operate something that depends on them. Save, stop normally and load that test save again. A process staying online alone does not prove that the collection works.

For an existing factory, repeat the test with a separate copy of its save before scheduling the production change. If dependencies fail or factory content changes unexpectedly, keep production on its original collection. Retain the whole pre-change backup until the group has checked the activated server.

## Related CloudExa guides

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Resolve Factorio mod and startup-setting mismatches](https://help.cloudexa-hosting.com/books/survival-games/page/resolve-factorio-mod-and-startup-setting-mismatches)

# Stage a Factorio mod collection update and preserve a complete rollback

A successful mod update must load the factory correctly, keep its important systems intact and allow players to return. Treat the save and its mod collection as one release. This guide covers planned updates and recovery; the related mismatch article handles a player whose installed set differs from an unchanged server.

## Freeze the working release

Record the full Factorio version, expansion requirements, enabled mods, exact mod versions and startup settings. Announce a maintenance window before interrupting players. Save and stop the service normally, wait for the process to finish, then make a complete backup that includes the selected save, mod files, generated mod list, settings and configuration.

Give the backup a clear date and retain it outside the active installation. Keep another copy of the current save separately. A backup containing only the factory cannot reproduce missing mod versions later, particularly if an author withdraws a release.

## Build a candidate release

1. Create an isolated test service or local installation using a copy of the factory. Keep its save output separate from production. Ask support for staging assistance if your plan does not provide another service.
2. Read changelogs for the mods being changed and their dependencies. Check support for your Factorio major version and expansion features using the [official metadata rules](https://lua-api.factorio.com/latest/auxiliary/mod-structure.html). A dependency update may affect more than the mod you selected.
3. Update a documented group of compatible packages, preserving the original collection unchanged. Keep a small release note listing every changed file and version so you can explain precisely what was tested.
4. Load only the copied save. Watch the earliest error and compare it with the author's upgrade instructions. Do not repeatedly disable content mods on the production factory to discover which combination starts.

## Check the factory, not only startup

Factorio's [migration system](https://lua-api.factorio.com/latest/auxiliary/migrations.html) allows mods to transform saved data during loading. That means a save written after an update is a different recovery point from your untouched pre-update save.

Inspect representative production lines, modded machines, research and inventories. Check the systems your group relies on rather than trying to validate every entity manually. Join from a second client with the candidate collection, play briefly, save, stop and reload. Record any script errors or unexpected missing items before approving the update.

The [official mod-sync guidance](https://wiki.factorio.com/Modding) distinguishes synchronizing to a server from synchronizing to a save; the latter can select newer versions by default. Use your recorded package versions when reproducing a release instead of assuming every sync produces yesterday's collection.

## Activate or recover as a complete set

If testing passes, repeat the controlled maintenance process on production with the tested packages and settings. Verify the production save selected by startup and confirm real players can join. Keep the pre-update snapshot and the candidate snapshot clearly separated.

If testing fails, preserve the failed candidate and its logs. Return the stopped service to the matching pre-update executable version, configuration, mod collection and untouched save, with support assistance where needed. Do not load the newly migrated save with older mods and call that a rollback. Check the restored factory and player connection before reopening access.

## Related CloudExa guides

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Resolve Factorio mod and startup-setting mismatches](https://help.cloudexa-hosting.com/books/survival-games/page/resolve-factorio-mod-and-startup-setting-mismatches)

# Install a compatible Hytale mod or plugin on a test copy

Hytale supports server extensions, but compatibility depends on the actual server build and the package author's instructions. Begin with one extension on a test copy. Do not apply a Minecraft plugin tutorial merely because both games can run Java server software.

## Check what the package supports

Read the project's release page and record its supported Hytale builds, dependencies and installation instructions. Distinguish a normal packaged mod from an early or bootstrap plugin. The [official server manual](https://support.hytale.com/hc/en-us/articles/45326769420827-Hytale-Server-Manual), reviewed on 10 November 2026, explicitly warns that accepting early plugins is unsupported and can cause instability. This guide covers ordinary documented mod packages.

The developer's [modding overview](https://hytale.com/news/2025/11/2025-11-20-hytale-modding-strategy-and-status) explains server plugins and asset-based content. A Java archive extension alone proves little: the project must actually target Hytale. Keep the download source and exact release filename in your change notes so you can reproduce the installation later.

## Prepare the test safely

1. Record the current server build and startup arrangement. Keep its existing launcher and authentication method. Do not replace them with commands from another host's installation guide.
2. Save and stop normally before copying the installation. Back up the complete service, including the universe, configuration, installed mods and any existing extension data. Verify that the backup is readable and retain it outside the active files.
3. Use a separate service or local test installation with a copied universe. Keep the original untouched and separate the test service's saved output. Ask support if you need help arranging staging or identifying the active working directory.
4. Check the extension's stated requirements against this test build. Do not assume an updated game automatically makes an older plugin compatible, or enable an unsupported startup switch just to bypass its warning.

## Put the package in the active location

The official manual documents ordinary mod `.zip` and `.jar` packages in `mods/`. Resolve that path relative to the running server's working directory. The newer upstream launcher runs the process from its `Server` directory, while a hosted template may arrange files differently. Confirm your service's location before creating another folder.

Upload the author's release package and required compatible dependencies while the test server is stopped. Preserve the package structure unless its own instructions specify otherwise. Keep any generated configuration changes limited to that extension; do not copy an unrelated sample universe or server configuration over your existing files.

## Check the feature and persistence

Start the test service and inspect its earliest errors. Confirm the expected extension is loaded, then join with the supported game client and exercise one documented feature. Check an existing area or player inventory as well, so a new feature does not hide a problem with old data.

Save, stop and start again, then confirm the feature and test-world changes persist. If testing fails, preserve the candidate's logs and return to the untouched backup rather than repeatedly changing production. Only activate the tested collection after recording its package versions and confirming that the ordinary join still works.

## Related CloudExa guides

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Authenticate a Hytale server and check the first connection](https://help.cloudexa-hosting.com/books/survival-games/page/authenticate-a-hytale-server-and-check-the-first-connection)

# Stage Hytale mod updates and diagnose build compatibility failures

A Hytale update can change both player compatibility and extension behaviour. Investigate those separately: a client rejected before joining is a different problem from a plugin failing during startup. Keep the original universe and package collection intact while testing a candidate release.

## Capture a reproducible baseline

Record the server build, client build, launcher arrangement, installed extension filenames and the last successful startup. Note which game or mod updates occurred immediately before the failure. Capture the first relevant error and its timestamp rather than only the final shutdown message.

Save and stop normally. Back up the complete service, including universe data, mod packages, generated configuration and extension-owned data. Keep credentials private. An update that preserves a directory does not prove every plugin inside it remains compatible.

## Separate the failing layer

1. **Client rejected for protocol compatibility:** compare the game builds before changing mods. The [current official manual](https://support.hytale.com/hc/en-us/articles/45326769420827-Hytale-Server-Manual) documents exact client-server protocol matching. Do not rely on a promised future tolerance or assume that two builds labelled release are interchangeable.
2. **Server fails while loading an extension:** record the named package and check the author's supported build and dependency releases. A plugin compiled against another API may need its own update even when the game payload is complete.
3. **Server starts but content is absent:** verify the package reached the active runtime's mod directory and read the extension's configuration instructions. Do not copy an invented enable flag into world configuration.
4. **Only one feature fails:** preserve its configuration and data. Test its documented action independently before changing authentication, allocation settings or unrelated extensions.

## Construct a candidate on a copy

Use an isolated test service with copied data. Update the game payload and intended extension releases as a recorded compatible group, following the current template and author instructions. Keep the original launcher in the recovery copy; mixing launch scripts and game assets from different releases makes later diagnosis harder.

The official update workflow preserves saves and mods, but that is not an extension migration guarantee. Check each project's instructions before converting its configuration or database. If an early-plugin warning appears, do not add an acceptance flag as routine troubleshooting; ask the author whether a supported ordinary package exists.

Where you need to isolate a suspected conflict, use a fresh disposable test world with the minimum dependencies first. Then test the complete intended collection against another copy of the existing universe. Do not remove content packages from the live universe and save over it just to see whether startup succeeds.

## Verify or restore the full recovery point

Join with the compatible client, exercise the affected feature and inspect existing player data. Save and restart the candidate, then repeat the check. Retain the successful package list with the backup so support can reproduce the result.

If recovery is necessary, preserve the failed candidate and restore the matching pre-change server files, configuration, packages and untouched universe with support assistance. Restoring only an old plugin over newly migrated data is not a complete rollback. Ask the extension author about safe migration boundaries before reopening production to players.

## Related CloudExa guides

- [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)
- [Diagnose Hytale authentication, UDP and world-loading failures](https://help.cloudexa-hosting.com/books/survival-games/page/diagnose-hytale-authentication-udp-and-world-loading-failures)