Version 0.18.22

[Pi-C]

if you want to play with mods you mostly are forced to play with any experimental 0.18 while the last stable is still 0.17.79

Mostly. I'm a proponent of making double releases for 0.17 and 0.18 regularly since I first noticed that a considerable part of total downloads were for 0.17 (for the latest release of Bio Industries, about 30 % of all downloads!). But I know that many mods are only updated for 0.18, which I also can understand since double releases mean more work, and not every feature can be backported.

[Koub]

Agreed, something like a week's notice would have been better. It still wouldn't have guaranteed that everybody would have noticed it …

Technically, we're short of 3 years notice, as the change was announced first here, but I can understand the last reminder arrived a bit on the late side.

[Squelch]

Just a general observation regarding deprecation and defunct values and keywords is that it is customary to log such things at compile time, or in the case of scripts, at runtime with plenty of lead time until made obsolete. I don't recall seeing these in any of the logs I have been looking at, but then again, they can become rather full of warnings and notes anyway, so I stand to be corrected on this.

The API docs don't give much away in this regard and merely list the two possible values of consuming = "game-only" and "none". "none" being is the default value if omitted. I did assume that "all" and "script-only" were being silently dropped and the value of "none" assumed in their place. These previous values were once included in sample scripts as comments, and appear to have been passed along via copy and paste by some mod authors perhaps oblivious to the impending change. The API docs do not note any deprecation to be fair, so it is only by deduction that if there only two possible values, anything else is illegal.

The illegality or critical treatment of the use of "all" and "script-only" does leave me rather baffled however. If they (I assume) were being silently dropped and then assuming a "none" value, then what makes these legacy values now so dangerous as to warrant the mod not being able to be loaded? I'm sure there must be a perfectly plausible reason, but on the face of it, it does seem rather draconian.

As for the notice that was given. Yes, it is true that it was mentioned some 3 years ago, and there was a notice post made the day before 18.22 was released, but I would guess that not everyone necessarily reads every single announcement or notice, or indeed understands the consequences of these notices, especially the none developer/players that are only interested in actually playing. This is not meant to be argumentative, but before lambasting someone for not paying attention, or complaining that we should be entitled to a full explanation, just take a moment and pause for thought. Things do get overlooked, and the consequences of changing something that might seem insignificant can have far reaching consequences. This fine project is still being developed, and eggs do have to be broken sometimes. Not everyone has the same skill set or interests that you might have, so please exercise some latitude when dealing with others.

[Pi-C]

Agreed, something like a week's notice would have been better. It still wouldn't have guaranteed that everybody would have noticed it …

Technically, we're short of 3 years notice, as the change was announced first here, but I can understand the last reminder arrived a bit on the late side.

I know, this has been brought up already. But let's face it: such an old notice hasn't much practical value because some people may never have seen it and others most likely will have forgotten about it. Imagine the minor Factorio versions being people: we're at 0.18 now, 0.17 would be the parent generation, 0.16 the grandparents, and 0.15 the great-grandparents! Now turn back to real people: There may be some of the great-grandparents' generation alive, and they may still have first-hand memories of the time they grew up. Also, there may be people who take a personal or professional interest in history who will read through newspapers of times long past. But you can't take for granted that everybody will be aware of small society scandals that happened a hundred years ago.

[Squelch]

Heh, prompted by Pi-C's society scandals in long past newspapers, I checked the API doc history of course.

The first mention of "all" and "script-only" being dropped was in fact 15.24's change notes as Koub has just revealed. At that time, LuaCustomInputPrototype wasn't even documented, and didn't make its debut appearance until 16.0 with the only two options we have now. I do not know where the script template notes originated, but I have come across it a few times recently while looking at some other scripts.

Code: Select all

  -- 'consuming'
  -- available options:
  -- none: default if not defined
  -- all: if this is the first input to get this key sequence then no other inputs listening for this sequence are fired
  -- script-only: if this is the first *custom* input to get this key sequence then no other *custom* inputs listening for this sequence are fired. Normal game inputs will still be fired even if they match this sequence.
  -- game-only: The opposite of script-only: blocks game inputs using the same key sequence but lets other custom inputs using the same key sequence fire.

So, technically, this could be called a none issue because it was never apparently documented officially, and just seems to have been grandfathered in from some much older mods until now.

[Omnifarious]

Heh, prompted by Pi-C's society scandals in long past newspapers, I checked the API doc history of course.

The first mention of "all" and "script-only" being dropped was in fact 15.24's change notes as Koub has just revealed. At that time, LuaCustomInputPrototype wasn't even documented, and didn't make its debut appearance until 16.0 with the only two options we have now. I do not know where the script template notes originated, but I have come across it a few times recently while looking at some other scripts.

So, basically, every single place where values other than 'none' or 'game-only' appear is the result of what I call "Cargo Cult Programming" where you put stuff in because that's what you've seen other people do without understanding it yourself. Note, that's exactly what _I_ did with one of the mods I wrote (both are very tiny mods, nothing special).

[malventano]

There was an early enough warning for this change

There was warning, but it was issued years ago,

There was a warning just a day before 0.18.22 was released in the Upcoming breaking mod changes thread. I was lucky enough to see it shortly after it had been posted, I was even more lucky that the change didn't affect any of my mods -- and I just subscribed to the thread so I won't miss any of these posts in the future.

viewtopic.php?p=292733#p292733

So 3 years is still not early enough.

As the fix is so easy just do it yourself if you can't wait for the mod author.

Quick fix for all lazy B's: https://mods.factorio.com/mod/zzz_fix_your_shit

The issue was that since there was a workaround implemented, the mods using the old method didn't break, so nobody knew there was an issue in the first place. The patch notes do say there was a change, but there is no mention of a workaround, so the assumption would be 'if it ain't broke, don't fix it' as far as mods went.

[Oktokolo]

The thing is that there was no reason to make mods with obsolete keywords that did nothing for years not to load at all. It would have been enough to display a warning on load that the mod is using some outdated code.

They removed the lagacy code handling the old setting value to reduce the amount of obsolete code in their code base. They should have done that much earlier but probably forgot about it. Less code means less code to maintain. So removing unneeded code is a good deed.
That mods using the obsolete value don't load anymore is the logical consequence of not having special handling for it anymore - it is just an ordinary member of the infinite set of invalid values now.

Factorio's prototype parser probably has no mechanism for deprecating values, wich could have been used to log warnings or display a (non-game-terminating) dialog on application initialization.
As they are going for 1.0.0 now, they probably did not want to add such a mechanism either. The API has proven to be exceptionally stable in the past and will not change much after release anyway. So adding a deprecation mechanism would just be a waste of coder time...
Just removing the forgotten code in the unstable branch is the right choice here.
Mod authors have plenty of time to get their copy'n'waste "programming" fixed and decide how their hotkeys actually should behave. Unstable users will report them the problem. Stable users will just get the fixed mods with the next stable.
Everything is fine and the mod update cycle works as usual.

Generic P.S.:
Unstable is called that for a reason. Alphas and betas are not the final product. APIs are bound to change before finalization (especially the undocumented parts).
If you don't want to deal with mods breaking over a minor version change, play the stable branch.
If you don't want to deal with API or gameplay changes, wait until release.

[Bilka]

Heh, prompted by Pi-C's society scandals in long past newspapers, I checked the API doc history of course.

The first mention of "all" and "script-only" being dropped was in fact 15.24's change notes as Koub has just revealed. At that time, LuaCustomInputPrototype wasn't even documented, and didn't make its debut appearance until 16.0 with the only two options we have now.

So, technically, this could be called a none issue because it was never apparently documented officially, and just seems to have been grandfathered in from some much older mods until now.

You're looking at the runtime docs for a data stage problem. The controls stage LuaCustomInputPrototype was only *added* in 0.16, so it only then appears in the runtime docs.
The *data stage* custom input prototype was first documented here: https://wiki.factorio.com/index.php?tit ... did=150470. I linked you to the version from September 2017, which is before 0.16 release. As expected, the tutorial mentions the then recently removed values for the consuming type as removed and describes only the other ones.
The data stage documentation for the consuming type was created in January 2018 and hasn't changed since then: https://wiki.factorio.com/Types/ConsumingType. It doesn't mention the removed values at all, simply because they are not part of the "possible values", and the removal wasn't "recent" anymore.

[Kyralessa]

It makes perfect sense to clean up on the experimental branch in preparation for the 1.0 release ...
Nobody is forced to play on the experimental branch.

correct in both points,
but if you want to play with mods you mostly are forced to play with any experimental 0.18 while the last stable is still 0.17.79

No, not at all. I have multiple installs of Factorio, using the .zip files.

• 0.17.79 install for mods that aren't going to be updated until 1.0.
• 0.18 install to see the changes
• Separate 0.18 install with a significantly game-changing mod.

You can have as many Factorio directories with different versions, or different mod combinations, as you like. That's the whole point of the .zip file installs.

[posila]

Hello, I'd like to say we mess this up, and we are sorry we caused this problem. In the future we need to be more careful about removal of legacy code, that in our minds has been deprecated for so long "most mods wouldn't use it anymore."

We should have made better job deleting the code in 0.18.0 (because it was marked for deletion after save compatiblity with 0.15 would be dropped). Usage of deprecated values should have at least put warnings into the log, but idea of putting deprecation warning into the main menu is something we should do for next time.

[steinio]

Hello, I'd like to say we mess this up, and we are sorry we caused this problem. In the future we need to be more careful about removal of legacy code, that in our minds has been deprecated for so long "most mods wouldn't use it anymore."

We should have made better job deleting the code in 0.18.0 (because it was marked for deletion after save compatiblity with 0.15 would be dropped). Usage of deprecated values should have at least put warnings into the log, but idea of putting deprecation warning into the main menu is something we should do for next time.

That's a very nice move and will calm down the people.

I wouldn't be angry if you clean up your code more aggresivly. It's just about everyones comfort zone.

[Anson]

.... Unstable users will report them the problem. Stable users will just get the fixed mods with the next stable.
.....Generic P.S.: Unstable is called that for a reason. Alphas and betas are not the final product. ....
If you don't want to deal with mods breaking over a minor version change, play the stable branch.

what about other problems and bugs in mods that mod authors only fix for a 0.18 version and not for 0.17 ? without updating factorio to an experimental 0.18, users of those mods will either have to fix the problems themselves, try downgrading the mod's fixed/updated version by editing the info.json (and hoping for the best), or stop using that mod.

rant about oktokolos own outdated stable mods

as far as i could see, you (Oktokolo) have four mods, all of them being updated for 0.18, some having fixed problems and/or include new features, and in a discussion on the mod portal you wrote that you yourself don't keep your own mods usable for the last stable :
> I don't backport.
> But if you want it for 0.17, feel free to just change the Factorio and bobplates version in the info.json.
> It should work just fine with 0.17 then.

thus you made the fixed/changed versions of your mods unusable for "stable users" unless they backport them themselves. even though in that specific case and two months ago, that might have been a minor change that works, it requires users to edit your mod, and most important (that's what i meant above with "hoping for the best") it requires them to also change other mods that may not be so easily backportable by a simple change in info.json when those other mods in the meantime also got important updates (in this case that other mod got fixes for bugs, icons, balancing, recipes, changes for the techtree, and requires a new version of libraries).

although you meant this statement in another context, saying "Stable users will just get the fixed mods with the next stable." means that users of your old stable 0.17 mod need to wait a while (a year?) for a stable 0.18.xxx or even the final release 1.0 before using your mod again ?

>>> .... Nobody is forced to play on the experimental branch. ....
>> .... but if you want to play with mods you mostly are forced to play with any experimental 0.18 while the last stable is still 0.17.79 ....
> No, not at all. I have multiple installs of Factorio, using the .zip files.
> 0.17.79 install for mods that aren't going to be updated until 1.0.

yes, you can have separate installs, but what happens to mods in your 0.17.79 install that are buggy and only fixed/updated for 0.18 ... ?
you either have to live with the buggy version, or have to remove them and can't use them any longer, or have to update the game and mods to 0.18.
i use several such mods and thus i said "when playing with mods, you mostly are forced to update to 0.18" (although not necessarily always the latest 0.18) ...

I wouldn't be angry if you clean up your code more aggresivly. It's just about everyones comfort zone.

one problem with this "sudden" change was that we are not used to anything severely breaking and then also not being fixed with a hotfix on the same day :-) for all normal users (non-modders) it might already have been helpful to include a warning in the last release notes "watch out for some changes in the next update that might break several improperly written mods and (this time only) it might be best to not update automatically" :-) or when 0.18 soon is reasonably stable call some 0.18.xx version "stable 1" to enable people to upgrade to that version and stay there in "relative safety" from future aggressive cleanups that may be necessary and even may be welcome by users to advance the game towards 1.0 ... of course, a warning might be useful before doing so, to not surprise those 0.17 users who have set the options (ingame or on steam) to "autoupdate to latest stable, ignoring experimental updates" ...

[Squelch]

You're looking at the runtime docs for a data stage problem. The controls stage LuaCustomInputPrototype was only *added* in 0.16, so it only then appears in the runtime docs.
The *data stage* custom input prototype was first documented here: https://wiki.factorio.com/index.php?tit ... did=150470. I linked you to the version from September 2017, which is before 0.16 release. As expected, the tutorial mentions the then recently removed values for the consuming type as removed and describes only the other ones.
The data stage documentation for the consuming type was created in January 2018 and hasn't changed since then: https://wiki.factorio.com/Types/ConsumingType. It doesn't mention the removed values at all, simply because they are not part of the "possible values", and the removal wasn't "recent" anymore.

Thanks for the info. I do have an understanding of the process that went on here, and that the information has been lost to time. I also strongly suspect that the use of the legacy values has been propagated via example, copied and modified... if it works, why touch it kind of mentality.

Hello, I'd like to say we mess this up, and we are sorry we caused this problem. In the future we need to be more careful about removal of legacy code, that in our minds has been deprecated for so long "most mods wouldn't use it anymore."

We should have made better job deleting the code in 0.18.0 (because it was marked for deletion after save compatiblity with 0.15 would be dropped). Usage of deprecated values should have at least put warnings into the log, but idea of putting deprecation warning into the main menu is something we should do for next time.

Perfectly understandable, and just one of those apparently inconsequential things that you have been meaning to do, but unaware of how widespread its (incorrect) use was.

Putting a warning popup on game start that deprecation is imminent and allowed to continue so players can prepare and modders can update would have been the most desirable way forward. Thank you all the same.

[Raxnar]

I would like to download the stand alone version of the latest .18 beta but I see they are not currently offered.

Sometimes I join a friends server on latest stable build but then want to dable in the latest beta offline in single player only.

It would be nice to have that offline copy and not have to constantly switch versions in steam.

Is it possible to post the latest .18.22 for download please?

[Pi-C]

I would like to download the stand alone version of the latest .18 beta but I see they are not currently offered.

They are available on the download page.

Is it possible to post the latest .18.22 for download please?

Look here!

[Raxnar]

I would like to download the stand alone version of the latest .18 beta but I see they are not currently offered.

They are available on the download page.

Is it possible to post the latest .18.22 for download please?

Look here!

Ahh Logging in was the issue, time for Coffee #2

Thanks!

[Hiladdar]

One of my mods crashed, not when 0.18.22, was released, but a bit earlier. I was able to trace the crash down to my mod trying to reference a graphic file which was removed as part of the code cleanup. Not a problem. I just downloaded an older version of Factorio, moved that graphic into my module, and corrected the pointers to that graphic and rolled out a patch.

I do not see that as a problem, especially since we were giving warnings via FFs around the time .18 was released that there would be a significant number of small things being tightened up in the releasable base game in preparation for 1.0 that would break some mods. I expect this trend to continue.

What I would like to see is that when 1.0 rolls out, all the mods that work on the most recent experimental version of Factorio prior to 1.0 would continue to work under 1.0 without any modification. That that would be a powerful marketing for Webe, to say they have over 2k mods available upon release.

Hiladdar

[Klonan]

What I would like to see is that when 1.0 rolls out, all the mods that work on the most recent experimental version of Factorio prior to 1.0 would continue to work under 1.0 without any modification. That that would be a powerful marketing for Webe, to say they have over 2k mods available upon release.

Yes we are thinking of some special check in the code that, basically internally, 1.0 is 0.18,
So mods with 'Version 0.18' will still load in 'Version 1.0'

(Then if we do a 1.1, we will continue the break mods system, where mods marked 1.0 won't load in version 1.1)

[Oktokolo]

as far as i could see, you (Oktokolo) have four mods, all of them being updated for 0.18, some having fixed problems and/or include new features, and in a discussion on the mod portal you wrote that you yourself don't keep your own mods usable for the last stable :
> I don't backport.
> But if you want it for 0.17, feel free to just change the Factorio and bobplates version in the info.json.
> It should work just fine with 0.17 then.

The 0.17 versions of all that mods still work just fine in 0.17.x.
Two of that mods literally got just a version bump and some metadata change.
For one of them, i fixed actual bugs - wich rarely still happen in the 0.17.x version and are actually just minor annoyances, wich could also very well be seen as a tiny logistiscs challenge .
Two of them got actual feature improvements. All in all i just adopted the convenient Factorio release cycle. I update more or less early in unstable and when unstable becomes stable, my mod is already well tested, so i hopefully never have critical bugs in old versions.

thus you made the fixed/changed versions of your mods unusable for "stable users" unless they backport them themselves.

I did not delete the 0.17 versions. If you want to get new stuff, you can swiutch to unstable or wait for it becoming stable. That is how it works for vanilla Factorio. And that is how it works for my mods...
Except: As everyone else, you too are allowed to fork and backport my mods for 0.17 if you want to. You could also provide the backports for other users to download on the mod portal.

although you meant this statement in another context, saying "Stable users will just get the fixed mods with the next stable." means that users of your old stable 0.17 mod need to wait a while (a year?) for a stable 0.18.xxx or even the final release 1.0 before using your mod again ?

No, they can just keep using the 0.17 version until they switch to 0.18. As i did not backport the mods, they never got the 0.18 regressions wich i had to fix for one of my mods. They also never got that new battery icons wich have an optional dependency on some 0.18-updated third party mod.
And if they are able to wait for all that shiny Factorio features to become stable, they surely can wait for some rather minor improvements to my tiny mods too.