Dedicated servers' "server_save_slot" - does it matter at all?

[dread3ddie]

When hosting (creating) a game from the game client it's possible to choose one of the 5 available slots. That will have the game client creating separate folders (Cluster_1, Cluster_2, ..., Cluster_5) to keep apart and distinct words for each slot.

Now, for dedicated servers, does it matter at all? By default dedicated servers do not create separate "Cluster" folders based on the selected save slot (right?); yet in every dedicated server tutorial out there you see a server_save_slot config param in the cluster.ini/server.ini files. 

I just started a dedicated server while watching the logs and didn't see any mention of selected "slot" or "cluster"; I also deleted server_save_slot param from my cluster.ini file and the server started fine just the same, no warnings/errors/anything. It doesn't affect the directory where the world/save files are stored.

Has anyone bumped into this? How do you keep different worlds/saves when using a dedicated server setup, is it through manually creating different "start" scripts? Thanks!

[Daniel86268]

Only thing I could imagine is that you can define different maps to use on the same cluster without the need of creating multiple cluster folders.

That said I always just created a new cluster folder with it's own startup scripts for each server I've set up. This way I can keep mods and settings easily seperated on all clusters. Not considerably more space needed and very clean imo.

[myxal]

On 5/22/2018 at 7:18 PM, machete_kills said:

yet in every dedicated server tutorial out there you see a server_save_slot config param in the cluster.ini/server.ini files. 

Really? I had the impression everyone followed ToNiO's guides, and there's no mention of this parameter there (at least not in the linux one)...

On 5/22/2018 at 7:18 PM, machete_kills said:

How do you keep different worlds/saves when using a dedicated server setup, is it through manually creating different "start" scripts? Thanks!

https://github.com/myxal/DST-DS-Tools/blob/master/dstds_tools.sh

./dstds_tools.sh -s path/to/cluster

Detects all shards and starts them as needed. (There are a few bugs which I'm too lazy to fix) When making a new cluster:

1. Copy existing cluster
2. Create new token and replace the existing one
3. Delete save directories for each shard
4. Modify leveldataoverride, if desired
5. Modify ports for player->server and slave->master connection (not that I run multiple cluster simultaneously, but I don't want the servers to fail at startup because I forgot to shut down the other ones.

As for the parameter itself - yeah, it looks like it only has meaning when the cluster is run in the client. Not entirely sure what difference it would make anyway, as even my client-hosted cluster don't have this parameter configured - seriously, where are you seeing this?

[myxal]

EDIT (post will probably be squashed to previous one):

@machete_kills: Yesterday I was moving a single-shard world from client to dedicated server and I think I figured out what the deal is with server_save_slot.

• When you make a single-shard server in the client, the Cluster_x directory will only contain configuration files - modoverrides, leveldataoverride, various ini's etc.
• The actual saves (world + players) is kept under the client_save/session/<some_ID> - this applies to all single-shard servers on the client, and also for player's own data for any server they have visited.
• The game is able to tell which session ID belongs to which client-hosted server via the single saveindex file - you'll see a data structure like this:

  slots={
      {
        enabled_mods={
  		...
  	  },
  	  server={
  		...
  	  },
  	  session_id="..."
  	  ...
  	},
    -- more servers here
    {...},
    {...},
    ...
  }

   

So my guess is that the server_save_slot parameter is probably used when you're using a single saveindex for multiple servers, as the client normally does for single-shard servers. I have no idea how one would do this with the dedicated server (especially for clusters of servers), or even why would one do this, as IMHO keeping the saveindex separate for each cluster is the better approach.

[dread3ddie]

@myxal thanks for the update! Nice to find what it's for; also I agree with you, one should keep separate saveindex files for each cluster.

[Daniel86268]

On 1.6.2018 at 8:55 AM, myxal said:

IMHO keeping the saveindex separate for each cluster is the better approach.

Well, that would certainly not hurt, but considering that seperate clusters essentially are completely seperate instances, where the save index would only conflict if you would try to merge multiple seperate worlds into a single cluster.

It's as if you'd have a group of friends each one hosting their client world where you are jumping back and forth and you are telling them to use different save slots as a better approach. Doesn't really hurt, doesn't really affect anything though.