Minecraftforge: [1.13.2] Feature Request: --modListFile equivalent

[dscalzi]

I heard on discord that --modListFile has no reimplementation in 1.13 due to the fact that not many people used it. Here I'll present my case for reimplementing it in 1.13.

---

As you may know, this feature allows mods to be stored maven-style and dynamically loaded by listing the corresponding identifiers in a JSON file. That file is then passed to FML via the command line.

A project I work on makes use of this for mod organization and management. Mods are shipped to the user and stored in a maven-style mod repository. Some of these mods are required, and some are optional (meaning they can be toggled on or off). With --modListFile, we are able to store a readily accessible configuration which keeps track of the toggles state of each mod. If a mod is toggled off, it is not included in the built JSON file, and therefore not loaded by forge. This system is efficient and guarantees the enabled state of the mod.

Without this feature, no such guarantees exist. The best that could be done is to drop all of the mods into the default mods directory and perform copious fs operations to verify the state of the mods. We can't simply store a configuration saving the states because we have to ensure that the file is disabled on the disk. With --modListFile, we are controlling what is being passed to FML.

In addition, everything is easier organized with --modListFile. All shipped mods are stored inside of the maven-style repository and dynamically loaded. This allows users to add supplemental mods to the default directory without complicating anything. Integrity validations are also simplified with the maven structure.

Liteloader supports an identical system which we use alongside FML's.

---

I know it may seem like this feature would only be beneficial to a few (or even just one) people, however the project I mentioned has a significant user base, all of which would be affected by the changes. Several other people/organizations have forked and are now using the same code base, and would be affected as well.

---

The system would not need to be identical, but the same functionality is requested. I know you guys are busy with more essential aspects of forge for 1.13, so I am open to working on a PR if you're open to accepting it. My knowledge of the new mod loading system is a bit limited, any pointers on where to ideally implement this would be appreciated.

Thanks for your time.

[io-craft]

This is true across a wide variety of openly available launchers, web, and other software for MC. Not implementing this feature would adversely effect a TON of users, developers and projects.

[JoJoDeveloping]

Just saying that --mods and --mavenRoots are a thing on 1.13 and used by the MavenDirectoryLocator.
Though however it might be a bit tedious / horrendously unpractical to add all mods as cmdline options.
Also, if you want to PR this I guess writing your own ModLocator (like the MavenDirLocator mentioned above; see all of it here) would be the way to go but better ask cpw first.

[dscalzi]

I'll take a look at that feature and see if it would be a suitable replacement. Thanks for the info!

[dscalzi]

Ok, the arguments provide the same functionality as --modListFile did. Just a note for anyone coming here in the future, the actual arguments you pass are as follows:

• --fml.mavenRoots <comma separated list>
  
  
  
  • The list of paths are resolved relative to the game directory.
  
  
  • GAMEDIR: AppData/Roaming/.minecraft
  
  
  • arg: --fml.mavenRoots ../modrepo
  
  
  • Resolved: AppData/Roaming/modrepo
  
  
• --fml.mods <comma separated list>
  
  
  
  • Argument takes a list of maven identifiers which are resolved relative to the specified maven roots.
  
  

Going to close this issue. Desired functionality is already included, and works with less overhead (no need to write to a json file, etc).

Thanks for the info @JoJoDeveloping 🎉

[vico93]

A way to just specify a folder to load mods (or a list of jar files) would be good for tech-savy modpackers.