How to Set Up a Soulmask Server Cluster

Your group has outgrown Cloud Mist Forest, somebody's already bought a second server for the desert map, and now you'd like people to be able to walk between the two without starting again from a rock and a stick. That's a cluster. Soulmask handles it through a cross-server terminal your players build in the world, not through anything in the main menu.

The good news is that our Soulmask setup already ships the command lines this needs: you're picking options, not writing config. The bad news is that one of the fields involved will lock your players out of their own characters if you change it at the wrong moment. So that's where I'm starting.

And if you'd rather not touch any of it, open a ticket. We set clusters up free of charge, and honestly we'd rather do that than restore somebody's world afterwards.

The Server ID rule, before you change a thing

Every server in a cluster needs its own Server ID, and Soulmask leans on that number to work out which account data belongs to which server.

Change a server's Server ID after people have made characters on it, and those players lose access to their characters. Not corrupted. Not fixed by a restart: the server just stops recognising them as the same accounts. Their progress is still sitting there in the save and they cannot get to it, which is a miserable ticket to have to answer.

So the order you do things in matters:

• On a brand new second server, set the Server ID before anyone joins. There's nothing to lose yet.
• On an established server that's about to become the cluster main, leave its Server ID exactly where it is. Even if it currently reads 0, and even if 0 looks like an unset placeholder: it isn't, zero is a perfectly valid ID. Uniqueness across the cluster is the only hard rule, so give the new server the different number and keep your hands off the old one.

I'd take a manual Cloud Backup of the established server first regardless. It won't cleanly undo an ID change, but it costs thirty seconds and I've never once regretted having one sitting there.

What a cluster does, and what it doesn't

Worth being blunt about this, because it's the second most common source of disappointment after the Server ID business.

Each server keeps its own world. Clustering is a travel link and not a save merge: your existing base, your tribe and your terrain all stay on the server they were built on, and the second server starts completely fresh on its own map. Nothing gets copied across. There's no setting that changes that, either.

Travel happens at a cross-server terminal that players build and interact with in-game. No menu option, no lobby, no launcher flag. It's a structure, and somebody has to go and make one.

Only a controlled tribesman can make the jump. Your starting character can't use the terminal at all, so players need to be possessing a recruited tribesman at the point they travel. Local inventory doesn't come along either. Anything worth keeping should be stashed on the map you're leaving before you go.

Setting it up in the control panel

Sign in to the LOW.MS Control Panel. You'll be doing a bit on each of the two services.

On the main server, the one running Cloud Mist Forest:

1. Open Commandline Manager and pick the Cluster Enabled command line. That's the normal Cloud Mist Forest startup line with the cluster broadcast parameter added to it.
2. Open Service Settings and set Server ID to a unique number, subject to everything above.
3. Make a note of the service's IP and game port. The cluster broadcasts on the game port plus four, so a service sitting on 27015 broadcasts the cluster on 27019.

On the second server, the one running Shifting Sands:

1. Open Commandline Manager and pick Cluster Secondary Server. That swaps the map over to the Shifting Sands level and adds the parameter that dials home to the main server.
2. Open Service Settings and set Server ID to a different number from the main.
3. On the same screen, fill in Master server IP & Port: with the main server's IP and that broadcast port, so something in the shape of 203.0.113.10:27019.

Then, on both services, make the private password match. Soulmask won't complete two-way travel between servers running different join passwords, and it's an easy one to trip over when the second server was ordered separately and arrived with its own generated one.

Restart both services once you've saved. Command line changes only take effect on a fresh start. A reload won't do it.

Three things that catch people out at this stage:

• The pairing is fixed. Cluster Enabled runs Cloud Mist Forest and Cluster Secondary Server runs Shifting Sands, and that's the shape we ship. Two Cloud Mist Forest servers linked together, or a third map bolted onto the cluster, means a custom command line, so ask us and we'll write one.
• Both cluster command lines drop the Mods: field. Neither of them carries the mod parameter, so if you're running Workshop mods today they'll quietly stop loading the moment you switch over. This one genuinely surprises people. Open a ticket and we'll build you a line that keeps them.
• An older service might not have the port. The cluster broadcast port comes from a fifth port on the service, and services created before we added it won't have one allocated. If yours only lists three, that's what's happened, and we can sort it.

Turning cross-server travel on

Getting the command lines right builds the topology. It doesn't actually switch travel on, which is the step people miss.

There's a game-side coefficient called KaiQiKuaFu that has to be set to 1 on both servers. Until it is, the cross-server terminal sits there listing nothing at all. Everything looks broken despite being wired up perfectly correctly. It's the single most common reason a cluster "doesn't work".

The route I'd use is in-game. Your admin password is the RCON password shown against the service in the panel, so hit the tilde key and run:

gm key <your RCON password>

Enter that password again in the GM panel that appears, take admin, then open the coefficients screen from the GM menu and switch Cross-server Mode on. Both servers, not just the main one.

There's also Web Console in the panel, which is wired up for Soulmask and sends over RCON:

Set_Coefficient KaiQiKuaFu 1

I'd treat the console as the fallback rather than the opening move: the in-game menu is the one I'd trust to stick.

Don't do this by editing GameXishu.json. Plenty of guides will tell you to open WS\Saved\GameplaySettings\GameXishu.json and flip KaiQiKuaFu to 1, and on a box you own yourself that's reasonable advice. On our platform it isn't. That file gets generated from a template on our side, the template hardcodes KaiQiKuaFu to 0 with no panel field sitting behind it, and it's set to regenerate. An edit you make by hand there isn't really a setting: it's a change queued up to be overwritten. Use the in-game menu and save yourself the puzzle.

If travel still isn't showing up

Run down this list before you open a ticket, and tell us which bits you've already ruled out. It genuinely halves the turnaround at our end.

• Have both servers actually been restarted since the command line changed? This is the answer more often than everything else here put together.
• Are the Server IDs different? Two servers sharing an ID won't link to each other.
• Are the passwords identical on both, case included, and that covers "both blank", if you're running the pair open.
• Is Master server IP & Port pointing at the game port plus four, rather than the game port itself, and using the main server's public IP rather than a local one?
• Is cross-server mode on for both servers? Half a cluster behaves exactly like no cluster.
• Is the player actually controlling a tribesman? A starting character standing hopefully at the terminal will get nothing back.

Log Viewer reads WS\Saved\Logs\WS.log, which is where the second server grumbles if it can't reach the main one. The last fifty lines after a start attempt are usually enough for us to spot the problem. If the trouble turns out to be one server misbehaving on its own rather than the link between them, /knowledgebase/soulmask-troubleshooting is the better starting point.

One last thing on Shifting Sands. Your server hosts the map regardless of who owns what, but each player needs the DLC on their own account to travel there. It was free to claim on Steam until 10 May 2026, and anyone who claimed it in that window keeps it permanently, so most groups split neatly into the people who were paying attention that week and the people who weren't. Everyone else buys it. There's more on that release in our Soulmask 1.0 launch post, and the wider settings reference lives at /knowledgebase/soulmask-server-configuration.

If it goes sideways anyway, open a ticket with both service IDs and we'll go through the link ourselves. Support's 24/7, and as above, we're happy to do the whole setup for you free if you'd rather skip the fiddly parts entirely.