Factorio Forums

See as well: 121070

Copy blueprint

This is a very specific pair of issues which are certainly related to the same root bug, and I saw a topic about this sort of thing but it didn't mention all of the parts I've found, which is why I'm going to report this separately from that one:

Steps to reproduce:
>Import BP
>Edit parameterization
>change Variable L or C
>press enter or check box
>variable "chests per wagon"(C) is now irrecoverable without reloading full BP, even without saving BP

Steps to reproduce:
>Import BP
>paste BP
>choose two different settings for "Cargo wagons" and "chests per wagon" in dialog box(like 2 and 8)
>both will be set in constant combinator to the value of "chests per wagon", likely due to 4 being default for both.


Further info: The variables are set as L(cargo wagons) and C(chests per wagon), but both are set as 4 by default. Changing them in in the blueprint before placing makes the later one vanish, despite having its own separate variable. This occurs as soon as you hit enter or the green check box to accept the change to the parameters, and is permanent, even if you don't "save blueprint" afterward, forcing re-import of the BP to fix. Parameters shouldn't be saved if you don't save the BP, so that feels like maybe a separate issue.

Attached to this issue is that, when placing an unaltered version of this, any setting applied to "chests per wagon"(C) in the dialogue box will apply to both "Cargo Wagons"(L) and "chests per wagon"(C). It appears that having set both of the variables to the same number when saved, the later one has taken over the setting, but the earlier one eats the later one if you change one in the parameterized blueprint before placing. It seems like the system is overzealous in trying to force variables together.

There's no way to fix this with the blueprint as is, the maker would have to make it wholly anew and avoid having any variables that have the same value which seems a tad obnoxious in practical use.

Confirmed in 2.0.16. I thought this would be related to the behavior where parameters with the same number get combined, but this is different.

Variable constants L and C (not the L and C signal icons) both start as '4' when you load the blueprint. If you change variable C from '4' to '2' and close the blueprint, when you reopen it the line for variable C is gone and the formula that uses C is highlighted red (since C is not defined).

The bug, summarized:
When two named value parameters share the same value, they consolidate into one parameter as if they were unnamed.
This can cause constants to get tied to parameters, and parameters to get tied to constants.

Workaround:
Either:
* Use unique, non-sensical default values for your parameters that share values with constants.
* Set the parameters exclusively in the blueprint - treating them as pseudo-constants.

Minimum working examples [2.0.17 (build 80319 expansion, win64)]:

Parameter of the blueprint is ignored
Copy blueprint
This screenshot describes what you'll observe in-game:


Constant is hijacked by the parameter
Copy blueprint
Similar screenshot:


The only functional difference between these two blueprints is the order.
For the ignored parameter, it occurs after the constant.
For the constant that is hijacked by the parameter, it occurs after the parameter.

This, together with not being able to a new parameter (e.g. for use in a calculation step before the actual usage) are the two things I REALLY wish could get fixed.