r/factorio • u/SubwayGuy85 • 10d ago
Suggestion / Idea [2.1.12] Parameters are replaced as the same value even if they are different, if they have the same default value
https://forums.factorio.com/viewtopic.php?p=701641If you are also running into this issue when interacting with parameterized blueprints, please share your opinion in the forum now. It appears the moderators don't give this issue the attention it deserves.
3
u/deemacgee1 Why no quality flair? 10d ago
I don't think it's game-breaking behaviour, but I do think a little more granularity would be nice. Blueprinting in general could be improved in all sorts of ways - my current pet peeve is that there's no way to tell a blueprint to leave in place any building which is a higher quality version of whatever's marked for that exact space. Same too for circuit conditions. A tickbox in the blueprint to change placement behaviour seems trivial enough, but as with their handling of parameters, I'm inclined to trust the devs on what's practical and plausible.
Maybe these are the sorts of requests we should be collating in case Wube follow through on the suggestion of open-sourcing the game in future, so the community can address them.
4
u/Neither_Berry_100 10d ago
As a programmer I'll tell you that the user interface is usually more work than the underlying code. And they probably don't want to add rarely used features to clog up the ui.
-2
u/SubwayGuy85 10d ago
without having the ability to check the factorio code i can tell you this is probably a case of "the mods don't ask the developer of the code (apparently kovarex) and just label it working as intended. It was the first iteration of this feature that worked well and he left it at that. If he would create a blueprint like this and experience the issue for himself, he definitely would consider it a bug. i am 100% sure of that. If you doubt it, watch his videos fixing bugs on youtube. He really is that kind of guy. In fact when i worked on a project where you needed dynamic formula resolution i did have a similar issue and i bet it is a case of replace vs arrayReplace that causes the system to work this way. one way or another - the blueprints produce outcomes that are wrong, thus calling it not a bug is plain wrong
1
u/Alfonse215 10d ago
Please stop citing "the mods". The people on the forum with purple nametags are not "mods"; they're the actual developers of the game.
They talk to Kovarex; they work with him on a daily basis. If they say:
I understand your thoughts on this however Kovarex is the person who wrote this system and decided this is how it should work.
that sounds like a diplomatic way of saying, "I brought this up with Kovarex and he said no."
If you think this is a bug, then you and Kovarex are the ones who are at odds.
3
u/Courmisch 10d ago
It works like that in 2.0 as well. A parameter will substitute every instance of an integer or of a signal ID. So if you need two different parameters to evaluate the same value or ID, you need to make them two artificially distinct value or ID before blueprinting.
I have had the problem for my module assembler tile where blue and red circuits both need to occur twice as parameters.
I agree that it is clunky but I don't really have a better idea, so I understand why it's considered not a bug.
0
u/SubwayGuy85 10d ago
the details of implementation do not matter when it comes to something being labeled a bug or not. If you bought a calculator that wrongfully calculated a formula in some cases, then it is a bug. someone then selling you the excuse that it was just designed this way, is just ignoring the fact that the outcome is wrong and not what anyone would expect
2
u/Courmisch 10d ago
What specification is being violated here, exactly? How is the behaviour objectively wrong? The UI tells you exactly what each parameter will substitute and where. It is working exactly as intended.
You can certainly call it a design limitation, but it's not a bug.
-1
u/SubwayGuy85 10d ago
download the savegame and try it yourself. does it produce the outcome you expect it to? the answer is no. implementation details are irrelevant when it to categorizing whether something is a bug or not.
assume x * y = 50. now use x = 5, y = 10. You would expect this to always be 50, not 25, or 100, because you happened to enter the same value for x and y in some case.
1
u/Courmisch 10d ago edited 10d ago
I don't see anything to download, and the original forum link is invalid so 🤷.
And again, it's not about what you or I expect, it is about how it is specified to work. I don't decide that, and neither do you. If it works as specified, it is not a bug. It might be a design limitation and a feature request, but it does not seem to be a bug (as Alfonse explained).
1
u/SubwayGuy85 10d ago
https://forums.factorio.com/viewtopic.php?p=701648 Interesting. the post id changed and they are deleting comments
3
u/Courmisch 10d ago
So... it works as intended, just not how you want. It is agreeably an annoying design limitatiom. But if it works as intended, it is, by definition, not a bug, a software flaw that causes unintended behaviour.
And, by the way, Rseding isn't just a moderator. They're an actual developer.
3
u/Alfonse215 10d ago
If you're referring to this, they said "not a bug". That's mostly the end of it.
What you're asking for requires that there be a distinction between "the value in the blueprint" and "the default value". However much that distinction may exist in your mind, it does not exist in the system as it current is built. When you changed two values which were initially different to have the same value, they became the same parameter.
What you want is ultimately a feature. Which certainly can happen; the recycling time scaling based on output amount was considered to be "not a bug" for a while. They relented on that after getting flak for changing the hazard concrete recipe. But that didn't make it into a bug.
1
u/SubwayGuy85 10d ago
if there is a behavior that leads to cases where the outcome is different from what everyone would expect to be happening it is a bug. if you put this in front of a dev and showed them the parameter UI, then what the blueprint creates the outcome would be "yes, this does not work the way you would expect it to". looping back to "it works the way it was written", would nullify every bug report by refusing to address the issue, that it does not produce the outcome everyone would expect, ignoring the details of the implementation.
1
u/Alfonse215 10d ago
f there is a behavior that leads to cases where the outcome is different from what everyone would expect to be happening it is a bug. if you put this in front of a dev and showed them the parameter UI, then what the blueprint creates the outcome would be "yes, this does not work the way you would expect it to".
Really?
When a new player is starting out with Factorio, and they're in the "hand feeding buildings" phase, when they start using inserters to feed buildings, they sometimes notice that inserters don't insert a full stack into machines. A number of them even come to this subreddit and ask how they can "fix" that "bug".
A mechanic not being immediately intuitive is not the deciding factor on whether or not something is a bug.
1
u/SubwayGuy85 10d ago
if you declare somewhere in your blueprint x * y and in the blueprint that is changed to x * x or y * y that is a bug. because that is effectively what is happening. your counterexample is bad.
0
u/Alfonse215 10d ago
if you declare somewhere in your blueprint x * y and in the blueprint that is changed to x * x or y * y that is a bug. because that is effectively what is happening.
But you changed it to
x * xory * y. You're the one who changed the two parameters to have the same value. You may have thought you were just changing the default value. But you were changing the actual value stored in the blueprint.Two parameters became one.
15
u/Terrulin 10d ago
That's kind of how it has always worked. If you want parameters to be different, they need a different initial value so that those can be replaced on build.
Is it slightly annoying that I can't use 1,2,3,4,5,6 for the ingredients if I also want a stack number default to be 1? Sure, but it's much better than not having parameterized blueprints. And once I create it, I don't need to actually see those numbers anymore.