Factorio Forums

The new "factorio_version" metadata for mods presents an annoying problem. I have a mod that worked fine in 0.12, works fine in 0.13, and will almost certainly work fine in 0.14. The only change I had to make when 0.13 came out was to add the factorio_version to the info.json. I am not looking forward to having to modify that line when 0.14 comes out, and 0.15, and 1.0, and 1.1...

I'd love to see some fix to this situation for mods that Just Work in a newer version, otherwise it's going to be an ongoing headache for mod developers.

I think the game needs to allow "outdated mods" (with an older version tag) to be loaded.

In World of Warcraft (a game which is EXTREMELY addon dependent) there is a version tag as well, but you can force the game to load "outdated addons" with a simple checkbox; for the exact reason that you can load addons that are only out of date because their version tag has not been updated yet.

Something like this would work for Factorio as well.

I though a while about it: This would work, but it is surely not the right way.

The right way (in my opinion of course ) would be, that for that cases everybody can upload a patch. Cause that would be the right signal "Yes, this works really with this version, the author of the patch guarantees that".

Such kind of possibility would be much, much more worth, than everybody trying it out with a stupid button. That is also in the sense of a community.

And for mods, which don't allow patches (cause of licenses) we can take this as fact: Either the mod author is just stupid, then I would not take care about such a mod, or the mod author wants eventually earn money/kudos with it. Why not? But in that case he would be also quite stupid not to take care on his mod, when a new version comes out.

While most useful mods (even ones which have been abandoned by the original author) will eventually get updated, not having a "try to load outdated mods" button seems like an incredibly annoying restriction -- at least while the new version is still "experimental". Doubly so when the mod portal and built-in manager are still having issues.

TheSkiGeek wrote:While most useful mods (even ones which have been abandoned by the original author) will eventually get updated, not having a "try to load outdated mods" button seems like an incredibly annoying restriction -- at least while the new version is still "experimental". Doubly so when the mod portal and built-in manager are still having issues.

It's incredibly annoying, but I don't see the point of making the developers do extra work for authors who clearly no longer care about updating their mod or disallowing anybody else to update their mod because of licensing/ego stupidity.

Well, I don't see a point in making modders perform extra work as well.
I really fail to see what good has been brought by this new tag.
The template description of the mod used to have the field 'tested with', which pretty much indicated that the mod might not pass through the compatibility break. And quite a few mods were happily being used up to a major version change.

Let's see that problem from a logic side: Either there is a version information and it is used or not.

- If it is used, then it needs to be strict: Either it matches, or not.
- If it it not used, there is no need for it and modders can write in it, what they want. Or don't write anything.

Simple logic facts.

No when we add a button like above suggested, then you switch technically between the two states: Use it, or don't use it.

Now again simple logic: Once you switch it to "not use", you cannot return. It's a one-way. You installed this old must-have-mod, that has just the wrong version information in it. Now you need to press this button. And then you cannot switch it back.

Ot think to multiplayer: For me it is not a solution, that I'm forced to press a button "Don't look at the version of installed mods", when I join another game. That is just stupid.

And now I know the Factorio development more or less well and I think I can say, that the devs will never choose one-way solutions, or solutions that force other players to do nasty thing. Just because they don't want to spent time for support. It's more useful to spent time in programming than support!

So I would say (with experience): This suggestion will never be implemented like so.

...

So what can be done?
For now I don't see it as real problem. Unpack zip, change info.json. Fixed. O.K., For multiplayer it is more difficult, but still solveable.

And for the future? Let's see, how other do this RIGHT. For example Apples app-store: The provide for each app a licence-key that tells the OS: Yes, this runs with version X.Y. And if a new version comes, the they just add a new key.

Well, I can think to some time, where the mod-portal also enable modders to earn money for their mods. But not now. Now this is much simpler: A script that changes the info.json to the newest version. Such simple!
So this work can be don by the mod-portal: If enough people say (or play) with this mod it could trigger this kind of "conversion".

Many other (similar) solutions are thinkable. But what I just want to say is: Don't built in buttons and stuff to bring mods to run, even if nobody really looked at it. Either the mod runs as provided or not. And if not, someone still can fix it, but not by pressing some buttons in the game.

ssilk wrote:Let's see that problem from a logic side: Either there is a version information and it is used or not.

- If it is used, then it needs to be strict: Either it matches, or not.
- If it it not used, there is no need for it and modders can write in it, what they want. Or don't write anything.

Version information does not have to be treated stricly. It can be treated as a suggestion or advisory.

After all, you can always override it by simply changing the version number in the manifest of the mod.

So it's not as black and white as you make it sound. It's not unreasonable to allow the player to override the version information and then take the risk of breaking things.

As I've mentioned above, WoW does have tens of thousands of addons and a huge addon infrastructure, and it's working fine even though it allows players to ignore the version tag.

ssilk wrote:Now again simple logic: Once you switch it to "not use", you cannot return. It's a one-way.

You've lost me here.

>For now I don't see it as real problem. Unpack zip, change info.json. Fixed.

This is a bit much for less technical users. All that's being asked for is a less annoying way to do this (or, rather, to not do the version check in the first place). Many moddable games have this feature, it is not some crazy thing that's never been done before.

>And for the future? Let's see, how other do this RIGHT. For example Apples app-store: The provide for each app a licence-key that tells the OS: Yes, this runs with version X.Y. And if a new version comes, the they just add a new key.

iOS apps aren't blocked from working with new versions of the OS unless they interface with some API that actually changed.

In my opinion it should be, first of all, down to the author of the mod to decide which versions it's compatible with (and it should always be easy to override for the player just in case the modder forgot to update or was slow to update after a new release).

If you require a certain version of Factorio then you can already declare this dependency by requiring this version of the "base" mod.

Furthermore, if a new version of Fatorio breaks your mod, then you can declare this as well (it will then require an earlier "base" mod).

The assumption should always be that upgrades to Factorio are downward compatible and won't break your mod. This might usually not be the case with major updates (like from 0.12 to 0.13), but those cases can be covered with a dependency declaration as well.

My guess is that that the current way of declaring a "factorio_version" is a slightly heavyhanded approach to get this information for the mod portal; but it does not seem to be necessary at all from a technical point of view.

TheSkiGeek wrote:>For now I don't see it as real problem. Unpack zip, change info.json. Fixed.

This is a bit much for less technical users.

Less technical users will force-load all their outdated mods, be greeted with errors from mods that do require changes to get running and they are back to square one with broken mods and no clue how to fix it.

In other words, the "solution" won't work for the people you think need it the most.

hoho wrote:

TheSkiGeek wrote:>For now I don't see it as real problem. Unpack zip, change info.json. Fixed.

This is a bit much for less technical users.

Less technical users will force-load all their outdated mods, be greeted with errors from mods that do require changes to get running and they are back to square one with broken mods and no clue how to fix it.

In other words, the "solution" won't work for the people you think need it the most.

It will if they disable the mods that have problems. Lots of people use little utility mods like autofill or long reach that are extremely unlikely to break even on major version changes. I think that people who are using mods would know not to expect things like Bob's Mods to work between major versions without some fixes by the mod's owner.

Right now people are posting "help, how can I get <insert utility mod here> to work?" and being told to manually edit the files in the mod just to satisfy the version check. Having a checkbox for that in the mod manager would be far more convenient. World of Warcraft does literally exactly this and it's extremely useful when modding API changes happen, and people don't seem confused by it.

siggboy wrote:Version information does not have to be treated stricly. It can be treated as a suggestion or advisory.

I thought a while above this. You're right.

Cause it's the same, as the age-check on you-porn. (Ok, I really don't know, if it is still such stupid )
What I mean is: There is technically no difference between:
[ ] Yes, I'm over 18
and
[ ] Yes, this works with version X.Y

After all, you can always override it by simply changing the version number in the manifest of the mod.

Exactly. You can lie. Nobody will check, if you lie.

As I've mentioned above, WoW does have tens of thousands of addons and a huge addon infrastructure, and it's working fine even though it allows players to ignore the version tag.

What would make sense would be a switch per mod, that can be turned on for that single mod.

And that is not the point, that it works. It will also work for Factorio, I'm sure. But it doesn't matter how many famous games do it like so.

ssilk wrote:And that is not the point, that it works. It will also work for Factorio, I'm sure. But it doesn't matter how many famous games do it like so.

I think it does matter how "famous games" do it and how well it works there. There's nothing wrong to look at big names and copy ideas that are working.

World of Warcraft is the POSTER CHILD of moddability. Everybody who makes a moddable game should look at WoW for inspiration (there's even a book called "Learning LUA with World of Warcraft Addons").

It's crazy good what people have created for WoW over the many years the game exists now. WoW without addons is like a smart phone without any apps. You can use it but it simply is not the same thing. Even the high-end content (raid encounters) are designed with the assumption that the guild uses addons.

One of the great things in WoW is that the base game uses the same API that the addons use. So you can replace the UI completely without problems and without creating weird effects (it basically works by hiding the default UI elements and replacing them with your own, but still using the normal game events). This means the community creates the UI for the game, the base UI has not even been touched in many years, and nobody bothers because all the power gamers use their own custom UI anyway. You can even build your own UI IN THE GAME, interactively. Just imagine Factorio would allow that.

You cannot compare WoW with Factorio. WoW is a stable game and it will not change the API. But Factorio is still ALPHA and it has changed the API several times in the last year.

You can see that in the mods section: There are still many, many 0.11 mods, that works with 0.13. But most of then don't work!

That is a mess!

And that is also something I've learned from the last years API changing: That it would be counter-productive to have such a switch, that generally enables it, cause (just look at the comments in the 0.11-mods) the users don't understand, what's going on. And it is a dead end, cause once activated you cannot reverse that decision (or only by not longer using such mods).

As suggested I could live with a switch, that turns that check off per mod. That would be useful, cause that would enable players to post lists of mods, that works/not work and others can just import that lists.

But to open it generally will by guarantee make more problems as it solves in the state as Factorio currently is.

The game is in development for 4 years. This is longer than the life cycle of most games. Even the mentioned WoW is barely older than 10 years, and that's an absolute veteran and nobody would have expected it to be still around.

By all means, Factorio is NOT a new game. You could even say it's an old game, after 4 years.

I know that the devs keep saying "we're still in alpha, anything is possible", but 4 years is a long time to get some stability for your API. "Alpha" is just a label that you can give to anything if you like it (the devs like it because it gives them the freedom to justify any breaking change).

The reality is different, though: when you have a lot of users (players and mod authors), you simply cannot break everything all the time, because that is pissing off your community, and then you will lose players and fewer mods will be created (causing you to lose even more players, because the mods are the cornerstone of the game for anybody but the casuals who leave after 1 playthrough).

So, yeah, the API needs stability, and incompatibilities needs to be introduced slowly (by marking stuff that is going away "deprecated", and give modders time to migrate away from these functions).

There are lots of software engineering practices that deal with these kinds of problems; they only need to be applied.

Being lazy about this and then saying "yeah, sorry, we're still in alpha", does not help anybody.

What is the problem after all?

You [in the sense of all] can write factorio_version = "0.13" in every info.json also if it don't work,
It's like 'load it anyway' only without an easy button.

What i like is, that it has no consequences on 0.12 mods if this tag exists because it is ignored.
So your mods will be als downward compatible.

It's also like a quality control of the mod author, that he/she has spend a minimum of time to look for 0.13 compatibility.

I guess it's to much ado about nothing.

My 2 cents.

siggboy wrote:By all means, Factorio is NOT a new game. You could even say it's an old game, after 4 years.

I said it is alpha. Not old. Quite big difference.
Which means: Things can and will change if the devs find it useful; proven by the past.

This is in contrast to WoW, which is stable. If there is not a really, really good reason, things won't ever change, you have brought all the good arguments.

Because ALPHA is not STABLE, both cannot be compared. It is that simple: ALPHA means, everything can change with each version. STABLE means, nothing will change, if not really, really needed.

So, logical conclusion, the assumption, that WoW can be compared with Factorio in this detail is wrong because WoW is STABLE and Factorio is ALPHA.

The reality is different, though: when you have a lot of users (players and mod authors), you simply cannot break everything all the time, because that is pissing off your community, and then you will lose players and fewer mods will be created (causing you to lose even more players, because the mods are the cornerstone of the game for anybody but the casuals who leave after 1 playthrough).

This is right for stable games. It's wrong for unstable, which Factorio still is.

Not taking care of this fact is just a stupid mistake.

ssilk wrote:

siggboy wrote:By all means, Factorio is NOT a new game. You could even say it's an old game, after 4 years.

I said it is alpha. Not old. Quite big difference.
Which means: Things can and will change if the devs find it useful; proven by the past.

Yes, but that has nothing to do with the software being alpha or not.

"Alpha" is just a word invented by software people to denote software that is not feature complete, and every tech team treats the label a bit differently -- but it does not mean "unstable", at least not in the general case.

Factorio is not unstable software. It's, in fact, very stable (I didn't have a single crash in 0.12, in the many hours that I've played with that version). The big changes happen between major releases (like the one we've just received with 0.13), but the community is not prepared for it because a lot of it has been held back and is now dumped on us.

Now, don't get me wrong, I love the changes, change is great -- but if you have a lot of modders relying on your API it's maybe better to prepare them for some of the changes, for example by making parts of the API deprecated before actually removing or changing them.

This is in contrast to WoW, which is stable. If there is not a really, really good reason, things won't ever change, you have brought all the good argu[ments.

WoW gets a new expansion every year, and this breaks addons -- a lot of them. So it's not that different from Factorio right now. WoW is only reasonably stable during an expansion life cycle, and even then sometimes addons break due to changes. Which is precisely the reason why you have version checking in WoW, too, and need to override it if you want to load "outdated" addons. The version checking (in WoW) is in place to protect noobs from broken addons after a version transition. If the addon author needs to update the version tag (even if there's no other change), then that means they have looked at their addon and checked it still works -- presumably.

The version check should still be able to be overridden, but we are in agreement about that, so no need to beat a dead horse.

Because ALPHA is not STABLE, both cannot be compared. It is that simple: ALPHA means, everything can change with each version. STABLE means, nothing will change, if not really, really needed.

That entirely depends on your definition of "Alpha", which is not a definition that is set in stone and that every tech team on the planet uses in exactly the same fashion.

The reality is different, though: when you have a lot of users (players and mod authors), you simply cannot break everything all the time, because that is pissing off your community, and then you will lose players and fewer mods will be created (causing you to lose even more players, because the mods are the cornerstone of the game for anybody but the casuals who leave after 1 playthrough).

This is right for stable games. It's wrong for unstable, which Factorio still is.

Does it matter? If you piss off 1000 players, then that's a fact. The players don't care what you label your software, they still pissed off by their favourite game breaking.

Also, let me point out that the devs very much try (and succeed) in keeping the game stable between major releases, which is why not much broke at all during the part of the 0.12 cycle that I've seen. Breakage is occuring right now because 0.13 is still "experimental" (<- now THAT'S a useful and pretty explicit label for software).

So my final remark on this: Factorio is a changing game, like many other games (all the MOBAs, for example). I don't really care if you want to call it Alpha or Shmalpha. However, if a release is tagged "experimental", like the current 0.13, then everything is possible, and I accept that fact. When it does leave the "experimental" state I'll expect it to be fairly stable, just like 0.12 has been most of the time.

And I'm sure the devs will deliver on that front (they've already proved for years they're capable of delivering a technically outstanding product).