Modpacks with specific mod versions

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

Post Reply
User avatar
jodokus31
Smart Inserter
Smart Inserter
Posts: 1227
Joined: Sun Feb 26, 2017 4:13 pm
Contact:

Modpacks with specific mod versions

Post by jodokus31 »

TL;DR
Modpacks are able to define the version of the containing mods.
With this info, you can resync your active mods to the specified mod versions
This suggestion is a follow-up of viewtopic.php?f=66&t=53696
and was sketched briefly here: viewtopic.php?p=529460#p529460
What ?
Introducing infos:
Modpacks are mods, which have dependencies to the containing mods. With the help of those modpack mods, you are able to install the containing mods by just installing the modpack mod and the dependencies are installed automatically.
There is also a mod category for them: https://mods.factorio.com/tag/mod-packs?version=1.1

The suggestion consists of 2 solution approaches:

1.
You already can specify the fixed version of any containing mod in info.json via the usual mod dependency mechanism (https://wiki.factorio.com/Tutorial:Mod_ ... pendencies). f.e.:

Code: Select all

ScienceCostTweakerM = 1.1.1
If you install the modpack mod, the specific version of the dependency mod should get installed instead of the newest version.

If you have a newer version of the mods installed, you should also have the ability to revert the modpack to the original mod versions. F.e. via an additional button in Mods -> Manage screen for the modpack mod.

Note: the Modpack mod is red in this case, because the dependencies are not correct, because the fixed dependency is not fulfilled. However, the modpack mod does not need to be correct, because the containing mods work for themselves. Not sure, if something would have to be done here.

2.
If you have a savefile, you are already able to sync to the mod selection of the savefile. So the savefile can act as modpack, but it always installs the newest version or keeps the currently installed version, no matter if the version in the savefile is different.
Here, you should alternatively be able to resync all (or some) mods to the original versions of the savefile. This should not replace the current functionality, because you sometimes want the latest version and not the original version.

Additionally, as ssilk proposed, you could consider npm standards for “backward compatible bug fixes”, which can be installed safely instead of the original mod version. This would imply, that all mods had to follow those principle, which seems a bit unrealistic, but that could be established.
Why ?
If you have a big modpack with dozens or hundeds of mods, its very hard to distribute a working compilation. Often some mod changes, do some experimental changes or introduce a new bug and then the modpack is broken, if you install the latest versions.
Seablock is a very popular example and the old big seablock forum thread viewtopic.php?f=190&t=43759 was full of problems, because people installed the pack with not matching versions of the mods.

Currently its easier to provide a big zip file of mods as modpack

It would be easier, if you could define all or some versions of the containing mods of a modpack and be able to revert the mods to its original versions.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12244
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Modpacks with specific mod versions

Post by ssilk »

Nice. Very good.

Sorry, I could have saying this earlier, but I thought pointing to the right direction should be enough.
From https://semver.org/
In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.
:)


What this suggestion currently describes is only the very, very top of the iceberg. Because it cannot solve all conflicts. And it leaves some open questions (what if it doesn’t run, who will give the players support?). But I won’t address them all. But especially for modpacks such conflicts are foreseeable.

So first some showing some theoretical background. Sorry, I will come to my point later.

I already mentioned conflicts. If a mod is installed in a specific version, but another mod wants to have it in another version, then we have a conflict.

npm solves this conflict by installing both versions, because JavaScript is able to load libraries in different versions without such a conflict. In Factorio this is not possible. LUA itself could also run different libs, as JavaScript, but a mod can exists only once. There are several reasons why that makes sense.

So we can say: in the situation of a conflict we need human interaction. Which is ugly, because it leaves the problem to the player. Which can decide wrong. Even when he decides right, he just cannot really know, if the conflicting mods can really resolved in the way he does. So what we can say is: it’s better to not let the player decide what’s the right version. It’s much better to give that decision to the modder or in this case the mod-packer.


npm has also a second mechanism, that explains, under which circumstances a version can be automatically changed/updated, when there is a newer version available. This solves the conflict.

As consequence for Factorio we need to have a process, where it is decided what version will be installed. And it either ends in a
- conflict (for example when mod A has dependency to mod B v1.0.1 and mod C has dependency to mod b v1.0.0), which cannot be solved automatically. This needs human interaction to solve. This is what is more or less what’s described in this suggestion.
- Or (much better) it can be solved. For example mod A wants to have version “~1.0.1” and the “~” tells Factorio, that the everything equal or above 1.0.1 is ok. 1.0.999 is ok, but 1.1.1 is not. So if mod B has also such a range of versions, Factorio can use the latest version without conflicts.

There are lots of documentation about this version ranges. It’s explained a bit in that already linked document https://docs.npmjs.com/about-semantic-versioning -> “ Using semantic versioning to specify update types your package can accept”. What I also found is this: https://www.geeksforgeeks.org/introduct ... ersioning/

But there are surely much more, like the semver calculator.


So, what I would add to this suggestion is the introduction of semver into Factorio, because I think that could prevent version conflicts here in over 90% of all cases.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
jodokus31
Smart Inserter
Smart Inserter
Posts: 1227
Joined: Sun Feb 26, 2017 4:13 pm
Contact:

Re: Modpacks with specific mod versions

Post by jodokus31 »

ssilk wrote:
Fri Jan 01, 2021 11:28 am
What this suggestion currently describes is only the very, very top of the iceberg. Because it cannot solve all conflicts.
Yes, I know. It's not a complete approach for solving the "dependency hell".
But, it rather tries to solve the use-case, where the "modpacker" exactly knows, which versions of the mods work together without problem.
If a user updates mods to newer versions, it should be possible and it also may work. But its not guaranteed to work any more from the modpacker's POV. If something is clashing, you should have the ability to rollback to the released mod versions of the mod pack.
I don't consider the case, where the modpacker packs mods, which are not compatible, because that's just a bug in the modpack.

Also, the modpack may not necessarily be a mod itself and the proposed mechanism should not necessarily be working for all other non-modpack mods.
ssilk wrote:
Fri Jan 01, 2021 11:28 am
So, what I would add to this suggestion is the introduction of semver into Factorio, because I think that could prevent version conflicts here in over 90% of all cases.
I mean, it sounds interesting and is a more sustainable solution, but it also sounds like very much effort.

User avatar
KiwiHawk
Long Handed Inserter
Long Handed Inserter
Posts: 76
Joined: Thu Jul 05, 2018 9:48 am
Contact:

Re: Modpacks with specific mod versions

Post by KiwiHawk »

I'm the current dev for Sea Block. Yes, something like this would be super helpful! It feels a bit broken that the easiest way of distributing the mod pack is a downloading a .zip from a third party site.

One way around the dependency hell issue would be to treat mod packs differently from other mods:
  • Only allow one mod pack to be enabled at a time
  • Install each mod pack and it's dependencies to a separate subfolder in the regular mods folder
  • Mod versions specified by the pack should be automatically synced
  • Any other non specified mod can just update to the latest version, just like what happens now

User avatar
KiwiHawk
Long Handed Inserter
Long Handed Inserter
Posts: 76
Joined: Thu Jul 05, 2018 9:48 am
Contact:

Re: Modpacks with specific mod versions

Post by KiwiHawk »

Optional dependencies in a mod pack should also be handled differently. Ideally players should be able to enable the whole pack in one click. But for experienced players, if they wanted to swap out FNEI for Recipe Book (for example) then they should able to - while still be using the Sea Block mod pack.

Post Reply

Return to “Ideas and Suggestions”