info.json factorio_version should support more as one version

[Kuxynator]

info.json `factorio_version` should support more as one version.
if a mod handles the differences of Factorio 1.0 and 1.1 in code it should not be necessary to publish 2 different mod versions.

Example: current I have a mod in version 1.2.3 for Factorio 1.0
for Factorio 1.1 I add a condition `if mods["base"]=="1.1.0" ` (or similar) to handle the changes, but add no new features.
to publish the changes I have to increment the version (e.g. to 1.3.0)
so now I have 2 versions to manage: 1.2.3 for 1.0 and 1.3.0 for 1.1
If I add new features I also have to manage 2 separated versions with different version numbers.
so 1.3.0 I can not use (because used for 1.1) I have to use 1.4
for 1.1 I need an extra version, using 1.5
Alternativ I could misuse the major version for Factorio. so 1.4.0 for Factorio 1.0 und 2.4.0 for the next Factorio and so on.
BUT that would only be half the battle I still have to maintain 2 different versions .with only differences in version and factorio_version.

This could be avoided if all supported Factorio versions could be specified.
Example:
`factorio_version = {"1.0", "1.1"}`
So the current mod only needs to be extended for the new Factorio version and new features could be added easily because only one mod version musst be maintained.

[CREE7EN]

hello,

i thought the same. maybe dropping "factorio_version" altogether and using "base" in "dependencies" as a reference instead would be more convenient.

or, using "factorio_version" as the "highest version this mod is supported in" and letting "base" in "dependencies" decide from which versions onwards.

a more "complex" example of how this could be done on the modders' site would be:

Code: Select all

{
  "factorio_version": "1.1",
  "dependencies": [
    "base >= 0.18.0",
    "! base = 1.0.0"
  ]
}

where this mod would support all versions from "0.18" to "1.1", except "1.0" (for whatever reason, in this example).

while the wiki states that:

Mods with the factorio_version "0.18" can also be loaded in 1.0 and the mod portal will return them when queried for factorio_version 1.0 mods.

i find this very unintuitive and confusing, both for players and modders, resulting in the hard-to-navigate mods page front-end we have currently.
harsh words, as it's not that bad, but it could be handled better in my opinion.

i started getting into factorio a week ago or so, and have been looking into modding since the weekend, so this is more of a brainstorming attempt than an actual good idea, most probably.

somewhere in the forums i've already read a similar discussion, but didn't quite agree with the outcome (or, for that matter, what is currently possible with versioning mods).

- cree7en

//e: on second thought, this might boil down to changes in the mods page front-end only, and no actual game changes or special info.json handling in regards to the api or introducing anything new on that end. not sure, though.

[MasterBuilder]

while the wiki states that:

Mods with the factorio_version "0.18" can also be loaded in 1.0 and the mod portal will return them when queried for factorio_version 1.0 mods.

i find this very unintuitive and confusing, both for players and modders, resulting in the hard-to-navigate mods page front-end we have currently.
harsh words, as it's not that bad, but it could be handled better in my opinion.

The mod loading across 0.18 & 1.0 is the only exception to the rule. None of the other versions work that way.
And the only reason this is like this is due to the version bump for the '1.0' release. Basically, 1.0 is equivalent to 0.18 stable. It's just called '1.0' instead because it's the first non-EA/beta version.
There were deliberately no breaking mod changes exactly so things made for 0.18 would work for 1.0. Again, so the full 1.0 release on steam already has the stable mods made for 0.18.

1.1 is back to the normal process where many breaking changes were made to mods & as usual, it does not support mods from previous versions.

[CREE7EN]

The mod loading across 0.18 & 1.0 is the only exception to the rule. None of the other versions work that way.

oh, thanks for the explanation!

but this doesn't mean one can't build one source which should work for multiple versions if exceptions in the code are handled properly, right?

[eradicator]

i thought the same. maybe dropping "factorio_version" altogether and using "base" in "dependencies" as a reference instead would be more convenient.

That is how it worked prior to the introduction of the factorio_version field in... 0.12? So it looks to me like a concious decision to not support that usecase.

[Rseding91]

Sorry, but factorio_version is specifically designed to lock a mod into 1 version of the game. Rather than a load of errors every time we release a new major version it's much cleaner if the players mods are simply disabled until the mod author deems the mod compatible with that new version and the player updates them.

[Kuxynator]

Sorry, but factorio_version is specifically designed to lock a mod into 1 version of the game.

I agree, its more easy to look at only one version, but is used only for a filter. und this filter could be redesigned

Rather than a load of errors every time we release a new major version it's much cleaner

I agree, for MAJOR, but not for minor changes. but it seems the versioning not uses Major.Minor.Patch

if the players mods are simply disabled until the mod author deems the mod compatible with that new version and the player updates them.

This would also be the case if you could simply add the new version to the field after making the mod compatible for the new version
At present the SAME mod hat to published multiple times with only factorio_version different, this is unnecessary.

[Rseding91]

factorio_version only supports major versions. It ignores minor versions and treats them all as the same compatibility wise.