search

TeamAOF / All-of-Fabric-1

Modpack containing the latest & best Fabric mods!
35 stars 6 forks source link

Modpack updating support in MultiMC #46

Open peterix opened 4 years ago

peterix commented 4 years ago

I'd be interested in some collaboration on this. Giving fabric packs and fabric itself some visibility would be interesting.

Poke me on discord, or feel free to list any and all things you would expect from such a feature.

valoeghese commented 4 years ago

image

Yoghurt4C commented 4 years ago

suggestion: implement a per-instance vfs like you do for jarmods, but instead make instances load files from them on startup as if they were in their mods folder; that would allow people to easily keep their client mods intact while updating manually or otherwise, without you having to bikeshed over-complicated methods of arbitrary jar preservation during updates

Prospector commented 4 years ago

Or diff the mods between pack versions and only remove mods that were shipped in the previous version of the pack and are no longer in the current version. Ignore any unrelated to the pack.

asiekierka commented 4 years ago

I still insist that cooperation with the MCUpdater team would be a very, very good thing.

peterix commented 4 years ago

@valoeghese That seems like a good start. Solving the problems with that version of it would easily encompass 90% of what is practically needed.

@Yoghurt4C The jarmod thing in MultiMC is more of a hardcoded build step for the game jar during launch, not really a vfs.

I started looking into the proper vfs stuff (actually making the game believe the filesystem looks different), and have a small prototype of it on linux. The general solution is ... a lot of work and would delay everything considerably, especially with three desktop OSs.

It's something I'll chip away at for the next few years, probably...

@Prospector This can be achieved to some extent by saving the image of what was originally installed and using the original, current and target state during the update.

It's probably not that valuable to model this, because if you are customizing the pack a lot, you will end up with weird stuff that needs resolving anyway. Think on the level of non-trivial merge conflicts in git. Gameplay issues, broken worlds, bugs not present in the actual pack... at that point, you are on your own.

I assume the 'baseline' here should be that people either don't customize, or add small things here and there (client side, visual or perf optimization mods). Target would be personal packs, private servers, that sort of stuff.

Detecting when things went off the rails and warning the user about it is probably a good idea for version 1. I'd put anything more involved into version 2, or 3.

@asiekierka Cooperation? Maybe. Last I looked, it didn't seem to fit. Too much detail, too specific about mod loaders and libraries. I'll give it an another look.

Some loose ideas...

You know how MultiMC has this export dialog where you mark files as included or excluded? That's fine for turning an instance into something other people can import. But it's not for a 'modpack'. A modpack needs to deal with other things like a server and client version. And for updates, it may be necessary to mark files to be treated slightly differently based on what they are.

So, think the export dialog, but extended to tag files as client/server/mod/config, or give them update behaviour (must be exact, allow diff, etc.).

I think the UI for it wouldn't be that hard to make, because I already have some of it.

Again, version 2 or 3. I think version 1 should be minimal. Just enough to do the job with the assumption that the user is playing on a server and diverging from the pack would break it.

Modpacks should have minimum/maximum/optimal Java heap info. This should be separate from the actual user settings.