Option to split values in parameterised blueprints

[danijel1023]

Add an option to group/split parameters' values in PB.

I want to provide default values that user might want to change but if they're the same value, they will automatically get grouped into a single parameter.

Eg.
param 1: "Number of wagons", value: 4
param 2: "Number of chests per wagon", value: 4
This doesn't work as the second param is ignored since it gets automatically grouped with the first one.

[Lilly]

I ran into this as well. As a work around, you could set some other parameters to some other placeholder value. However, that value then also becomes the default when placing. Allowing us to set a default value might be easier to implement than an option to split the values.

[omron]

Hi,

This has been brought up in a huge amount different posts:
- bug reports, marked won't fix: 117000
- feature requests:
viewtopic.php?p=674863
viewtopic.php?p=674849
viewtopic.php?p=674029
viewtopic.php?p=671752
viewtopic.php?p=669468
viewtopic.php?p=667997

So clearly, many people feel strongly about the usefulness of default values in blueprints, and would like to have that feature be consistent with itself by not merging parameters which are meant to be separate.

Kovarex's response in the bug report above

Hello.
This was a design [choice], and I prefer it to stay this way.
The id parameters are also all merged into one place for a good reason, to be able to change them all at once.
With numbers, it would get all clunky and complicated having to somehow identify where the number came from and work with it separately, especially when you would have to have a tools to merge and unmerge them (as sometimes you want them merged).

For that reason, I would leave it as it is, and if you want to differentiate the numbers in the parametrized blueprints, you just have to give separate numbers, which is always possible.

I kind of agree with his response and the current implementation- that is, to assume all identical values are the same parameter and to merge them, they are "deduplicated". I would not want to manually change 400 splitters' filters, when one parameter for them all would do, and I imagine most players feel the same.

I think where the current solution falls short is that even named parameters are not treated as "unmergeable" in the bowels of this deduplication algorithm, which leads to things like people having a named train limit parameter being merged with some other parameter, which not only takes away control from the player placing the blueprint on the default parameters, but could in fact completely break certain blueprints.

One solution, as many have pointed out, is to to use unique "dummy values", like 1000, 1001, 1002... to prevent the merging of certain components in blueprint parameters, but in that case the default values themselves are worthless, and the player will have to manually most if not all parameters for a blueprint each time they want to place it, or make static copies of a template blueprint. And so this is clearly not acceptable as a solution.


One possible solution, that I feel would take a smaller amount of work than a full overhaul:
- As far as I know, this deduplication happens before the player ever sees the blueprint; which means that players cannot mark which parameters should remain unmerged until they have already been merged.
- Implement a change so that parameters (those with the check box marked) will not be merged. In combination with placing dummy values before turning a build into a blueprint, one could ensure that certain variables would not be merged under any condition. Once marked, they could be freely changed to any value (even the same value), without becoming the same parameter).

Pros:
- Value of default parameters is preserved
- Doesn't break blueprints
- Still favors the "assume identical" approach, simplifying blueprint storage and initial workload
- We already have a parameter checkbox, so there is no extra GUI work!

Cons:
- Player has to do more upfront work in placing dummy values to prevent a merge before they can mark things as parameters. This is somewhat unintuitive, but not impossible.

I do not feel that this is an ideal solution; but I would like to see this issue fixed in some capacity. The parameter system, which is such an awesome addition to the game, is nearly ruined if defaults and parameters are not respected.