Factorio Forums

Bugfixes

• Fixed that wire connections were not preserved in tightspot campaign. (48910)
• Fixed various crashes on macOS related to logistic counts. (49053)

Modding

• Changed default value of "allow_custom_vectors" in inserter prototype to true, vanilla inserters set it to false explicitly.

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

Experienced the crash a couple of hours ago on osx. You guys are awesome!

Insane how fast you guys fix things! Get some sleep!

I was totally not expecting a fix for this today!

Wube/Factorio teams Rock!

I have bought 4 copies of the game so far, and will find someone else to spread the word to and buy them a copy!

- Jack

Since my concern has not been answered, I type it here again:

posila wrote:

ZlovreD wrote:Reasonable solution is making it "true" by default (even if it missing), which tooks all non-vanilla inserters.
Another modding to make live harder, like it was with tanker rotations.

I was about to explain how this was done to fix a bug where importing blueprint string with modded vanilla inserters to vanilla game would make it possible to have inserters with arbitrary pickup/drop target ... and then I realized you are right, we could have defaulted it to true and set it to false for vanilla inserters explicitly.

If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?
Sure that will break some mods, but in obvious way, such that modders can know the problem and fix it in the first place. But when its default value is true, modders who provide modded inserters without custom pickup/drop locations, e.g. super fast inserter with same locations, will potentially expose the bug to users and they may not even know about that. It will be too late when a user encounter the bug. You don't know who and how he will report the bug to.

Mooncat wrote:If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?

Main goal was to keep vanilla as vanilla. We will probably change the default back to false in 0.16, when mods need to be updated anyway.

posila wrote:

Mooncat wrote:If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?

Main goal was to keep vanilla as vanilla. We will probably change the default back to false in 0.16, when mods need to be updated anyway.

Sorry but I don't understand how setting its default value to true and explicitly setting it to false for vanilla inserters can "keep vanilla as vanilla"...
I think it is better to change it back to false before 0.15 becomes stable, or I'm afraid that you will get reports about that bug caused by modded inserters.
Bob has updated his mods with "allow_custom_vectors" anyway, I guess it shouldn't be a problem to change it back now?
Thanks for your precious time for answering.

It's more of an exploit than a bug. You can hack inserters into new directions with an edited blueprint. So users won't run into it unless they are trying to.

DaveMcW wrote:It's more of an exploit than a bug. You can hack inserters into new directions with an edited blueprint. So users won't run into it unless they are trying to.

hm... so what is "allow_custom_vectors" exactly for? To avoid vanilla inserters being edited by blueprint editing mods?

Mooncat wrote:

DaveMcW wrote:It's more of an exploit than a bug. You can hack inserters into new directions with an edited blueprint. So users won't run into it unless they are trying to.

hm... so what is "allow_custom_vectors" exactly for? To avoid vanilla inserters being edited by blueprint editing mods?

Basically if you don't have mod that enables it inserters will ignore custom positions even if you have them in blueprint. So blueprint will no longer work if mod that is used to set up inserters is not present (or similar mod).

Long story short. It doesn't really make a whole lot of difference if you have it set to true by default, and false in the vanilla definitions, or just false to default.

The idea behind the tag is thus. It is possible to create blueprints that include base game inserters with edited positions, using modded tools such as my inserters mod.
Since the entity is still a base game entity, those changed positions would still be valid in the blueprint, as would the entity itself, and therefore the blueprint would pass all validity checks.

What adding this flag does to the game is make this blueprint invalid. I'm not sure if the blueprint would just be registered as invalid, or still be valid and place-able, but the inserters defaulting to their default hand positions, but either way, it should fix the bug.

bobingabout wrote:Long story short. It doesn't really make a whole lot of difference if you have it set to true by default, and false in the vanilla definitions, or just false to default.

The idea behind the tag is thus. It is possible to create blueprints that include base game inserters with edited positions, using modded tools such as my inserters mod.
Since the entity is still a base game entity, those changed positions would still be valid in the blueprint, as would the entity itself, and therefore the blueprint would pass all validity checks.

What adding this flag does to the game is make this blueprint invalid. I'm not sure if the blueprint would just be registered as invalid, or still be valid and place-able, but the inserters defaulting to their default hand positions, but either way, it should fix the bug.

Thanks for the explanation! I think I understand it now.
So the parameter tells the game whether the inserter's locations have been (or can be) changed by the set location functions and thus they are different from the prototype?
Then I guess you are right, there is nothing really need to concern as long as it is false for the vanilla inserters. Thanks.

bobingabout wrote:Long story short. It doesn't really make a whole lot of difference if you have it set to true by default, and false in the vanilla definitions, or just false to default.

The idea behind the tag is thus. It is possible to create blueprints that include base game inserters with edited positions, using modded tools such as my inserters mod.
Since the entity is still a base game entity, those changed positions would still be valid in the blueprint, as would the entity itself, and therefore the blueprint would pass all validity checks.

What adding this flag does to the game is make this blueprint invalid. I'm not sure if the blueprint would just be registered as invalid, or still be valid and place-able, but the inserters defaulting to their default hand positions, but either way, it should fix the bug.

Except it still doesn't fix the bug for new inserter types created by other mods which aren't intended to have altered pickup/drop locations - it's still possible to take a game that has both a mod that introduces new inserter types, and a mod that gives all inserters the ability to have custom pickup/drop locations, and create a blueprint which you can import into a game with just the first mod and end up with an "impossible" configuration.

It really does seem like it makes more sense for the default to be false, and for any mods whose purpose is to customise inserter pickup/drop locations to just flip it back to true for the inserters they customise. That way, blueprints will do the right thing when copies between games with any combination of inserter mods.

Did this update just reset achievements? Or does switching from a modded game back to vanilla do that (if so, why - can't it keep track of both modded and vanilla achievement progress)?

I installed Bob's mods a few days ago while I was on 0.15.17. I just upgraded to 0.15.18, then disabled all mods, and continued playing a vanilla 0.15.17 savegame. After a few seconds a bunch of achievements were unlocked - and then I noticed all of them had been reset. I'm not using Steam, if that matters.

Hey small idea could we get either a option to disable/remove the restart button or have it at the bottom either above or below quit, cause i had a moment of in-attention and click yes to restarting and boy was that annoying

torne wrote:

bobingabout wrote:Long story short. It doesn't really make a whole lot of difference if you have it set to true by default, and false in the vanilla definitions, or just false to default.

The idea behind the tag is thus. It is possible to create blueprints that include base game inserters with edited positions, using modded tools such as my inserters mod.
Since the entity is still a base game entity, those changed positions would still be valid in the blueprint, as would the entity itself, and therefore the blueprint would pass all validity checks.

What adding this flag does to the game is make this blueprint invalid. I'm not sure if the blueprint would just be registered as invalid, or still be valid and place-able, but the inserters defaulting to their default hand positions, but either way, it should fix the bug.

Except it still doesn't fix the bug for new inserter types created by other mods which aren't intended to have altered pickup/drop locations - it's still possible to take a game that has both a mod that introduces new inserter types, and a mod that gives all inserters the ability to have custom pickup/drop locations, and create a blueprint which you can import into a game with just the first mod and end up with an "impossible" configuration.

It really does seem like it makes more sense for the default to be false, and for any mods whose purpose is to customise inserter pickup/drop locations to just flip it back to true for the inserters they customise. That way, blueprints will do the right thing when copies between games with any combination of inserter mods.

But the chance of having such mod is pretty low. Who will change the inserters from another mod but not create new inserters for himself instead?
Yes, changing its default to false can eliminate this situation, but it is not extremely important now.
It is fine to have it set to false in 0.16.

I prefer to have the default as false, because that means I can distinguish between false by default (nil) and explicitly false.

GotLag wrote:I prefer to have the default as false, because that means I can distinguish between false by default (nil) and explicitly false.

True... it is quite difficult at times to distinguish between nil and false. Most quickchecks will fall over this, you can only actually catch it if you excplicitly check for a ==false condition.

Also aparantly table.copy falls over and doesn't copy tags that ==false sometimes. (or maybe that was my specific use-case of table.copy that failed)

could you please add in the next version at the train-freight options the liqiuds like in the trainstops

also a button for renaming locomotivs would be nice

Whenever I try to load in the experimental version 0.15.18 I get a message saying "Automatic Steam update notice" Then it says its made by a beta branch and it wont let me click ok. Anyone know why? I also have a message in the back I cant read becasue of the one that I just read off but its titled configuration, if anyone knows what that is