Improvements for parameterized blueprints
Posted: Wed Nov 05, 2025 8:01 pm
TL;DR
This is a bit of a collection of ideas for improving parameterized blueprints, sorry. Each is a very simple idea so I didn't split them into separate issues.- Virtual parameters
What?
Allow creating virtual parameters (variables) that aren't present in the blueprint already so the user can add variables for formulas.
Why?
I can create a blueprint where I select an item and a multiplier and the arithmetic combinator gets a value according to a formula:
- bp-virtual-parameter.png (690.01 KiB) Viewed 175 times
Select an item, adjust the multiplier as needed and the threshold of the arithmetic combinator gets set automatically.- bp-virtual-parameter2.png (172.42 KiB) Viewed 175 times
But for this to work I need an entity (the constant combinator) that has a parameter with a value that I can turn into a variable. The constant combinator is completely useless in the finished blueprint. Luckily it can be removed after parameterization without loosing the parameter. But why do I need to go through this? Why not simply allow adding a new parameter that I can use in formulas? - Allow splitting parameters
What?
Allow splitting parameters that are used multiple times into instances of fewer use cases. It should probably be possible to select a subset of instances to be split off so for example a set of 10 use cases can be split into 3 and 7 use cases.
Why?
I have a arithmetic combinator that outputs 1 and also a constant combinator that generates a 1 signal. I want to turn the constant combinator signal into a parameter but leave the arithmetic combinator output alone. As is when place the blueprint and change the multiplier the output for the arithmetic combinator gets changed, which is not desired.- bp-split-parameter.png (622.98 KiB) Viewed 175 times
So the parameter needs to be split so the use case in the arithmetic combinator is distince from the use case in the constant combinator.
As is everything must be given an unique value before making the blueprint so the parameters don't get joined and then all the values have to be adjusted to the desired default values. - Add parameter type for train stations and interrupts
What?
Allow selecting train stations from the list of existing train stations and interrupt names from the list of existing interrupts.
Why?
I have blueprints for trains that I can place in a refueling station. The train then gets build and fueled and once fueling has finished the train drives to it's base station automatically. For this the blueprint has a preset schedule with the base station for the train.
- bp-train1.png (51.12 KiB) Viewed 175 times
- bp-train-2.png (101.07 KiB) Viewed 175 times
- bp-train-3.png (1.3 MiB) Viewed 175 times
By naming the station [item=parameter-0] the station becomes a parameter in the blueprint and when placing the blueprint the name can be selected from the available items, fluids and in some cases recipes. So provided I name all my stations using icons I can select what station a blueprinted train goes to.- bp-train-4.png (50.53 KiB) Viewed 175 times
But this limits my freedom to give good names to stations. Realistically I have to use "Smelt [item=parameter-0][item=parameter-1]" so I can have stations "Smelt Iron 1", "Smelt Iron 2", "Smelt Iron 3", ... in icon form as the base station name has to be unique for me.
The same works for interrupts so I can select what items a train shall fetch or deliver for cases where this isn't circuit controlled. Same caveat applies that icon names have to be used in the interrupt name.
It would be much nicer if stations and interrupts could be parameterized without resorting to naming them [item=parameter-0] and the parameter could be selected from the list of stations or interrupts when placing it. - Parameterize entities
What?
It should be possible to parameterize entities so they become selectable on placement. By that I means that belts should be selectable from yellow, red, blue, green belts. Inserters should be selectable from yellow, blue, green, ... Assemblers should be selectable from grey, blue, yellow. And so on. The upgrade planer already has the needed logic to produce a list of possible entities to replace a give entity.
When placing a blueprint the parameterized entities should default to the entities used in the blueprint but get downgraded to availble entities if unavailable. So a blueprint with stack inserters placed early in the game would default to yellow or blue inserters.
Why?
Say I build a train station like this:
It would be nice if I could select blue inserter to replace all the yellow inserter for stations that need more throughput without having to create a second blueprint. Similar the wooden chests might need to become iron or steel chests. Again currently I require 3 blueprints for this to select the chest type. And this is multiplicative. So I have 12 station blueprints now: 3 chests types * 4 inserter types. Parameterized entities would combine them all into a single blueprint.- bp-entity.png (970.23 KiB) Viewed 175 times
viewtopic.php?t=119813 - Container size as new variable for formulas
What?
This extends on the previous point but not necessarily so. It should be possible to use the container size (chest, cargo wagon, fluid tank, fluid wagon, ...) of a parameter in formulas. In the above example of a train station the arithmetic combinator would use a formula that uses the chest size and possibly the cargo wagon size to set the correct threshold.
Why?
For any type of buffering logic the size of the container becomes important. So I would like to have blueprints that have a parameter for the container used, their count and then set values based on the container size * count via formulas. The container parameter can be created using a constant combinator emitting for example a wooden chest signal. So this idea doesn't require the previous one but they would synergize nicely.
Along the same lines other useful variables would be crafting speed, belt speed and recipe time, - Remember defaults when placing a blueprint multiple times
What?
When a paramerterized blueprint is placed again and again use the parameters choices from the previous placement as default for the next.
Why?
I often have blueprints that represent a tilable unit of a factory. When building the factory multiple copies of the blueprint are placed side by side to get the required throughput. But everytime I place the blueprint the parameter mask pops up like this:
So I have to select the same item type over and over. It would be nicer if the blueprint would remember the last choices as default for the next time as long as it is kept in hand. Once the blueprint is put back it forgets everything and reverts to its normal defaults.- bp-virtual-parameter2.png (172.42 KiB) Viewed 175 times
A modifier key for repeating a parameterize blueprint completely without questions would be nice. Both ctrl and shift are already used but could Alt be used for this?
Placing a blueprint with Alt would use the last choices or defaults without popup if possible. - Figure out parameters from existing structures when placing blueprint over existing placement
What?
When placing a blueprint over existing buildings the code should check if any entity with parameters matches the existing entities and if so use the existing entities values to set defaults for the parameters. For example an assembler where the recipe is a parameter placed over an assembler that is set to produce iron gear wheels would default to iron gear wheels in the parameter mask.
Why?
When changing something in a blueprint the blueprint has to be placed everywhere it was used to propagate the change to everywhere. But every time it is placed all the parameters have to be selected again and again and it is unlikely to be any different from the last placement. Most likely only some inserter was added or a missing wire or the formula for some combinator was changed. It could usually all be figured out from the existing entities making updating the base so much simpler.