Palworld Native Workshop Server Mod Not Loading

Create a reversible test boundary

Pocketpair warns that mods can crash the server or corrupt save data. Run /Save and /Shutdown, verify exit, then copy SaveGames, PalWorldSettings.ini, Mods/PalModSettings.ini and the relevant Workshop metadata outside the install root.

If the mod owns creatures, structures or items, never diagnose removal on the only good world. Loading and saving without the content may make the loss permanent.

1. 1Record the current server build and complete enabled-mod order.
2. 2Make a dated off-tree snapshot after clean shutdown.
3. 3Use a private copy of the world for first activation or removal tests.

Verify that the package can install on a server

The current native Windows flow discovers Workshop packages under Mods/Workshop/<folder>/Info.json next to PalServer.exe. Pocketpair only installs packages whose install rules mark them for server use.

A folder's numeric or friendly name is not necessarily the identifier used in the active list. Open Info.json and copy its PackageName exactly rather than guessing from the directory.

• Confirm the manager is starting the same installation root you inspected.
• Confirm Info.json exists and the package has a server install rule.
• Confirm the PackageName, not the folder name, is used for activation.

Build the smallest valid PalModSettings.ini

PalModSettings.ini is generated after the mod-aware first launch. Enable global mods and add one ActiveModList entry using the exact PackageName. A stale or malformed list can hide the difference between a package failure and an ordering conflict.

Restart the entire server. Pocketpair's deployment flow checks the managed package at startup; hot-adding a file while the process runs is not a complete activation test.

1. 1Set bGlobalEnableMod=true.
2. 2Leave one ActiveModList=<PackageName> entry.
3. 3Start, capture the first mod-related log result and complete a matching-client join.
4. 4Add remaining packages one at a time in the intended order.

Use -NoMods to separate mod failure from world failure

The -NoMods argument disables all mods for a controlled vanilla diagnostic start. Use it only against the protected copy when a content mod may own persistent objects; a successful vanilla boot does not mean it is safe to save that copied world and replace production.

If the package changed version, the server redeploys it at restart and records managed installation data. Preserve the log and manifest evidence before repeatedly validating or deleting folders.

• Vanilla boot succeeds: inspect package eligibility, PackageName, version and ordering.
• Vanilla boot also fails: diagnose server/config/world state before blaming Workshop.
• Mod loads but client cannot join: verify that client's required package/version and platform support.