Base new modpack on existing pack

[seanwcom]

Just like you can base a new build on a previous build, it would be nice to be able to create a new pack based on an existing one. In my case I have my normal pack and I'd like to create a "plus" pack that is exactly the same, but with a few extra client side mods.

As long as I'm blue sky dreaming, it would be VERY cool if you could not just build the new pack based on an existing one, but keep it linked so that updating the main pack modified any linked packs as well. So for example, if I update BuildCraft in the main pack, the linked pack would be updated automatically.

[sct]

Hm. Instead of it being like I do builds, it could use a modpack as a "base." Along with that a new option to hide a modpack from the API. (Ill explain why in a moment)

So, you create your base modpack and set it to hidden. You add in all your mods you want to be across all the versions of your modpack. So, all the core mods obviously, but lets say you don't include forge/optifine/tweaks.

You then create two new modpacks, one called "Super Pack Ultra" and "Super Pack Lite." You "base" both of these modpacks off of your "Super Pack Base" modpack. They will inherit any mods in the base pack and add in whatever you include specifically in them.

This should let you do what you want and also add a lot more flexibility to modpacks. What do you think?

[seanwcom]

Sounds great!

Would you also set it up so that the inheritance remains in place? In other words, if I make a change to "Super Pack Base" (after creating "Ultra" and "Lite"), would you expect "Ultra" and "Lite" to get those changes as well?

That's what I imagine should happen, but it may be something you could choose when creating a new pack. I don't run a lot of packs myself, but I can imagine a scenario where you'd only want to create a new pack based on another one, then have no more inheritance from the base pack.

For my purposes, however, what you've described is perfect. :)

[sct]

Thats the idea. You would link the new packs to the "base" pack. Any changes in the base pack would always be mirrored to the packs that are children of it. You won't be able to edit the base pack from a child pack. Just add to it.

[Razorskills]

So.. Im wondering if this is something that is already added? Or a work in progress still? Right now I am am manually updating the recomended version for normal users, the latest version has all the extra addon stuff and this is all I need it to do. But I also have a Lite version that players must select manually to use. Is there a possibility to have 3 versions that check if there is a newer version?

Then I can set my laptop to the lite version and when there is an update, i don't have to fidle with the settings. But when Im on my main comp. I have it set to Latest, this gives my gaming rig shaders and other extra features. But at the same time the Recmomended is right in the middle but they all will ask if I want to update to the current version of 'Lite' 'Recommended' or 'Latest'..

I think that makes sense what Im trying to say.

71

[Indemnity83]

Is there any motivation to having more than one base mod? Could make an impact on implementation.

I see two ways of achieving this:

1. Add two fields to build management, the 'base build', and 'base build version' (recommended and latest would be options here too).
2. Implement functionality very similar to the Add a Mod section, but with modpacks instead. This would allow an unlimited number of "base mods" to be merged into a single deliverable.

I lean towards the second option, it shouldn't be significantly more difficult to implement, but I'm not sure if its really necessary.

In either case, when the mod list is generated for this build the mods from the selected version of the base build would be pulled in too (would require changes to both the API and views). On the views the mods should show up with the buttons to change and remove as disabled (or removed).

[Indemnity83]

After sleeping on it, the second option seems the most robust and lets admins group together common mods (like for example, the three parts to Thermal Dynamics) and manage them in one place, but use them in multiple distributions.

I'm going to put together something for this, see how it works out.

[Indemnity83]

I have the GUI working for this over in my development branch. The missing piece right now is that it doesn't present the base modpack in the API requests. I'll work on that soon. There are some pinch points in the functionality that I'm particularly interested in getting some feedback on now though:

I've chosen to implement base modpacks such that the final modpack must have a unique list of Mods with no duplicates. So that means I have to check before a mod or base modpack is added that it doesn't create any duplicates in the list. I've tried to do it efficiently, but it may become a problem for large packs. And there are still gaps in this coverge, there is nothing that prevents a user from modifying a base pack after its been added to another modpack, causing duplication.

So I'm starting to wonder if its even necessary to do all of this, it may be easier to just let the user duplicate a mod between base packs, and the current modpack but only return the latest mod on API calls.

Anyway, I'd really like it if anybody wanted to weigh in, and if somebody would take a look through and possibly try out the development branch I have (don't use it in production, the API wont return the correct stuff)

[Indemnity83]

Nobody? There was a lot of activity on this at one point and its tagged for the next release, but its difficult to make progress without any feedback.

[EntranceJew]

I had to take a moment to read through this, but the second proposed workflow definitely is more flexible for modpack creators and clients. As far as base modpack resolution, I think you've done it about as best as you could have without altering the established program flow too much.

I don't know if silently failing by reporting the latest mod is the best idea, the modpack creator could easily overlook that without any sufficient warnings.

The only thing I would change is adding a bit more details like what base/mod is conflicting with whichever they're trying to add, to make things a little easier to deal with. There will probably be circumstances where a user wants to add a mod that conflicts with a base pack, which will result in one of two things if they absolutely need that mod version:

• The user makes a new version of the base pack without the mod in question.
• The user imports all the other mods from the base pack and changes the conflicting mod with the version they intend to use. ( which would be a case for #71 )

The same goes for adding a base pack that conflicts with another base pack.