Ability to import a modpack to a profile

Brittank88 commented 2 years ago

Currently, installing modpacks does not create profiles for them, so you cannot switch to a profile in order to start adding or removing mods from that modpack.

Modpacks such as Fabulously Optimized are designed with some intent of acting as a 'base pack' for modpack creators to extend from. I see no way currently to do this with Ferium.

theRookieCoder commented 2 years ago

So basically specify a list of version IDs to additionally download?

Brittank88 commented 2 years ago

So basically specify a list of version IDs to additionally download?

Well... I am not sure this will preserve pre-configuration performed by the modpack creator. It's more than just the mods themselves.

It would be better if there was some way to tell Ferium that the modpack it is adding should have a profile created for it.

theRookieCoder commented 2 years ago

I am not sure this will preserve pre-configuration performed by the modpack creator

I don't really understand what you mean? Do you think there should be more user customisability than just adding mods?

Brittank88 commented 2 years ago

I don't really understand what you mean? Do you think there should be more user customisability than just adding mods?

I'll try to elucidate this with an example. If I were using Fabulously Optimized as a base pack and extending from it, I would download it in GDLauncher, then edit the pack and start adding my own mods.

If you just specify mods to additionally download, what happens if you want to add or remove some more later on?

I guess the best way to describe what I'm asking for is the ability to modify the set of mods used by a modpack at any point in time via Ferium, akin to how most GUI-based launchers would allow you to.

JustSimplyKyle commented 2 years ago

So smth like ferium modpack edit add-modrinth iris (There should be a better syntax than this)

JustSimplyKyle commented 2 years ago

It would be better if there was some way to tell Ferium that the modpack it is adding should have a profile created for it.

Maybe ferium profile --import --curse-modpack id could work? This will only import the mods tho. Any "pre-config" would be lost if you want to turn modpacks into profile

Brittank88 commented 2 years ago

It would be better if there was some way to tell Ferium that the modpack it is adding should have a profile created for it.

Maybe ferium profile --import --curse-modpack id could work? This will only import the mods tho. Any "pre-config" would be lost if you want to turn modpacks into profile

Well you'd specifically want to keep any other configurations that the modpack author has created. If Ferium supports downloading a modpack why is it so difficult to just say "hey this should be a profile btw!!"?

I think in general when you install a modpack it should automatically be assigned a profile so you can manipulate it just the same as anything you setup yourself. The separation it has now feels very restricting.

theRookieCoder commented 2 years ago

This would require a fundamentally different method of dealing with modpacks. What about we keep the existing modpacks, and if you're a tinkerer, you can import a modpack's mods into a profile. This would require #82 though

What do you guys think?

Brittank88 commented 2 years ago

That would be good - would it be possible to also transfer any other configuration files? The copy of the modpack potentially wouldn't work at all without it.

At the very least it should advise that you will manually need to copy over any other files, however automating that would be preferable.

theRookieCoder commented 2 years ago

would it be possible to also transfer any other configuration files? The copy of the modpack potentially wouldn't work at all without it.

Yeah, that's one of the downfalls of this method. I guess it should download and install the overrides to a folder when you first create the profile so that the user can deal with it. This 'mode' is more for more advanced users so that's better right?

Brittank88 commented 2 years ago

That does sound better!

abhemanyus commented 2 years ago

Has this been implemented?

theRookieCoder commented 2 years ago

Nope. If something has been implemented, the issue will be closed :)

arlyon commented 2 years ago

The way this currently works feels odd to me. As it currently stands, if I import a modpack and upgrade it, the mods will replace my current mod profile rather than augment it. I feels odd that there are separate commands for upgrading your current profile and the modpack, as the concept of a profile is not respected at all by the modpack. It really makes modpacks feel like an after thought. Add on top of this that I can switch modpacks without impacting the profile, and vice versa makes it clear that modpacks and profiles should be treated as the same thing, with a modpack acting as a profile base or equivalent which can be extended.

As it stands, here is what happens when I try to install the 'fabulously optimised' modpack and add some mods on top, and here is what I'd expect:

> ferium profile create --name default --mod-loader fabric --game-version 1.19.2
> ferium modpack add 396246 # this adds fabulously optimised
> ferium modpack upgrade # ok, it's installing something, but the user mods are not included...
> # source the missing mods and place them in the user folder, but how do I install them?
> ferium list # empty? I'd assume the modpack mod list to be included here with some metadata
> ferium upgrade # does nothing, ok thats odd, I need to copy the user mods over!
> ferium add 32274 # this adds journeymap
> ferium list # ok, one mod added, maybe it will copy over my user mods now?
> ferium upgrade # wait, where are my mods? let me check which modpack I have installed
> ferium modpack # hm, this doesn't tell me anything, maybe list?
> ferium modpack list # ok, so its selected but not tied to my profile or installed. odd

I would expect a modpack to be the base layer, with additional mods optionally being installed on top, and it seems odd you can simultaneously be using a profile but not have the mods for that profile installed, or have your modpack selection updated.

theRookieCoder commented 2 years ago

ferium list # empty? I'd assume the modpack mod list to be included here with some metadata

This just lists the mods in the current profile. To list the modpack you have, you should run ferium modpack list

ferium upgrade # does nothing

Again, this downloads mods in your current profile. To download a modpack, you need to run ferium modpack upgrade

ferium add 32274 # this adds journeymap

Again, this adds the mod to your current profile. You have to realise that the mods profile and modpack is completely different and function independent of each other.

I would expect a modpack to be the base layer, with additional mods optionally being installed on top

That's what this issue aims to (at least partially) solve.

I think the rest of your doubts can be resolved if you understand this

theRookieCoder commented 2 years ago

I recommend that you read the documentation on adding a modpack, installing it, and managing it.

arlyon commented 2 years ago

I think the rest of your doubts can be resolved if you understand this

I do understand, I am just leaving a user story / context to why new users may be confused by these two concepts (profiles and modpacks) given that they are semantically very similar. At the very least, a warning message to notify the user when they exit 'profile mode' and enter 'modpack mode' would go a long way (happy to write a PR for it! :smile: ). I will also note that (unless I am missing it) that it states nowhere in the docs you linked that these features are completely incompatible even going so far as to call modpacks 'profiles' (https://github.com/gorilla-devs/ferium/blame/main/README.md#L198) (also happy to open a PR :) ).

theRookieCoder commented 2 years ago

happy to write a PR for it!

I'd appreciate that! I'm currently not really sure how to clarify something like this, a PR would be of great help!

even going so far as to call modpacks 'profiles'

Sorry that's my mistake, will fix ASAP!

lucaszischka commented 1 year ago

Hello, first of all I would like to thank every collaborator. Second of all, I would like to give a quick opinion on this topic ;).

Description

Before I start writing about my opinion I will to summarise the goal, because there have been misunderstandings:

Ability to add/remove mods to/from a modpack. Optional addition: Ability to combine modpack's.

Possible Solutions

I looked a some modpack's and realised, that a modpack is often more than just a list of mods with their versions, but also can have pre-configurations, texture packs and a couple of other things in form of overrides. Also really important is, that any part of it can be changed with a new version of the pack. Let's have a look on how these parts of a modpack would perform with the proposed solutions (who solve the issue as described in the description) and other ones I can think of and make sense.

Solution 1

Allowing a modpack to be edited (eg. ferium modpack mod remove).

a) The modpack would be added as usual.

No mixing of modpack's will be possible.
- There is probably a way to do this, according to the concepts form Solution 2.

b) The modpack would be upgrade as usual.

The user needs to fix incompatibles between custom added/removed mods with newer version of the modpack itself.

Solution 2

Getting the modpack's mod list and overrides, then adding it to an existing profile, which then can be edited as usual.

a) The mod list would be added.

b) The overrides would be added.

Overrides between different modpacks could conflict.
- A priority ranking system could help.

c) The mod list and overrides would be updated on upgrade.

The user needs to fix incompatibles between custom added/removed mods with newer version of the modpack itself.

d) The mods would be upgraded individually to their latest version.

This could be problematic if mods are not compatible on their newest versions. This could be fixed by #82.
- However the user would be forced to figure out incompatibilities, and resolving them, on its own (especially if they appear not on creation).

Solution 3

Merging profiles and modpack's (which both 1 and 2 more or less already do; in other words: if 1 and 2 would both be implemented, they would be indistinguishable from the end user perspective, except for missing multi-modpack support. in 1).

Would clear up unusual confusion from an end user perspective.
Changing the basis of how you currently deal with modpack's and profiles will be much work, as well as either braking backwards compatibility or make your live even harder if you decide on adding backwards compatibility.

Personal Conclusion

I think Solution 3 would be the best and I personally don't understand where the split came from in the first place, as other mod(pack) tools and launchers don't have this split and limitation. However im also not a rust, nor Minecraft modding programmer and therefore don't have the expertise to judge. But if it is be possible and the goal of ferium is to get a full fleged cli alternative to other Minecraft launchers this will be sooner or later a must have feature. So I think even if the structure of profiles and modpack's is currently fundamental different, it would be worth the work.

On the other side if this is not possible in rust at all or you want to preserve the split, because you are a different opinion (which is of course fine :)), I would settle on Solution 2, because it makes multi modpack support possible and is essential Solution 3 without removing the split.

Last but not least, if solution 2 is also not possible (could likely be the same reason as for 3, because both solution are so similar) or you decide against it, solution 1 will work for many people as well.

I would love you to get back on my suggestions and opinions, and will answer as soon as possible any questions you may have regarding my explanations or ideas.

Greetings Lucas

Brittank88 commented 1 year ago

personally don't understand where the split came from in the first place, as other mod(pack) tools and launchers don't have this split and limitation

I totally agree - this seems to be a deep design flaw (unless there's a good reason for it - not that I can think of any but maybe implementation detail?) posing severe limitations in some cases.

A very good write-up by the way!

But if it is be possible and the goal of ferium is to get a full fleged cli alternative to other Minecraft launchers this will be sooner or later a must have feature.

I totally agree. The ability to pull down a modpack and then modify it (and then export that as something new, potentially) is present in any other modpack launcher I can think of. For them, it's a lot simpler because things haven't been split in the manner they are in Ferium.

I really love Ferium and want it to succeed, it just seems like the devs shot themselves in the foot with this strange modpack/profile split, but I have an open mind and would love to learn about why exactly that has been done.

theRookieCoder commented 1 year ago

Well to be honest, ferium wasn't really meant to be a modpack 'manager'. The initial goal was to just download a list of mods (which it does a mediocre job at atm). For some reason, modpack support was very widely requested that I just tacked it onto the existing system. So, the current implementation actually downloads and installs modpacks rather than 'managing' anything.

I'm honestly still in a confusion/dilemma about how to implement modpack management, and it doesn't help that I've got basically no time nowadays. I've currently settled on the 'import into a profile' implementation which I've described in this issue, but I'm free to any other suggestions, like @lucaszischka 's (thanks for the suggestions!)

Brittank88 commented 1 year ago

It's funny to me how the GDLauncher rewrite is using Ferium, but in some ways, it seems Ferium itself needs a rewrite given these new conditions!

Not that there's anything wrong with that, but I am a strong believer in doing it the right way the first time around. I can see a lot of complications coming up given this relationship between Ferium and GDLauncher and the expectations that it has regarding features. Instead of using tacked-on features, I feel like it needs to be properly rebuilt ground-up to do what it needs to, but I understand you have little time.

Feels like a conversation to be had with the GDLauncher guys though - the unavoidable truth is that they're planning to use a backend that currently doesn't have the launcher's required features as its main goal/capability.

Please let me know if I got anything wrong - I want to keep an open mind and understand what's going on, because I care about these sorts of projects succeeding!

gorilla-devs / ferium