See as well: 121070
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.
[2.0.15] Parameterized Blueprint variable issues
-
BeefTaquitos
- Manual Inserter
- Posts: 1
- Joined: Tue Nov 12, 2024 11:42 am
- Contact:
Re: [2.0.15] Parameterized Blueprint variable issues
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).
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).
My mods: Multiple Unit Train Control, Smart Artillery Wagons
Maintainer of Vehicle Wagon 2, Cargo Ships, Honk
Maintainer of Vehicle Wagon 2, Cargo Ships, Honk
Re: [2.0.15] Parameterized Blueprint variable issues
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
This screenshot describes what you'll observe in-game:
Constant is hijacked by the parameter
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.
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
This screenshot describes what you'll observe in-game:
Constant is hijacked by the parameter
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.
-
pindab0ter
- Burner Inserter
- Posts: 9
- Joined: Fri Nov 01, 2024 12:27 pm
- Contact:
Re: [2.0.15] Parameterized Blueprint variable issues
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.
Re: [2.0.15] Parameterized Blueprint variable issues
I found an actual workaround, but I'm afraid using it will alert eldritch horrors to my location:
Since everything is based on the VALUE, even when named, you need to use unused values for your constants and set them to the desired constant value in the Formula field.
This way, the Quality parameter of 4 and Batch size exponent base of 2 can be adjusted at will without their value hijacking or getting hijacked by constant parameters.
It's horrible, but it's better than nothing.
Since everything is based on the VALUE, even when named, you need to use unused values for your constants and set them to the desired constant value in the Formula field.
This way, the Quality parameter of 4 and Batch size exponent base of 2 can be adjusted at will without their value hijacking or getting hijacked by constant parameters.
It's horrible, but it's better than nothing.