If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?posila wrote: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.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.
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.Mooncat wrote:If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?
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"...posila wrote: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.Mooncat wrote:If setting "allow_custom_vectors" to false can avoid the blueprint bug, shouldn't its default value be false instead of true?
hm... so what is "allow_custom_vectors" exactly for? To avoid vanilla inserters being edited by blueprint editing mods?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.
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).Mooncat wrote:hm... so what is "allow_custom_vectors" exactly for? To avoid vanilla inserters being edited by blueprint editing mods?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.
Thanks for the explanation! I think I understand it now.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.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.
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?torne wrote: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.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.
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.
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.GotLag wrote:I prefer to have the default as false, because that means I can distinguish between false by default (nil) and explicitly false.
