Please add a button to add a new blueprint parameter variable

[Theikkru]

[...]
every formula have a "value" parameter variable reference to it self.
[...]

Coincidentally, I proposed implementing numerical parameter variables for a different reason, and realized on reading this that the same implementation could cover both use cases.

[Firestorm253]

yes pls. since we can use formulas, it's annoying that every parameter needs to exist inside a physical object. if u just want an input parameter or an intermediate of some sort, that can't be done currently.

[Geigeabc]

+1
We had the same problem, and having to add variables by adding trash items in requester chests, that you then replace in the blueprint, felt very hacky and unclean.

[PssX]

Yes, please!

I like addition of parameterized blueprints very much. But some things like 117000 and this one make me concern about direction where it is going.

[Novalith]

Throwing my hat in. I don't care if you don't, but would use the hell out of it if you do.

[ctrom]

+1 on this suggestion. I found this thread after struggling to implement the logic I wanted in a blueprint. As a work around, I have been using the approach of:

1. Adding a constant combinator to my design
2. Setting a value in it (but making sure that the value doesn't collide with another to avoid the problem mentioned in 117000)
3. Using that value as the additional parameter I needed while setting up the blueprint
4. Deleting the constant combinator from the blueprint

Which (using my standard method of setting a constant combinator) amounts to 4 key presses and 8 mouse clicks across 4 different dialogs in order to perform an action that could be a single click in the existing "Blueprint parametrisation" dialog.

Blueprint parametrisation really is a great feature, but it seems to lack some seemingly basic functionality.

[Hares]

<...> As a work around, I have been using the approach of:

1. Adding a constant combinator to my design
2. Setting a value in it (but making sure that the value doesn't collide with another to avoid the problem mentioned in 117000)
3. Using that value as the additional parameter I needed while setting up the blueprint
4. Deleting the constant combinator from the blueprint

Wait a second, if you remove constant comb from the BP its parameters will also be gone, I remember this being a thing, isn't it?

[CheeseMcBurger]

+1

[Firestorm253]

<...> As a work around, I have been using the approach of:

1. Adding a constant combinator to my design
2. Setting a value in it (but making sure that the value doesn't collide with another to avoid the problem mentioned in 117000)
3. Using that value as the additional parameter I needed while setting up the blueprint
4. Deleting the constant combinator from the blueprint

Wait a second, if you remove constant comb from the BP its parameters will also be gone, I remember this being a thing, isn't it?

ye no, this doesn't work.

[ctrom]

ye no, this doesn't work.

I was pretty sure that it did, but it seems I ran afoul of the issue in 117000 again. Apparently, leaving a value (as a default) in the parameters that is equal to the value of another parameter that has a defined formula will still silently combine the parameters, even though the formula would seem to make them unique from each other. It happened that in my testing the value I provided to the parameter produced a sane output when I built the blueprint, so I didn't realize it had replaced my extra parameter with what was supposed to be a computed (parameterized with formula) value on a logistics chest.

Thanks for prompting me to examine this more closely. I've come up with an alternative method for my use case that does not require the combinator, but is much more of a kludge than I would like. This blueprint adds an undesired request to a requestor chest that was already in the design, but I've set it to an item that I wouldn't expect to ever be available in my logistics network (wooden chest). Even though this kludge does circumvent the issue, it still seems like a design oversight that parameters cannot be added to allow user input to a blueprint that aren't directly tied to some other element in the blueprint.

Code: Select all

0eNrFlk1vm0AQhv+KtccKUvOxxEbqofceqvZYRdYCY2dUWMguOHEj/ntnAWMCxKndg+WDl2HmnWd3Z0a8siitoFAoSxa+MoxzqVn465Vp3EmRGlt5KICFTOgSVI6JHT9W8jezmBSZsRdC0YLe2UtWWwxlAi8sdGprqNH5Cq0hi1KUOzsT8SNKsN1BkFs/WAxkiSVCS9E8HDayyiJQpNpnVfBUgSEiHPonnCLXFJdLk84ArO7vuMUOtOL+HackXchmiynFaeOnITYhba4jucV6jzfWyX4dyvpUiZQIyS5zldFmLRbnmfEpcwJmXxpDZU7XWZozOW51Rs+9UM8Z6Hkzet6Feu5Az5/R8y/U8wZ6fEaPX6jnD/SCXu85zxOQfRlcIMjrB/oZ0VGZnS4HpQZFrOfri1N9zcgM70Rr3INdqHyPybmiXY2KNhKqa6aRuP9PjKs3jBZLULUlz8LVjOjplmY79ewh3HdNFmMxHgtH82ZyOabhe8+24bpxg8lpxPxoRS1jHCt3kjYNrqRH+7gImvvqUnW7t46LkPFT7p9VUaSHRValJRYpNn57oVBEqXlNdjaQaqhHlM5/UJrRuFOQIF2UnW8n4/bMHhxzOlsSrlJh4pYbdD4ZXKoCKIDayPRAqSr4gN+9Eb8z4Xev4vduxO9O+L2r+P0b8XsTfv8qfn4jfn/Cz9/hpyGEJWTkdfoYslgqIqCPF/b9mBH/QLL4lu9Qlxjrxdd2RIJaPH+Gl1KJRc9mZgTNs2afPHDX/nrN/SAI/HVQ138Bxr4ggw==

[WarmCat]

I also would like to see this problem resolved.
I've spent hours trying to create mall-assemblers using parameterisation, but it is currently not possible within game due to being unable to add to the parameterisation list.
I tried using the hack of adding a constant combinator, but as soon as this combinator is removed from the blueprint, then the entries are removed from the list.
Waste of time.

[fazol]

I'm in, +1