Caused by the fix for viewtopic.php?p=641471#p641471.
Originally, a parameter y could only be set to be an ingredient of a parameter x if parameter x is used as a recipe within the blueprint. For example, if it is the recipe in an Assembler.
Kovarex fixed the bug/changed it such that parameter y can now be set to be an ingredient of any parameter x.
THE BUG
A parameter x that is NOT used in an assembler does not expose its crafting-related variables to the formula field, even if a parameter y is set to be an ingredient of parameter x.
Meanwhile, A parameter x that IS used in an assembler does expose its crafting-related parameters to the formula field, regardless of whether a parameter parameter y is set to be an ingredient of parameter x.
This behaviour is inconsistent.
It means that two functionality identical* blueprints have access to different variables:
* I recognize that these two blueprints aren't identical, but if their recipe is to be set by the circuit network, they might as well be.
For a 1-EM plant no-productivity loss quality cycler blueprint I was parameterizing, this led to a nasty surprise: the parameters I need (p0_t, p0_i1, ..., p0_i6) aren't available
This means I'll have to make a new blueprint with an assembler that already has the parameter set as a recipe, parameterized it, and at the very end, remove the extra assembler.
Or ignore the validation errors, because the compilation still works fine, but it's extremely janky:
Point is: this bug limits circuit-controlled assembler designs and forces the user into using extreme jank.
PROPOSED FIX
Always exposing all crafting-related parameters of a parameter x to all formula fields would lead to hefty amounts of clutter.
Instead, I would expose crafting-related parameters of a parameter x only if one of the following conditions apply:
- parameter x is used in a production building (current behaviour)
- Another parameter y exists that is marked as an ingredient of parameter x (additional new behaviour)
Thank you for your time!