Factorio Forums

Hi,

I have a suggestion: It would be pretty cool if there is a possibility to start Factorio with a specific mod-list json file. It could work like that (Batch example):
The path must be the path to a json file like the basic mod-list.json, where you can enable and disable certain mods.
If no --mod-list is give, the basic mods/mod-list.json file will be loaded.

With this feature you can make several links to Factorio.exe, each loads a specific modpack.

Wouldn't it be much better to have commands, that turn mods on/off?

ssilk wrote:Wouldn't it be much better to have commands, that turn mods on/off?

For this method I see no advantage...what if you have multiple Modpacks (like one for multiplayer, and another for singleplayer)?

Your idea:
- select a mod-list and start a game

My idea:
- start a game and select (copy/paste) a script to run and change the mod-list.

I see there a technical advantage: My Idea can change the mod-list during the game.

Also, the idea with the mod-list is not thought to the end: What happens, if you don't choose a list? With a new game-creation or game-load the former list will be running. Which is not what you want then.

What you need for that case is also, that you can store the resulting list inside of the game-save and that the game will not change that without any action from a player. In that case it is very similar to your idea.

ssilk wrote:My idea:
- start a game and select (copy/paste) a script to run and change the mod-list.

Oh, I thought you spoke about a start parameter...But changing mods ingame (by enabling/disabling or continuing a savegame) is definitely the best way.

Also, the idea with the mod-list is not thought to the end: What happens, if you don't choose a list? With a new game-creation or game-load the former list will be running. Which is not what you want then.
What you need for that case is also, that you can store the resulting list inside of the game-save and that the game will not change that without any action from a player. In that case it is very similar to your idea.

If no mod-list is choosen, the basic mods/mod-list.json will be loaded.
My suggestion was only about starting Factorio without edit the mod-list.json (or start Factorio, enable/disable mods and restart again) if you want to play a specific modpack. The rest (if you want to play another modpack you have to restart Factorio or if you play a savegame with different mods) would be the same as now.

Bumping this thread as I had the same realization recently; avoiding a duplicate post.

tl;dr: Add --mod-list command line parameter to use a different .json file than the default mod-list.json!
Edit: And a --mod-settings parameter too...whoops!
This would simplify using the same mod-directory for different modpacks with overlapping mods, updating once rather than duplicating update checks and downloads whenever someone switches to a different set of mods, while saving both space and complexity. Avoiding the need to load to the main menu with one modpack before syncing to the other one.

The current command line parameter option (using --mod-directory) results in massive duplication of mod folders, update processes, etc. unless symbolic links are used, or an external script/tool adjusting mod-list.json itself.

As a final note/PSA for those on Steam trying to launch bin->x64->factorio.exe directly with custom console parameters and getting this message:
"Allow game launch? Factorio is attempting to launch with the optional parameters shown below.
If you did not request this launch or do not understand these options, select Cancel." You can bypass it with

Got pointed to this thread by way of the Factorio Discord when I had (and implemented) an almost identical idea for an alternate way to handle multiple mods. So +1 to this from me.

The proposed alternate mod-list.json and mod-settings.dat would fulfill a currently blank spot in between using the in-game sync mods function, bundling them up in modpacks, and using the command line parameter to specify a different path.

The currently available --modpath is great for ensuring that there is compatibility between one or more mods and the base game, or with other mods.
However, from what I can see, more often than not --modpath is instead used in a similar fashion to several modpacks: To simply bundle up a certain configuration of mods together, and minimize the time spent switching between these configurations. The reason most people use --modpath over a modpack or the readily-available sync mods with save function is that --modpath eliminates one entire round of booting up the game, saving additional time.

The --modpath solution, however, can very easily lead to bloat and clutter if the same mods are used many times over. Chances are high that any of the most downloaded and popular mods would be culprits for this, along with Quality-of-Life mods in general. There are even mods which have secondary mods to ensure compatibility between them and a third mod! And whenever a new version of a mod (or mods) that falls into this category is released, updating them can easily become a chore as one has to either repeatedly download the new version, or manually copy the updated version between each different alternate modpath.

While mods are generally small and many computers today have plenty of available storage, this remains an inefficient use of both system resources and time. Most of the time, the latest version of a mod or mods is all that is desired and compatibility is not an issue.

Which leads to the proposed solution of an alternate mod-list and mod-settings:
These two files determine what mods are enabled and what settings are used for said mods. For the average use-case, simply changing these two files is the only necessary step. I was actually pointed to the thread when I posted my script https://github.com/Ocean-Phantom/Factor ... n-Switcher as an automated way to do exactly that. All it does is make a copy of these two files, store them in a reasonably unique path based on date and time, and overwrite these same files in the default folder with the relevant copy when desired (It does falls one step short and doesn't actually launch the game when it's done. )

Both mod-list and mod-settings combined would take up far less space than many mods (especially those that add new sprites to the game), and simplify the update process as the mods are naturally synced.

In summary: Simply switching the list active mods and the relevant settings is far more efficient for the use case of switching mods without having to first launch the game. --modpath is far better suited to cases where compatibility is a potential issue, making it something of an edge-case that is being used unnecessarily as a solution to a general case.

As a possible work around on this until such an idea is implemented, or in case this never is, you should be able to use a batch file to actually swap the mod-list.json and mod-settings.dat files. This, of course, would not allow for a "default" mod list and settings that you revert to automatically, but otherwise it is the same functionality.