Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Per-profile mod directories #169

Closed
Boobies opened this issue Nov 5, 2019 · 16 comments
Closed

Feature request: Per-profile mod directories #169

Boobies opened this issue Nov 5, 2019 · 16 comments

Comments

@Boobies
Copy link

Boobies commented Nov 5, 2019

It would be particularly useful to people using several modded versions of the game for the Fabric loader to automatically pick the correct directory so we don't have to manually swap the mods around whenever we are about to launch the game. For instance, I often use the latest release as well as the latest snapshot and have to manually run a script I've prepared to do it for me.

@sfPlayer1
Copy link
Contributor

The usual way to do this is by configuring multiple profiles in the launcher, each with its own game directory and version.

@Boobies
Copy link
Author

Boobies commented Nov 5, 2019

That works but seems wasteful. If I want multiple profiles for the same game version (e.g., because of incompatible mods), I need to install multiple copies of the same game version. The launcher already has a directory for the installed versions of the game.

@sfPlayer1
Copy link
Contributor

It only duplicates the user data - mods, configs, world saves etc. - not the "version" in launcher terms including MC, fabric-loader, vanilla assets etc.

@Boobies
Copy link
Author

Boobies commented Nov 5, 2019

"Only" is relative since the world saves by far take the most amount of space; several gigs is not at all uncommon.

@sfPlayer1
Copy link
Contributor

sfPlayer1 commented Nov 5, 2019

But then those are not backwards compatible with older MC versions, the same applies to most mods and parts of the configs.

@Boobies
Copy link
Author

Boobies commented Nov 5, 2019

Well that shouldn't matter. The same argument applies to Minecraft in general. If I decide to upgrade a world to a new version, it won't be backwards compatible. Yet, I have the option of doing so or not without copies (unless I ask MC to make me a backup). The argument does not apply to using the same version with different (incompatible) sets of mods.

@liach liach added the question label Nov 5, 2019
@liach
Copy link
Contributor

liach commented Nov 5, 2019

That is the fault of your launcher for copying unnecessary version data. You can just have two folders for your two launch configurations with the same loader+minecraft version combination and different content in the mods directory.

@Boobies
Copy link
Author

Boobies commented Nov 5, 2019

I thought we are talking about the official MC launcher and I was going by the above answer which said that I'd need that data copied over. I am not currently at home so I cannot see my options. If there is a way to have different configuration folders but keep versions, saves, etc. in a single place, we can close this ticket.

@sfPlayer1
Copy link
Contributor

What I am trying to say is that the user-side benefit for this is quite small/niche.

You'd still need multiple profiles in the launcher, have each profile set some system property like -Dfabric.modsDir=<some path> in the JVM args field without a nice gui element and then still run into problems with other folders containing potentially incompatible contents.

Alternatives on your side may include symlinking the folders you want duplicated across the game directories.

Liach's suggestion only covers the non-user-data as mentioned in my above reply.

Overall I'm not sure - it is fairly easy to add, but poorly accessible and unlikely to be used widely.

@Boobies
Copy link
Author

Boobies commented Nov 5, 2019

I was thinking of having the Fabric installer set up the profiles properly and then letting the user take care of any edits later on.

@liach
Copy link
Contributor

liach commented Nov 5, 2019

Eh, if this really becomes a feature, I only see it introducing more trouble than convenience. Even in vanilla, e.g. if you share a same game directory for a Minecraft 1.12 and a Minecraft 1.8 instance, incompatibility across game options (auto jump) arises; when you set to disable auto jump in 1.12 but happened to launch 1.8 once, the autojump setting is removed and when you open 1.12 again, autojump is back enabled (or reset to default)

Given even vanilla doesn't support multiple different game instances sharing a same directory, I'd argue against your proposal.

@liach
Copy link
Contributor

liach commented Nov 5, 2019

And how about configs? If you want to have 2 sets of different config but want to share everything else (mods, maps, options, etc), should you ask fabric loader for this support? I disagree. And if we replace configs with mods, I don't think it is fabric loader's obligation either. It should, in my opinion, be an option in a minecraft launcher.

@liach
Copy link
Contributor

liach commented May 23, 2020

Vanilla launcher allows you to configure custom game directories. Just put a set of mod into a custom game directory for your purpose.

@liach liach closed this as completed May 23, 2020
@Artoria2e5
Copy link

Artoria2e5 commented Jun 11, 2020

Wrote a shell script for (eh) the copying and symlinking stuff. Just note that symlinks are far from universal; you need to be admin on Windows to have them. (Dumb I know.)

https://gist.github.com/Artoria2e5/d398dcbbde037ea115566855860e053a

@Hollikill
Copy link

Hollikill commented May 23, 2022

Not sure if anyone is even checking this anymore, but I wrote a program that manages profiles quite nicely. You can find it at my website, accessible at this link:

https://hollikill.net/html/SFP.html

@sfPlayer1
Copy link
Contributor

https://minecrafthopper.net/help/guides/changing-game-directory/ shows the vanilla launcher way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants