Friday Facts #392 - Parametrised blueprints

[Tertius]

I already have a feature request: instantiating a parameterized blueprint into a regular blueprint so you can select options once and then place it a hundred times.

As far as I see it in the video, you first get the popup to enter the parameters. If you finished entering them, you have the finished blueprint in hand and can place it. My guess is that this is a regular volatile blueprint now, like the one you get if you copied but not yet pasted something. This is an item you're able to put into your inventory instead of placing it, and voilà, there you have your regular blueprint you can place a hundred times.

Or may be (and that would be my version of your feature request), the last placed parameterized blueprint is pushed onto the copy+paste stack and you could recall it with CTRL-V.

[Wenihal]

As a developer myself, I love this feature. Is it possible that parameters have a default value? I place a blueprint, if I like default values I just confirm and go, if not change parameters first.

[Xteec]

Great feature!

[ElderAxe]

I'm curious as to why you didn't end up allowing entire rich string parameters. It would seem like an obvious inclusion so that you could do the entire station name in a parameter. It's not a biggie by any stretch, but my station naming scheme usually includes the actual item's name in addition to the icon, so that I can easily find them with a quick text search.

Quick search feature works for icons as well.

[The_Mell]

Suggestion 1: included array of parameters

Instead of having to select manually parameters, why not 'automate' it by having a bunch stored in the blueprint and scroll through different setups similar to blueprint books' scroll function.
When i looked at the intro video, i expected a feature similar to the one of blueprint books but it stops like just a step before it...
#0 would be optional and be the manual selection, #1 could be iron plates for train unloading station, #2 copper plates, #3 coal, #4 stone, and so on.
Could be a list at top maybe where we also switch on the feature by adding additional use cases besides #0.

Pro:

• resambles a current features
• even quicker to use
• less risk for setup failure

Contra:

• another level to setup
• another level to be programmed by developers
• blue print format becomes even more complicated

Sugesstion 2: automatic generation of parametrised blueprints out of 2 (or more) blueprints

Modifying a blueprint is nice and fancy, at least a little bit, but don't we quite often build stuff, copy or blue print it, build it again and then change it?
Maybe it's just me but i prefer to work the 'real' stuff instead of inside a blueprint. (Probably a use case for 'power user' activation of parameters everywhere.)
This can easily create very similar blueprints which then could be merged into a parametrised blueprint.
There would be the need of a button in a blueprint to merge another one into it (and now i start to think that 'merge' might not be the best word for it). On a normal blueprint it would try to create a new parametrised one.
In combination with Suggestion 1 this would lead to one with both variants as stored parameters. On a parametrised one it would try to add new variant.
Of course, this idea has a quite some problems which are hidden in the word 'similar'...

Pro:

• easier creation of parametrised blueprints
• even quicker to use

Contra:

• 2 blueprints must be compared, recognised as similar, and mostly automatically resolved into one by programmed code
• restrictions of what a 'similar blueprint' is could lead to irritating user experience and problems
• automatic or manual problem resolution in case of differences

[picklock]

Another interesting FFF that introduces a great feature.
However, only time will tell to what extent I will use it in the future. I am also one of those who has a separate blueprint or even a separate blueprint book for each item.

[Neutronium]

It seems like conditional logic baked into it would help out a lot. We were discussing the implication of this feature with the quality mechanic, and how different qualities would be treated as the same parameter or not. For instance, you can have a checkbox on the BP parameter screen when placing it, and depending on whether that variable is true or not, you could have combinator-like logic flow which is quite powerful. This can allow these generic BPs to be even more versatile by letting people add what turns out being different configuration options.

This is taking the programmatic approach of this and taking it one step further. I hope this message was clear enough.

[Justderpingalong]

Looks great at face value... but I have my doubts.

1. In terms of using this for a constant combinator... I hardly see the point when we have Constant Combinator Groups already available? If anything, I'd like to be able to parameterise my constant combinator to use group X when I place it.

2. Speaking of combinators: Will parameterisation work with the new arithmatic combinators? I'm not sure how and why you'd ever use it... but I'm sure someone can figure that out.

3. The most common use case for this seems to be train-related but I am deeply missing a connection between this and the recently presented Train Groups. When pasting in a train, can I automatically assign it to a group?

4. Speaking of trains: I assume that we'll be able to set the fuel and the cargo wagon inventory filters via this new system? Because if you're paranoid and you desire to have all your train cargo filtered, it'd be real sweet if you could just parameterise your trains. (On the topic of this, rather than having to set filters on every slot, can we just set it once, and in the same GUI, specify how many slots we'd like to filter? That'd be real sweet).

Can't think of any other questions at the moment and it looks nice... but am wondering how useful this actually is.

[Sachertorte]

Noticed that kovarex is usng train stops prefixed with rich text icons. Me too! Wondering if this might be as good a time as any to suggest for 2.0 that the sort order of train stop names with icons in them be changed to match the sort order of that icon in the inventory, as opposed to being alphabetised by the icon's internal code? Suggestion thread for that (with a Lua implementation) here: viewtopic.php?f=6&t=97719

Parametrised blueprints look awesome, by the way. I can't wait.

My one critique is about the 'ingredient of' option. To me it feels a little too niche and perhaps overcomplicates the GUI for something that might not be used that often? I don't think it's too unrealistic to expect players to know what items they'll need for a given blueprint. What happens if an item has multiple recipes?

I think it also implies other options instead of 'ingredient of', which invite their own complications - off the top of my head I can think of

• barreled version of
• barreled version of ingredient of
• localised name of
• rich text icon of
• stack size of
• rocket weight of
• inventory size of (I'm thinking to set requester chests feeding into modded upgraded cargo wagons)

This is a feature "only just finished" so I imagine much of the GUI is subject to change, but as of right now I don't think it's clear how you add new parameters to a blueprint (do they automatically appear when you add the parameter network signals to stuff?), or how you change the type of a parameter between e.g. network signals and numbers as shown in some of the screenshots.

"you also can't set the train stop name by circuit network at the moment" - doesn't look like this FFF addresses this right now, but looking forward to seeing how it does! Maybe if you put a rich text icon for a parameter signal in the stop name?

But overall this looks seriously useful.

[AileTheAlien]

feature request: instantiating a parameterized blueprint into a regular blueprint so you can select options once and then place it a hundred times.

+3 for this one. The second video where the dev picks each parameter looks only slightly faster than just selecting those options on the non-blueprint buildings, and then just copy-pasting the settings to each building. Then multiply that by each copy of the blueprint you want. For example, if I need three different iron-stations at one sub-factory, then two more at another, I'm either re-entering the parameters, or using normal temporary blueprints to copy-paste things between locations, which defeats the purpose of the new feature.

feature request: being able to select between tiers, e.g. whether the blueprint should be built with yellow, red, or blue belts, and so on.

This one would also be pretty handy. I guess I could upgrade-planner my parameter-blueprints, but it'd be nice to just plug in related items / item-tiers like yellow/red/blue. Even better, would be if you could parameterize blueprint books, and then pass parameters from books into blueprints. For example, I copy the parameter-blueprints into three different blueprint books. One book is yellow belts and grey assemblers, one is red belts and blue assemblers, and the last is blue belts and yellow assemblers. Or maybe I parameterize the inserters and chests. Any new parameter blueprints inserted into these books could use those parameters from the books, or just normal parameters. Or I just have one book, and I update the book-parameters when I research each new tier.

[Dial-up]

Dependant parameters

the first thing I thought was that they finally added an explicit recipe dependency visualizer (aka helmod) to the game

[whaleberg]

I want this yesterday please.

[StansTheMan]

Amazing! So many opportunities to expand on it, just imagine the possibilities!

A: Define specific sub-items to choose from, depending on what is selected as the top item. Equip blueprints with their own elaborate forms to fill out before placing. You could define whole trees and sub-trees full of possibilities. Just imagine being able to select any complete AngelBob's ore processing chain from a blueprint, and only having to select the initial ore 1x when placing it.

B: Blueprints automatically set their own parameters when placed, depending on the conditions under which they are placed. Instead of choosing the stations yourself, you would just park the trains first, then pop the blueprint over them. The blueprint reads the contents of the wagons and selects the type of station itself. Or for example a single blueprint for a large elaborate mining setup that automatically picks up different settings for each ore, e.g. when building on uranium ore.

[aka13]

Very cool! Will there be a possibility for the said parameters to affect the tiling of the blueprint?
Let's say a blueprit for a solar field, or a railway, where I change a parameters, and the blueprint gets tiled?

[shmooooo]

FINALLY FINALLY FINALLY FINALLY FINALLY

BEST FEATURE EVER

[MEOWMI]

The only thing that confuses me at first glance is the "Value" and "Ingredient of" fields. It's not quite clear what they refer to, but I'm sure you could get used to it quickly.

[03noster]

Looks amazing. Now the only thing we need are basegame recursive blueprints!

[kajacx]

This is great! Setting up trait stops in "grid based" train bases has always been a pain, and this looks like it will (mostly) solve it. I say "mostly" because I don't see how you can set a train station color based on the item selected.

Also, it would be nice if you could use "item stack number" in train enable condition automatically, To enable the train stop when there is X stacks of items in a chest, for example. Items can stack to different amount, so 20 stacks of iron plates might be a different number than 20 stacks of copper wire. I just want to say "20 stacks of the item I am loading" and be done with it.

[Diablo]

Kinda feels like a solution looking for a problem really.

*Having one specific blueprint for each item, which sounds like a nightmare.
Hence BP Books...
and designing different builds is fun.

*This is nice, but whenever I build the blueprint I need to re-configure all the filtered inserters for the target item,
Once you setup a generic station with a constant combinator for the filter, it a matter of adjusting one signal in the combinator and your done.
(and may I add a lot faster then what you showed here)

*and also change the name of the stop, and it is tedious.
Sounds like you do not enjoy playing the game to me.

In my opinion the "tedious" stuff that happens while playing the game, is playing the game, it's what makes it (to me at least) such a relaxing experience.

With all these QoL upgrades, soon you will not even have to touch the keyboard or mouse, just boot up the game (simulation) and watch it go.
Don't get me wrong, there have been and surely will be lots of updates that were awesome (train bridges to name a recent one) and certainly have improved the gameplay experience.
This however doesn't feel like one.
It feels like a lot of extra steps to achieve something trivial.

[Stimpatch]

Wow.

I never understood why soccer fans cheer for their team on tv when no one is around.

Today, i clapped twice reading this blogpost.

Just... wow. Bravo!