Supporting multiple Factorio (Major) versions

[Squelch]

Hello all,
I'm sure this must have been covered before, but my search foo has failed. With the release of Factorio 0.18, it renders any mods with 0.17 major version incompatible. My little effort was originally created for 0.17.xx series and has been tested on 0.18 and found to be working fine. However, I cannot seem to find a way to make it compatible with both versions, or indeed any prior version. The only method I can see is to release multiple versions of the mod for each major version of the game by editing info.json accordingly. This seems rather cumbersome. Have I missed a trick?

What I've tried:

• "factorio_version": "> 0.17"
• "factorio_version": ">= 0.17"
• No factorio version (defaults to 0.12)

I was rather hoping that the same syntax as that used in the dependencies field so multiple major versions could be used, but alas no.

Any ideas?

[Klonan]

Nope, we definitely want it to be explicit.

[Squelch]

Ok thanks, and understood. I'll stick with 0.17 stable and release a separate copy for 0.18 experimental series.

It's a shame that 0.18 isn't the stable version, it would have seemed more intuitive and made modder's lives a little easier by not having to maintain more than one release when they are still compatible.

[Edit for clarity]

[BlueTemplar]

0.18 will be stable too, eventually. Modders make mods for experimental versions at their own risk.

I had the same issue with 0.16 => 0.17, to the point that I'm still procrastinating on putting my mod(s) on the mod portal, as I wanted to properly support both 0.16 and 0.17 stables.

Ideally, all modders would support all major versions (at least those newer than the mod), though depending on mod complexity, this could be unfeasible.
(EDIT : Also, if they even can do it : if Factorio removes a feature that the mod relies on, like Pickaxes as items or Mining hardness, you're out of luck...)

However, I'm wondering whether the "Deprecation" feature couldn't be used here - mods that have an older major version could still be listed on newer versions, but as "Deprecated" ?

[Squelch]

I've been giving it some thought and experimenting with the versioning. It does seem possible, but isn't immediately clear from any of the guides, that a mod can support multiple major versions at once.

Here are my findings:

• The Mod portal has a version tab to list only those mods compatible with that Factorio version. It will discern between the same mod contents (version number only changed) across Factorio versions.
• The game's mod manager only shows mods for the currently running version. ie 0.18 mods are not shown in a 0.17.79 game and vice versa.

With a bit of planning by the mod maker, different versions of the game can be supported by prudently using their own versioning strategy in parallel with the game. My suggestion would be to number the mod's version appropriate to the game's major version. For example, my little mod was built for 0.17 as 0.1.2 and has no functional incompatibilities 0.18. If I change the supported game version number alone, it will only become visible to 0.18 games and on the 0.18 tab on the portal. However the previous version is still visible as 0.17 specific. I do not intend making any more changes to it in the near future, so I could version the 0.18 payload as 0.2.2 (note the incremented major version) and keep the minor number for any code changes I may have to make. This effectively forks the same base code, differing only by the games major version, but also allows any other functional changes to be kept relevant to that game version. Eg, something changes in 0.18 that diverges from the original code. The two forks could end up something like 0.1.12 for Factorio 0.17 and 0.2.23 for Factorio 0.18.

0.18 will be stable too, eventually. Modders make mods for experimental versions at their own risk.

Undoubtedly, but not anytime soon. I am aware that some players will stick to the stable versions, and others will "live dangerously" on the cutting edge and go Experimental.

I had the same issue with 0.16 => 0.17, to the point that I'm still procrastinating on putting my mod(s) on the mod portal, as I wanted to properly support both 0.16 and 0.17 stables.

Perhaps the above strategy might work for you in this case?

Ideally, all modders would support all major versions (at least those newer than the mod), though depending on mod complexity, this could be unfeasible.
(EDIT : Also, if they even can do it : if Factorio removes a feature that the mod relies on, like Pickaxes as items or Mining hardness, you're out of luck...)

Absolutely, and it is one of the perennial problems seen in mod friendly games. New experimental features will invariably break mods, but modders also like to keep up with and take advantage the latest changes. The poor player can then become quite frustrated with the main Devs or mod creator. They simply just want to play after all.

However, I'm wondering whether the "Deprecation" feature couldn't be used here - mods that have an older major version could still be listed on newer versions, but as "Deprecated" ?

I'm not sure if that's the intention of the deprecation feature, but I follow your logic. I am in hope of deprecating my only mod so far because it has been officially adopted. It should still be visible for older versions of the game for those that wish to stay behind of course.

[Jelmergu]

What usually happens is that modders don't really support a stable release after an (major) experimental has been released. It is to much of an hassle to support two different versions at the same time. Experimental isn't really experimental, more like beta. The experimental versions of Factorio have always been the base for the stable versions, which means that for a modder it is less time consuming to develop only for the experimental version.

That is at least my view and how I work with my mods.

[Squelch]

What usually happens is that modders don't really support a stable release after an (major) experimental has been released. It is to much of an hassle to support two different versions at the same time. Experimental isn't really experimental, more like beta. The experimental versions of Factorio have always been the base for the stable versions, which means that for a modder it is less time consuming to develop only for the experimental version.

That is at least my view and how I work with my mods.

It's all in the name, and it seems fashionable of late to label a game as something like Alpha when in fact it is already quite mature. Experimental, to me, means there might be game breaking changes as development progresses, but as you say, it is essentially beta. I'll make a large assumption that a majority of Factorio players are technically proficient, and can work around most of these problems, but I would not like to assume that that is at the expense of other non technical and new players. Steam offers the stable version by default for example, and not all players are necessarily aware that the "Experimental" options exist in my experience.

I fully agree that maintaining two or more forks at once can be an unwelcome overhead for modders. However, with the right practices applied to whatever versioning tool is used, it is entirely possible with just a little effort. The current modding guides do not seem to cover this aspect, perhaps in the assumption that modders are already familiar with such practices?

I do see that quite a few mods have been updated to 0.18 already, and after running a diff on them, have changed only the supported version number. @ssilk has also posted as script to update the version number only in the 0.18 release thread too. This would not accommodate functional changes between the versions of course, but does seem quite useful nonetheless.

[BlueTemplar]

I had the same issue with 0.16 => 0.17, to the point that I'm still procrastinating on putting my mod(s) on the mod portal, as I wanted to properly support both 0.16 and 0.17 stables.

Perhaps the above strategy might work for you in this case?

Yeah, I've already though of something like this, specifically to use 016.xx.xx, 017.xx.xx, now 018.xx.xx as versions (we can now be certain that there won't be a 0.100 version of Factorio ! )

However, I'm wondering whether the "Deprecation" feature couldn't be used here - mods that have an older major version could still be listed on newer versions, but as "Deprecated" ?

I'm not sure if that's the intention of the deprecation feature, but I follow your logic. I am in hope of deprecating my only mod so far because it has been officially adopted. It should still be visible for older versions of the game for those that wish to stay behind of course.

Mod deprecation
A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc.
[*PIC*]
Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later.

Collaborators
[...]

I just checked, and deprecated mods (like Industrial Revolution) indeed only show only on the website and not in the in-game mod manager...

Also, a somewhat related "issue", is how Wube's matchmaking server (accessible through "Browse public games") only shows the MP games for the major(?) version that you are currently running.

[BlueTemplar]

Alternatively, mods for older versions could still be listed* and downloadable by the game, but marked with an additional tag : "Outdated" ?

*Perhaps in a sub-category for the in-game mod browser.

[BlueTemplar]

Or/Also this :
Set mod version as deprecated (not whole mod), by darkfrei

[Squelch]

Alternatively, mods for older versions could still be listed* and downloadable by the game, but marked with an additional tag : "Outdated" ?

Older versions are still listed in the downloads section of the Mod Portal. The game only fetches Mods marked for the currently running game.

0.17

On the portal and filtered for 0.17, only one copy of my mod shows

0.17-Portal.PNG (105.43 KiB) Viewed 5270 times

Game ModManager sees only 0.1.2 of my mod

0.17-ModManager.PNG (63.4 KiB) Viewed 5270 times

0.18

On the portal and filtered for 0.18, two copies of my mod show Note; one deprecated, so only visible to me, and those that grabbed it whilst it was live.

0.18-Portal.PNG (143.41 KiB) Viewed 5270 times

Game ModManager sees only 0.2.2 of my mod

0.18-ModManager.PNG (58.62 KiB) Viewed 5270 times

*Perhaps in a sub-category for the in-game mod browser.

I'm not sure that's needed to be honest. Outdated mods can still have their factorio version edited for the current version if nothing else has majorly changed in the meantime.

The only problem seems to be how the portal handles the display and download, and this was what initially caught me out. It does filter for 0.18 correctly, and the download link fetches the latest revision (0.2.2 in my case) However, when filtering for 0.17, it initially looks good, but the download link will still fetch the latest revision (0.2.2 for 0.18 in my case). We must first expand the mod's link and use the downloads tab to see the revisions, and then select the correct game version for things to work properly.

Downloads tab

Mod Downloads.PNG (106.58 KiB) Viewed 5270 times

[BlueTemplar]

Ah, yeah, one issue is how that list has a limited length, so for mods with a lot of releases, 0.16 versions have already been "pushed out" of the list !

I'm not sure that's needed to be honest. Outdated mods can still have their factorio version edited for the current version if nothing else has majorly changed in the meantime.

But it is a pretty big problem, since the modder might not be around to even do that little change, the mod licence might be forbidding it for someone else to just do a copy, and most people won't be even aware it exists if it doesn't show up in the in-game mod manager !

This is especially likely a problem with Wube's new plan to release major versions more often (but with smaller changes), at least if I understood it correctly ?

[Squelch]

You make some good points. The mod portal does seem limited, and has a few issues that have already been highlighted. The ingame browser will only show mods marked for the current game version, but there is a hidden setting in config.ini that allows the list to populated with all game versions. Personally, I think that is a little dangerous, but it's there should anyone want to explore.

The only other alternative, is to release individual mod revisions targeted at one specific game version - as I attempted to do with my [Exp] labeled release. That does of course add an overhead to modders, and will inflate the mod portal's storage somewhat.

I fully understand, and support the ideas Wube are exploring re developer resources. Solely bug fixing, or on the other hand, new feature creation can lead to burn out, so by splitting their time and tasks between the two does work well in an Agile environment. That could actually mean more point releases (minor) and smaller feature (major) resulting in shorter release cycles than we've been seeing so far. That could then make the shortcomings in the mod portal even more prescient.

As an aside:
I do have a feeling that the ingame mod browser is still needing some more work, and I personally would like to see the mods per save feature expanded so we can manage mods within the save folder structure via an overlaid or redirected path. I'm currently formulating some ideas to do just that, along with savegame filters and forking, but with the help of an external archiving/versioning tool. Experiments are currently in progress to find what hooks are available to realise such a tool. The ongoing GUI work in 0.18 may render this entirely moot - I hope

[BlueTemplar]

Yea, I thought afterward about the risk that it could potentially pose for mods to auto-update and breaking games - one solution for that would be for mods to not auto-update across major versions, but only update when asked for ?

[Hanse00]

Nope, we definitely want it to be explicit.

I totally understand wanting to be explicit in supported versions, but can we explicitly support multiple?

Eg.

Code: Select all

"factorio_versions": ["0.17", "0.18"]

[Optera]

I'm only developing for experimental, though I do increment major version on each mod when updating so bugfixes for stable won't mess up versions.

Considering the last 3 or 4 major releases always broke mods to a certain degree, I don't see any real benefit supporting 0.16, 0.17 and 0.18 with the same codebase.
However if Wube decides to go rapid release cycle I'd certainly want to support multiple major releases.

[Klonan]

However if Wube decides to go rapid release cycle I'd certainly want to support multiple major releases.

I think at most its going to be 1 major version every 6 months

I have always and only ever updated for latest experimental, and once the new experimental is out I don't even care about old versions of the mod,
In the long run it is a waste of time, as eventually the experimental becomes the stable

[Squelch]

I think at most its going to be 1 major version every 6 months

I have always and only ever updated for latest experimental, and once the new experimental is out I don't even care about old versions of the mod,
In the long run it is a waste of time, as eventually the experimental becomes the stable

That is all well and good for a vanilla game, but it does rather render the point of the stable release moot. Eventually, and 6 months is a long time to wait for a player that has invested hundreds, if not thousands of hours into their current game, only to have to abandon it because a mod is only being built against the stable revision. That is a bit of hyperbole on my part, I'll admit, but it does emphasise the kind of mess we find ourselves in where mods cross the divide in major version support.

What I and @Hanse00 seem to be seeking, and I'll hazard a guess there may be others, is the ability to support multiple major versions where the codebase is common and unchanged. In fact, it would be quite empowering for modders to be able to branch their code path to allow for small functional changes between explicit versions too. It then falls incumbent upon mod makers to test and verify their mod against a cutting edge release, but would also allow players to continue on a less fragile (stable) game revision in the meantime. I don't think that advocating that modders have to support versions as far back as, say, 0.12 is wise, but at least the last stable without needless duplication.

I see that some players are also getting caught out by upgrading, finding things don't work out for them, and then only to lose their BP library for example. I do agree with you that that situation isn't an intended use case, but the encouragement to go experimental through the promotion, and the hassle mod makers have go through to try and support multiple versions, or eventually not bother thereby forcing players to follow, makes that scenario inevitable sadly.

This situation isn't in any way unique to Factorio I might add, but it can be mitigated by enabling modders the ability to support multiple explicit versions with ease.

[Klonan]

What I and @Hanse00 seem to be seeking, and I'll hazard a guess there may be others, is the ability to support multiple major versions where the codebase is common and unchanged.

I don't see the value.

As a modder myself, the versions for the stable release still work, and if people are playing stable, they can play the last version of the mod that I released for the stable update.

For myself, I am updating my mod to experimental, using the new features, fixing bugs I make, improving things,
I do not have any interest in playing in the stable release, I have no interest in backporting things to stable release

[Solinya]

I think a big question is: what does the post-1.0 landscape look like? Will there continue to be major refinements to the game, with potentially game-breaking changes, or are they going to be the more minor sort once official release has passed? If it's the latter, then a multi-version system doesn't make much sense because it's only an issue during pre-release "early access". If it's the former and all mods have to update every 6-12 months, it might be worth considering post-release.

I can understand not wanting to work on it now. Multi-versioning in the current release setup is kinda murky in that not all breaking changes are in the .0 release. I'm pretty sure most of my mods would work fine in .18 as the breaking changes seem focused on areas I don't rely on. But some future enhancement (probably the character GUI) is likely to break something on a .18.x. Just like how my mods worked okay on both .16 stable and .17 experimental until .17.35 introduced the player -> character rename.

So allowing people to prematurely mark both .17 and .18 doesn't necessarily mean the mod will work on the rest of .18. There will likely come a time when an 18.x release makes a mod no longer work with the same code as in .18.0. From the .18.x perspective, the older versions of .18 will be quickly forgotten (relative to the .17 stable), but the mod that works on .17 stable and was marked with .18 compatibility will no longer be actually .18 compatible with the newer stables.