Jump to content

Adding or removing mods mid-game on the server


Recommended Posts

(Moving my post here since it got zero replies in the Vintarian forum.)

Hi! Having recently bought the game, I'm starting a small coop server for my friends. Part of the setup is deciding which mods to use - I considered using none, but I think I want at least Primitive Survival and the Gravemod.

However, do I have to pick a list and stick to it (really hard when I know we won't get to test some parts of those mods before having invested dozens of hours in our world), or is it possible to add or remove mods mid-game without destroying the savegame? Some posts on the forum had me worried, especially this one:

I'm interested in the technical details of what goes on behind the scenes with block ids and what not when you add or remove mods. From my memories of Minecraft, I think it handled this pretty gracefully? What approach was taken here?

Thanks!

Link to comment
Share on other sites

IMO, adding mods at any time isn't much of a big deal.  Never hurts to back up your saved game more often when doing so, but I've seen it done many many times on various Twitch streams without incident.

Removing mods is a bit more problematic (for obvious reasons).  In general, one could expect in game blocks to simply transform into white blocks with question marks, because those blocks were a part of a mod that no longer exists, and you could run around and break them because they are simply an eyesore.  But some mods are more complicated than that - they add more than just content, so removing them would take careful consideration.  

There are cases like you've linked to above where block mappings have gone "off the rails".  I'd like to think that it's uncommon, but it can definitely happen.  
 

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Mods like that LIchen one should really have a graceful degradation on uninstall. There is a server command that helps remap blockIDs back to where they should be. It's a shame that more mods don't think of what happens when they are uninstalled. There should really be an "OnUninstall" method for all ServerSideModSystems, and the rule should go that you Uninstall the mod via the mod menu. That way, you'd have the graceful degradation built in, as part of the culture of VS mod management.

There is no overriding "Vintage Story Modding Ruleset", so each mod is handled by the developer. There are a range of skills within the modding community, ranging from absolute beginners who need help installing Visual Studio, to people who've been coding in .NET for decades, and have only had the learning curve of game development to contend with. The codebase itself is much better than most games I've modded before, but it's still pretty sketchy for a .NET codebase. It doesn't follow C# Coding Standards, and a lot of the game doesn't follow its own design patterns. Especially the GUI. Some of it is ported directly from Minecraft mods, and just run through a Java to .NET converter. There are Get/Set methods where Properties should be being used, and there are lots of exposed public fields which shouldn't exist. Resharper tries to sit you down and give you a good telling off if you try to match the naming conventions and coding styles of the vanilla game. It needs a major overhaul to make it consistent, and compliant.

A lot of the "Essential" mods like CarryCapacity, etc., are very easy to uninstall. The less the mod touches the block registry, the better, when it comes to hotswapping. It's like trying to hotswap minecraft mods though. Ripping Botania out of a pack might leave huge clumps of barren land where flowers once grew, but compare that to ripping Biome's A'Plenty out of a pack...

  • Like 3
Link to comment
Share on other sites

Thanks for the in-depth insight @ApacheTech. I hope the messy codebase doesn't end up slowing development to a crawl through bug explosion as features pile up, or forcing a major months-long refactor.

The OnUninstall method sounds like a great idea that should be introduced sooner than later.

As far as the remapping command goes, it seems pretty limited? IIUC you have to map each missing ID to a unique valid ID. But if you had built, say, Lichen tents with their various blocks and just want them to disappear and be replaced by air i.e. all by the same ID, it doesn't sound easy?

Link to comment
Share on other sites

6 hours ago, BearWrestler said:

I hope the messy codebase doesn't end up slowing development to a crawl through bug explosion as features pile up, or forcing a major months-long refactor.

It will cause issues eventually. It will definitely stunt the scalability of the game. The biggest crime is using public fields, and not following C# naming conventions. That last one is the one that infuriates me the most. I think both are remnants of Java that need to die in a fire. Just a single auto-cleanup through JetBrains Code Analysis would solve a huge number of problems, including spelling errors, and casing issues. Part of the codebase uses the Strategy Pattern, but there aren't nearly enough interfaces. The GUI, especially, is very tightly coupled, and lots of things are hard-coded where they shouldn't be. I've seen this GuiComposer used in Megaquarium, and it's just as terrible there. It's really difficult to edit, and really steep learning curve to make your own. Even ImgGui for C++ is easier to work with! But, with enough adaptors, visitors, and extension classes, you can make your own modding framework that hides all the mess, and allows you to make rapid roll-out code mods, in a really elegant way. :)

6 hours ago, BearWrestler said:

As far as the remapping command goes, it seems pretty limited? IIUC you have to map each missing ID to a unique valid ID. But if you had built, say, Lichen tents with their various blocks and just want them to disappear and be replaced by air i.e. all by the same ID, it doesn't sound easy?

You can run the command `/fixmapping applyall` to fix issues with invalid Block IDs. You can also run `/bir [getid|getcode|remap]` to manually remap blocks after uninstall. This is what the mod author should handle within their uninstall process. However, this is an issue for Multiplayer Servers. You really shouldn't rip mods out of an SMP world, mid-season. The player-base should be involved in the process, and given plenty of time to prepare for the removal of a large mod. Some form of compensation may be needed by the Admin. I could only imagine what would happen if Better Crates was ripped out of Aura Fury SMP. I've spent over 1,000 copper ingots upgrading them so far, and I'm only half way through! I'd want some form of reparations from the Admin Team if they decided to pull the plug. Removal should first be done on a backup of the world, so that you know what to expect on the production server. In a Single Player world, you can just change game modes, and get back anything you lost, and change any blocks that need changing.

  • Like 2
Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.