Linked/Embedded/Modular Modpacks

[RobertLupas]

Linked Modpacks

The idea:

I propose implementing a modular system for modpacks, enabling users to create and manage (similar) modpacks more flexibly and efficiently.

Explanation:

• At its core, the system would revolve around a base modpack that acts as a foundation. Additional mods can be incorporated into other modpacks, that also have the mods from the base modpack. These additional versions are dependent on the base modpack and automatically inherit any changes or updates made to it.
• From a technical standpoint, this feature involves developing a system that establishes dependencies between modpacks/modpack versions. Whenever a change is made to the base modpack, all dependent versions should be identified and updated accordingly.
• A feature like this ensures consistency across different versions and eliminates the need for manual updates.

Example uses:

• There could be a normal version of a modpack and one for people using NVIDIA graphics cards (which would add the Nvidium mod). The Nvidium version of the modpack would inherit any changes made to the base modpack. So when the base one gets updated, the NVIDIA one gets updated too.
• A modpack with a series of mods, but with 2 versions for looks: one with a more medieval style (with resource packs for UI, blocks, etc) and a more modern one.
  With modular modpacks, I'd do this by having a base modpack that focuses on mods and global resource packs, and 2 dependant modpacks, which inherit the base one, but add rustic/modern resource packs. Something to add here is there should be a way to make the base modpack private/unavailable to play as-is. So for this example, people couldn't play the base one, without any custom styles.

Other needed sub-features:

• As I wrote before, there should be a way to make the base modpack private/unavailable to play as-is and make only the "children" modpacks available.
• There should be a way to disable mods/resource packs/etc from children packs. This should be available to ensure there would be no compatibility issues.

Diagrams

• Relations between modpacks
  

[LINCKODE]

I was thinking of kind of the same thing.
Kind of like how Docker Images work.
You can have a base image (in this case a modpack) and then have other images that are based on it.

One thing to take into account though:

Let's say a user installs 10 packs that depend on pack "A". Then you'd have 10 installations of the same base pack plus the sub-pack specific mods / configuration / content / etc.
You end up installing the same mod jars 10 times, at least with how things are setup now. I wonder if mod loaders could work with symbolic links / shortcuts.

A second thing to consider would be:

What if a sub-pack depends on an old version from the parent pack?
Let's say Pack A version 1 has the following mods:

• Sodium
• Lithium
• Something else
  Then we make a pack B that depends on A version 1. This pack will add Indium for example.
  Everything is nice and good until you update pack A to a new version of Sodium, which Indium from pack B is not compatible with.
  Assuming that everyone could make packs that are based on other packs, then all of these authors will have to update their packs manually after every update of their parent pack.

[LINCKODE]

@half-real-SCRACX please don't take this as mean criticism, I like the idea, I was just thinking of some potential issues that would need to be worked around when creating such a system.

[RobertLupas]

For your first concern

I'd want the pack to behave just like any other one. So, if you download a dependent pack, the mods/resource packs/configs/etc. from the base one get downloaded with it. So, again, just like any other normal pack.

For your second concern

As I said in my original post (i think 😅), there could be ways to control the version of the base used. Also, there should be a way to disable mods from the base pack individually.

These are all things that I didn't really think about at first, but I think they could be solvable 😄

*when i say "mods", I mean anything from mods to resource packs and shaders.

[neirenoir]

Getting Nix working on Windows would be kind of a pain in the ass, but it is designed to solve the first issue flawlessly. It would not solve the second problem, but it could attempt to run the latest version if there is no version pinned by the root modpack developer.

[der-fruhling]

Having pack dependencies like this (some kind of inheritance) is an interesting idea. Unfortunately I can also see this being expensive on resources to keep, and making modpacks more difficult to review as each child pack would likely have to be reviewed separately.

As I wrote before, there should be a way to make the base modpack private/unavailable to play as-is and make only the "children" modpacks available.

Hiding the "base" packs would be a bad idea in my opinion, they should be available on their own alongside the child packs which contain additional/replacement content or features. Your next point ("There should be a way to disable mods/resource packs/etc from children packs.") supports this flow, as child packs could remove incompatible mods from the base pack if needed.

A modpack with a series of mods, but with 2 versions for looks: one with a more medieval style (with resource packs for UI, blocks, etc) and a more modern one.

I believe this problem is better solved by simply including both resource packs in the main pack. This gives both options without ending up with multiple instances, which would allow the player to switch without having to move save data over. In packs where the style changes require mods, however, this is fine.

From the standpoint of the server, having pack dependencies raises the question of how they should be represented in .mrpack files downloaded from Modrinth. If the pack references are kept "as is" and included in the download, they would have to be downloaded at runtime, which may be a problem if the intention was to install the pack in an environment without Internet access, but resolving them into a complete pack on the server may be a waste of resources, especially in situations where there are a ton of child packs that inherit large or many mods.

Finally, how in the world are we even supposed to create these things!? The only good way I can think of is to have something like a Dockerfile where you can specify parent packs and what modifications to make and have a tool to "compile" them into a finished pack. The Modrinth app could be made to support packs that inherit from one base pack, but if the feature were to support having multiple base packs things could get messy there would have to support combining packs.

And then, when those packs have conflicts (two mods with the same version, two overrides with the same path, etc.), which one should prevail? Should it be up to the user? When there are two config files, should they be merged? Is that too much to ask?

Would a normal user even understand how pack inheritance is supposed to work?

Just some guy on the internet's view on this. I've never contributed to Modrinth so I have no knowing of how difficult this would really be to implement.

[RobertLupas]

A modpack with a series of mods, but with 2 versions for looks: one with a more medieval style (with resource packs for UI, blocks, etc) and a more modern one.

I believe this problem is better solved by simply including both resource packs in the main pack.

This might not have been the best example 😅

In packs where the style changes require mods, however, this is fine.

👍

From the standpoint of the server, having pack dependencies raises the question of how they should be represented in .mrpack files downloaded from Modrinth. If the pack references are kept "as is" and included in the download, they would have to be downloaded at runtime, which may be a problem if the intention was to install the pack in an environment without Internet access, but resolving them into a complete pack on the server may be a waste of resources, especially in situations where there are a ton of child packs that inherit large or many mods.

IDK what the best way to implement this would be, on the server/storage side...

Finally, how in the world are we even supposed to create these things!?

You kinda responded to this yourself :)

The Modrinth app could be made to support packs that inherit from one base pack

but if the feature were to support having multiple base packs things could get messy there would have to support combining packs.

I don't think that should be a feature. One base pack for another one should be enough...
And in the "worst" case, sub-packs could also be unallowed. (so you couldn't make something like base pack->child pack1->child pack 2 that uses child pack 1 as a base)

Would a normal user even understand how pack inheritance is supposed to work?

Only pack creators should be able to understand them. The feature should work in such a way that users don't have to do anything differently from using a normal pack.

[Prospector]

In my opinion, this is extremely complicated for a very niche use case. It'd require a lot of development work on Modrinth's end, all the launchers that support Modrinth, and makes making modpacks way more complicated.

Ultimately, mrpack is just a distribution format that defines a pre-configured instance. This sounds like a modpack creation toolchain you could build which could export to mrpack.

[Gaming32]

At least a basic single linking version is not a niche use case. For good performance and OF features in modern versions, there are many mods that are required. For this reason, optimization packs exist. It's currently very annoying to develop a content pack, as you have to manually include and configure potentially dozens of client-side mods that have otherwise nothing to do with your pack. Some content packs do this by copy pasting the contents of an optimization pack, such as Adrenaline or Additive (I've been on a team that developed two content packs this way). It would be exceedingly useful to be able to make a pack that's "based on" another pack. Think of it like inheritance in an OOP language, or using a template repo/forking on GitHub.

[Prospector]

Again, this is entirely a modpack creation-end thing. It would be kinda a nightmare to have upstream changes coming into your modpack because a new mod is added or configured in an unexpected way.

You can build a modpack based on another in the Modrinth App very easily by downloading the pack, unlinking it, building your modpack on top of it, and re-exporting it. I can't see why as a modpack author who is building a tailored experience would want to deal with extra upstream headaches then you already have to with updating mods.

[RobertLupas]

Wait, you can? Still, a simple implementation (without really complicated extra features/stuff) could be possible. And it doesn't need to be complicated. Just like @Gaming32 said, a very basic way of doing this would be really usefull for many people.

[neirenoir]

You can build a modpack based on another in the Modrinth App very easily by downloading the pack, unlinking it, building your modpack on top of it, and re-exporting it.

But what if we want to let the players customize the pack depending on their hardware? Say, the Nvidium case. Packwiz can help with the modpack development side of things, but it does not let the player configure the modpack.

Worst case scenario, you update the entire modpack as if it was a mod, or pin/override a specific version of a specific modpack or mod in case of incompatibilities.

[RobertLupas]

I think that if this is discussed and thought through, it could be an awesome, neat, and extremely used & useful feature.

Drop your thoughts/suggestions here! :)

P.S.: I'd be happy to code this in myself (or at least a part of this)!

[DJMoffinz]

As a Modrinth user I honestly would love this and use it all the time
I use Simply Optimised, but I also have mods that I like on top of it, and its annoying seeing that SO is getting updates, and I'm not getting them
if I want them, sooner or later I'm gonna have to download SO again and move all my worlds and extra mods over
I think Prospector's latest comment about a separate piece of software might do the trick, but it might also be something geared more towards pack makers than end users who just wanna play Minecraft

[RobertLupas]

That's exactly one of the use cases I thought about
I think this feature should be integrated into Modrinth itself. It could be done in a not-so-hard way (probably). And if broken up into smaller tasks, so that more people can work on it, I think it'd be feasible.

[Julynx]

What about having the ability to add modpacks to a modpack in the same way as mods?

This would allow for a similar functionality as what is described in this thread. You first create the Core pack and then you create the Medieval pack and add the Core pack to it, plus any other medieval specific mods and texture packs you want.

From my PoV this would make reviewing modpacks easier, as if the Core pack is already approved, you dont have to inspect any of its mods to review Medieval, just the extra ones.

In this model it doesn't make sense to modify anything included by the Core pack when you are editing the Medieval pack because it is treated as a unit included in the modpack.

To build modpacks like this in the launcher, you simply add modpacks to the modpack in the same way you would add mods.

[RobertLupas]

This is probably the best way to implement this! Good idea!

[Julynx]

I would love to see this functionality added in some way!

Right now it's kind of tiresome to build themed modpacks, as you have to manually add and configure every optimization and QoL oriented mod to build a Base modpack before you can add the mods that actually define your modpack.

Cloning an existing modpack, then unlinking it and manually adding the extra mods doesn't really fix this problem, because in the process of creating the new modpack you will probably need to add or configure a mod or two from Base, and you can't easily update Base and rebase from it at that point. Instead, you now have to manually keep in sync two versions of basically the same mods in two diferent modpacks.

In my proposed solution, if you want to add or edit the Base modpack, you simply do it, then update the Base modpack contained in your new modpack to receive those changes, in the same way you update the mods inside your modpack from the Modrinth launcher.

To me this seems like less of a dependency hell than having to manage different copies of the same mods inside different copies of modpacks.

[neirenoir]

Modpacks being treated the same as mods inside of a .mrpack file would be great! It even helps with organizing stuff by categories.

[neirenoir]

I think .mrpack v2 getting some bespoke support for modular modpacks would be great. The idea would be to be able to make small packs and use them as Rust traits (i.e. instead of having to manually include all the optimization mods manually in every modpack, just include a small pack of compatible optimization mods). In turn, these modular modpacks (and mods themselves) could make use of some oredictionary-like feature applied for modding, where developers can tag their mods or modpacks with a list of traits, or subsystems they provide (imagine a mod provides a hunger overhaul subsystem; it would make no sense to combine it with another hunger overhaul system, so they could be mutually soft-exclusive). In case of redundant providers inside of a modpack, the user could be prompted with a wizard to configure the provider to use.

This providers system could solve the Nvidium/Rubidium dichotomy presented in the OP, as both provide the Sodium trait/subsystem. There is also no need to make a complicated tree if it is all done horizontally or as layers.