New JVM argument to load mods from other places inside the game directory

[vico93]

Summary

Add a new JVM argument based on Fabric ones to add extra mods

Goals

Basically, add a new JVM argument similar to Fabric's -Dfabric.addMods= that would accept filenames and folders inside the current game directory that would allow modpackers to better organize mods or choose what mods should load per "scenario" (like singleplayer, dedicated server, optional mods, etc).

Non Goals

At first, this shouldn't be viewed as a way to load mods outside the game directory - the concept of profiles/installations (the name depends on the version of the launcher) already exist for that.

Motivation

Lack of viable options to organize multiple subfolders per-profile/installation - only a "global" argument exists but require the user to edit the version JSON file on versions folder on client.

Description

Well, i thought about this idea after trying to return back to 1.12.2 and realize the ways i used to organize the mods of my modpack are really complicated due to limitations on stock Forge back on that version. I use to separate my mods in three different folders inside the game directory:

• the standard mods folder only contain mods that will be loaded in both client/singleplayer and in my dedicated server;
• mods_client contain mods that should be loaded only in singleplayer or client-side: from things like Optifine and similar graphic mods to stuff that i don't want to be activated when playing in my server;
• mods_server contain mods that should be loaded only on a dedicated server, ranging from EasyEula to mods to better manage the server (similar to Spigot plugins in concept, like openinv, fly, etc).

Unfortunately Forge really doesn't add an easy way to quickly specify via JVM arguments to load addditional folders or specific .jar files outside mods (but still within the game directory).

So, i propose the addition of a new JVM argument for loading mods from extra locations inside the game directory. The argument should work in the same way of Fabric's -Dfabric.addMods, that allow the player to specify a list of either subfolders or files, paths relative to the game directory. That would allow mod organization like my use case possible with Cleanroom.

Example on client/singleplayer (on Windows, on Linux for some reason colons should be used instead of semicolons):

-Xmx16G -Dfabric.addMods=mods_client;mods_optional/c2me.jar;mods_optional/chunky.jar;mods_optional/rei.jar;mods_optional/nbtedit.jar;mods_optional/sound-physics-remastered.jar;mods_optional/smoothskies.jar;mods_optional/mica.jar

---

To be very honest there is two arguments (--mods and --modListFile) that in theory would allow loading mods from extra places, but they:

• Aren't supported by the standard "JVM arguments" of the launcher because i think they should be positioned after the rest of the command launcher outputs to start the game, so in client they could be added only editing the <version>.json present in the versions folder, so they are called for any profile/installations that use the same version, this is not good for per-profile/installation organization in my opinion, while -Dfabric.addMods can be used in before the .jar name so it can be added in the standard "JVM arguments" field so they are really work per-profile/installation-only.
• Or use a JSON structure that is very unwelcoming to newbies (the mod list format) or cannot accept subfolders like the Fabric argument does (the --mods only), requiring wildcard contraptions like subfolder/*.* to be able to load multiple mods in a subfolder, while in the Fabric argument one can specify either relative paths to files or subfolders just separated by semicolons (or colons in Linux), far more easier to understand and organize.

Dependencies

No response

References

No response

Guidelines

• I have and will continue to adhere to the guidelines

[kappa-maintainer]

Looks good, maybe we should make this default