Mod Packages

[bobingabout]

Currently, Mods can be added to the game in 2 ways.
1. In a folder with the name "<modname>_<version>" where <modname> is the name specified in info.json, and <version> is the #.#.# formatted version number as defined in info.json
2. In a zip file, that includes the folder specified above, of the exact same name.

What I sugest is that multiple mods are able to exist in a zip file, which can be a way of distributing mod packs to use as is, so that you don't have to extract them first.
The simple way of handling it is that the name of the zip doesn't matter, the game engine just looks inside it at the folders, and assigns a mod to each folder as it would normally.


A "Better" way of handling it, which would require a bit more programming on the Dev's part, is that this zip file is treated as a mad package. it contains all the mod folders that are part of the mod pack AND an info.json file similar to that within each mod. This info.json would then allow you to specify simple information like the modpack's name and version number, that would apear in the game's mod list as a catagory headder, and each of the mods within that pack as listed with an indentation under the pack to show it is part of it. I'm not sure if the game would be able to handle it, but perhaps even the mod's zip files could exist within the zip, rather than just the folders. This would allow you to have a mod pack within a mod pack.

The way the game would handle it on a "Is this mod installed" level, would be to just ignore the mod pack status, and look at the mods within the pack, that way if someone installs the mods indevidually, where someone else installs the pack, if they're all the same version, they should be compatable in multiplayer.

[ssilk]

Hm.
I think the "much better" way to do this is like so: Every mod can define dependecies and can load automatically that dependencies.

So when we have a working mod-db (which might be possible this year), a modpack just needs to be downloaded; let's say it's a big modpack, then it is 2 kilobytes.

Then, when starting the game, it sees there are dependencies and looks into the mod-db. If the mod is found (in the right version) it is also downloaded (and also that dependencies). The indentations in mod-list are a good idea...

No modpacks needed anymore; long lives the modpacks!

[UberWaffe]

I also think that Mod-Pack support is actually required.

The reason for this being that when certain mods are combined they often need to use different config settings in order to work well together.
Those configs might differ from what is used when those same mods are used stand-alone or with other mod combinations.

A similar need arises when scenarios are taken into account. A scenario can call for a very specific set of configs for various mods.

Currently, having only mods (with their config files trapped inside the .zip packages) does not allow for this to be done in an easy manner (i.e. the end-user does not get the typically expected one-click-and-everything-works behavior.)

As such, I would suggest the following be supported:

Mod Configs outside mod packages: Mods should write their config fire into a directory where all currently enable mods config files exist. (I.e. the code should check if the config for the mod already exists, and if not, copies it from the .zip package into this directory.) The configs should be loaded from this directory, not from the zip package.

Mod packs: A modpack should consist only of a list of required mods (which hopefully can be auto-downloaded from the mod manager once that is in place), along with the required version (or minimum version), a config folder (the one mentioned above).
That way, a mod-pack can come with configs for the mods it includes already setup, without having to include the mods themselves.

Scenarios can define required mods or mod-packs: A scenario should be capable of defining what mods and mod-packs are required to run it. There should preferable auto-download similar to how mod-packs themselves auto-download. (Once mod manager is in place.)

The above points do mean that the config files of mods need to give enough access to options / code so that tweaking in the mod itself is not needed.
But in general I feel this approach would make sense, grants ease of use and properly splits the lines of responsibility (or at least where the actual changes should be applied).

[Boogieman14]

Linux package managers (or apt at least, for sure) have a concept called meta-packages. These are packages that don't have any content for themselves, but simply list a number of dependencies. Bob could use this as a one stop shop for all of his mods. Compilation creators could, if they so desire, add one more mod of their own, which has the required lua files to do some pre- or post-loading setting changes to tune the other mods to their wishes.

A separate location for configfiles on the face of it sounds like a bad idea to me, because this would make it very difficult to differentiate between different mod settings for different savegames. Once Factorio gains the ability to selectively load mods depending on savegame settings, I could imagine people having one big collection of mods that only specific mods get loaded from when they load a savegame that needs them (or they explicitly add them to an ongoing game). Mod packs using their own config overruling mod would then also only get loaded for games that were started with them.

Ideally however, I suppose mods would have to take care of saving all kinds of settings in the savegame for themselves, as far as they're relevant to ongoing gameplay. That would probably also make it easier for them to tweak certain settings in new versions without breaking backward compatibility.