thunderstore.io mod support

[eksime]

Hey, I've been using this without any issues for quite a while - thanks for putting this together!

This suggestion follows on from the discussion in #282 - It would be great if there was a configurable method to install and update thunderstore.io plugins by setting environment environment variable(s)

It looks like this functionality is somewhat present in order to update BepInEx:

https://github.com/lloesche/valheim-server-docker/blob/3fec572aa9844a90b06dd38f6d05d18b7ff61a43/bepinex-updater#L18-L20

Thinking about how this could be implemented, one way could be to extract this logic into a function, that takes a username/plugin combination i.e. denikson/BepInExPack_Valheim.

I realise there is much more that would need to be refactored for this to work (merge files etc) and there would need to be a way to enumerate/iterate the installed plugins for: https://github.com/lloesche/valheim-server-docker/blob/9a9b1110f9dc32a0cd5f97f089a27dafc4a83a63/valheim-updater#L76-L80

It's possible this method may be usable for Valheim Plus too, as it's also on thunderstore.io and has a dependency on denikson/BepInExPack_Valheim

One last thing to note is that BepInEx seems to allow plugins to be in subfolders within /opt/valheim/plus/BepInEx/plugins/ which may make separating plugins for updating/file operations easier.

[lloesche]

I had a working version of this for testing back when I added BepInExPack support. But discarded it later because people on my Discord didn't like their server auto updating their plugins. The issue goes beyond separating folders or making sure that a thunderstore mod doesn't conflict with e.g. a Nexusmod that the user manually added. The main issue was that some mods are server only and some require users to also run the same version. Now if the server updates to the latest version and half of your players don't have that version of the mod it's an issue. I had added a workaround where on mod update I would zip the plugins folder and use the status httpd so everyone could download the exact version the server was using but then players would also get the server only mods, so you'd have to track which mods are client/server and which are server only. The other issue was deciding when it is safe to overwrite config files and when not to. I.e. if you get a new version of a mod it might not be compatible with an old cfg but you don't just want to replace the cfg as the server admin likely modified it. So you'd have to track config file modifications or other customizations before removing the old mod and adding the new one. In the end I decided it was too much trouble and people seemed to prefer manually maintaining their plugins folder anyways. That said if you or anyone else would like to take a shot at this I'm happy to merge any good PR that solves those issues. It's not like they can't be solved, it was just more work than I was willing to put in.

[stabbthehuman]

I'm working on building out a heavily modded server for my friends and I and I'd like to employ the zipped plugin folder method you have mentioned. Could you elaborate a bit on how you are pushing the compressed plugin file to a status page?

[nbusseneau]

Hey, just voicing my support for this because managing server mods via integration with Thunderstore directly from the server itself would be tremendously helpful :)

Basically on my end the ideal scenario would be to provide a dependency list, e.g. (thunderstore.toml dependencies format)

Author1-Mod1 = "X.Y.Z"
Author2-Mod2 = "X.Y.Z"

or (r2modman dependency string format)

Author1-Mod1-X.Y.Z
Author2-Mod2-X.Y.Z

and then all of the mods from the list are automatically downloaded on next server start (even better if it works with RESTART_CRON, without need to restart the container at all).

This way, dependencies are pinned and server admins retain control over mods, but it's still mostly automated. Configs are a non-issue in my opinion if dependencies are pinned: server admins already know they need to check for configs changes on mod updates.

As for player-side mods, it's out of scope in my opinion: server admins should also already maintain a separate modpack or modlist for their clients, so whenever they update the server-side mods they notify or block the clients (depending on mods, some have blocking via Jotunn checks for example). Sending mods to clients should definitely not be handled by the container, this responsibility falls on r2modman or whatever method of choice the server admin enforces for their clients.