Spotting outdated mod configuration?

[myxal]

Hi all.

I'm running my server for the "very long run", and already noticed several times where a config option was added to a mod on an update. I noticed when it actually broke the mod or game, but there are probably more mods with uninitialised configuration options.

Is there a programmatic way to check a modoverrides.lua file against all relevant modinfo.lua files, if all the options are specified? Or perhaps a line in server log when launching such a server, which I should look for?

[Daniel86268]

Usually all mods have a default config value that is used if not declared otherwise in the modoverrides.lua. (Unless a mod is so badly programmed in a way that the default config options are undefined/broken, in which case you probably shouldn't use said mods on a server anyways.)

If mods are breaking after updates of either the Game or the mod itself, it's either because they became incompatible to eachother (for a short period of time) or that the Save file got corrupted a little. (I'm assuming with breaking you mean that the game/server doesn't start anymore.)

If you really want to keep track of all config option updates the mods do, you can just install all those mods in your client, and every time before you launch your server you launch your client, let it generate all the config files, and compare those with the created ones from your server. (There are softwares for comparing script/textfiles with eachother that tell you the exact differences.)

[myxal]

Hi @Daniel86268, thanks for taking the time to respond.

23 hours ago, Daniel86268 said:

(I'm assuming with breaking you mean that the game/server doesn't start anymore.)

Actually, no - I mean "breaking" = things that worked don't work anymore. This almost always refers to the mod. (eg. Divining Rod X started crashing the game when the item was equipped by a player after an update introduced the "sort" option; I will look into the modinfo to see if the default is set or not - I have seen another mod where a default was set to an invalid value for the option, but those cases are very rare, I think, and I don't remember ever seeing a mod where the default for an option was not set at all).

23 hours ago, Daniel86268 said:

You can just install all those mods in your client, and every time before you launch your server you launch your client, let it generate all the config files, and compare those with the created ones from your server. (There are softwares for comparing script/textfiles with eachother that tell you the exact differences.)

Hmm, looking up mod names from workshop IDs gets really old after ~10 mods, but I could just move the cluster files from DS into the client. Would that work?

23 hours ago, Daniel86268 said:

in which case you probably shouldn't use said mods on a server anyways.)

...  (flashbacks of Firefox 3) ... Nevermind, I'm not going to rant here.

[Daniel86268]

8 hours ago, myxal said:

Hmm, looking up mod names from workshop IDs gets really old after ~10 mods, but I could just move the cluster files from DS into the client. Would that work?

Technicially you could, but you'd have to move your mods every single time when any of your mods get's updates, and since that's very hard to track on a dedicated server you'd have to track that every time to be sure. It's much easier to just look up all mod IDs once, even if it takes some time and enjoy the easy updates on a button press.

[myxal]

3 hours ago, Daniel86268 said:

you'd have to move your mods every single time when any of your mods get's updates,

Wait, what? (I'm not sure what you mean by moving mods - mod code?) My DS gets all its mods through just 1 or 2 collections on Steam, so even if I wasn't already subscribed to every mod used by the DS (which I am), I could just toggle the 1 or 2 subscriptions and get the latest version on the client as well.

My complaint about having to look up mod names against workshop IDs was aimed at making comparison between modoverrides.lua from server and client - either I wouldn't configure the client and then most of the file would differ, or I'd have to replicate the configuration by setting the mods in client's GUI. My intention is to move modoverrides.lua from the server (or possibly the whole cluster) to the client, and run the cluster on the client. I haven't actually thought about not having a mod used on the server installed on the client - good catch  

[Daniel86268]

2 minutes ago, myxal said:

My intention is to move modoverrides.lua from the server (or possibly the whole cluster) to the client, and run the cluster on the client.

That should be easily possible. Just copy/paste into an existing cluster or straight up copy over the entire cluster should do the trick (Maybe with some modifications like naming of the Master and Caves folders.), as long as you have all the mods installed as well. Just keep in mind to copy it from both Master and Caves worlds, if you have both.

[myxal]

20 hours ago, Daniel86268 said:

That should be easily possible. Just copy/paste into an existing cluster or straight up copy over the entire cluster should do the trick (Maybe with some modifications like naming of the Master and Caves folders.), as long as you have all the mods installed as well. Just keep in mind to copy it from both Master and Caves worlds, if you have both.

Well, not quite... I managed to get the client to load the cluster data (saves, snapshots, etc.) by putting it into the cluster directory previously occupied by another cluster (putting it into a cluster directory which the client considers empty or "occupied" by a client-hosted game won't work), but the mod configuration is still loaded from somewhere in the client data - the modoverrides.lua files copied into the cluster's server directories just get overwritten.

The modconfiguration for all slots is saved in .../client_save/saveindex, so I pasted the relevant portion of modoverrides.lua there (intentionally leaving out some mod's configuration to test this) and.. The modoverrides.lua files were left untouched. I had to delete them to make the client regenerate them.. which it did, and with correct (updated) configuration, but the sections were in completely different order from the original file.. 

So, meh... this is about as much hassle as just making a blank cluster with all DS mods enabled. and then just comparing the sections from DS's modoverrides with the generated file.