Friday Facts #392 - Parametrised blueprints

[Terrahertz]

Very Nice!

I also like this sentence:

Use circuit network, but it feels like an overkill (more on that later), and you also can't set the train stop name by circuit network at the moment.

as the "at the moment" implies you can rename stations via circuit network in 2.0

One thing seems to be missing: Getting the amount of an ingredient.
There are 2 scenarios I can think of where this might come in handy:

• Drone based malls: to help configure the requester chests

• Configuring the train stop circuit network: For instance when building Processing Units, you might want to activate the appropriate trainstop when Red Circuits fall below 2000 and Green Curcuits fall below 20000

Also are there going to be more than 10 parameter placeholders? Just in case the blueprints might get a bit more complicated.

[hojava]

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. This should create a new blueprint that you could use and then discard, or you could place in your blueprint collection next to the still remaining parameterized blueprint. This could be extended further to allow the same for a whole blueprint book. If all the blueprints in the book have the same parameters, you could generate a new book with all the options pre-set.

Just build it once and use copy-paste. You can also quickly make a regular blueprint out of it if you want to.

[Hanakocz]

Now, we can build blueprint with script/command from blueprint item, will we be able to send parameters via this method too?

[ElderAxe]

Thank you for this feature. I'm happy that this becomes a part of the vanilla with 2.0. I will definitely use this on my blueprints. Their circuitry will be simplified and number of BPs will be reduced a lot

I have two questions about this feature;
- Is it possible to filter the choices. Use case: Only fluids can be able to be chosen for fluid unloading stations.
- Is it possible to have like stack size of Parameter #0 on Parameter #1's formula. Use case: Only enable station if there is enough space on the chests for full train of materials

https://mods.factorio.com/mod/blueprint-variables this mod provides parameterization on blueprints right now. But since i share my blueprints, everyone that wants to use parameterized blueprints needs to have this mod installed as well and that makes it unusable for my case.


I'm one of those guys that create different blueprints for each product.

Screenshot 2024-01-05 153739.png (176 KiB) Viewed 4380 times

[koliw_br]

An interesting thing: these new symbols at the bottom of the signals tab. Maybe there will be something about it in the next FFF?

[Tooster]

A really nice feature! I have one feature request though to help with UX:

Instead of a fixed number of signals from 0-9 I would recommend a tag/name based system. I envision that the system you presented would quickly run into a bottleneck of insufficient number of parameters, for beginners and advanced players alike. I can already see "add more than 10 different parameters" requests on the forum. Generally I am in favor of "limiting player's options as a form of a puzzle", but I don't think this is the appropriate place for that — this looks like a QoL feature which should be highly flexible and cater to both really simple builds as well as advanced megabases.

A tag/name based system would instead work similarly to a train stop name system or your new "train schedule" system — parameters would be discerned by name and you could always either introduce new parameter (like you introduce a new train station name) or reuse an existing one using a dropdown (in the context of one blueprint of course, the names wouldn't be shared among different parametrized blueprints). This way you could both allow for creation of more complicated parametrized blueprints as well as improve UX by saving some space in the UI — there would be no need for separate `name`, `variable` and `signal` fields — parameters would be uniquely identified by a string value of a `parameter` (current `name`) text field alone. Any additional info could be included in a collapsible section/popup `comment` box.

The potential problem with 10 parameters is even more evident to me when I look at the "Ingredient #1/#2 of" rows for each ingredient. I think we could quickly run out of parameters if the number of parameters is fixed to 0-9 and instead of fun it could be frustrating instead. The wording "Name: N, Value X ingredient of Y" is also a bit off to me, I had to stop and try to what exactly does it mean and what different inputs do to parameters, but it is still complicated. Doing something like `param1.ingredients[0]` could be easier instead (a bit lower I write about "functionality" select box which could be better), because it wouldn't have to be explicitly defined as a parameter. Reading `Name: N Value:100 Parameter: [x] Variable: X [x] Formula: ...` is also a bit confusing and different combinations of those inputs make it a bit cluttered.

What's more, the tag based system could be more UX friendly than a signal one: instead of thinking "what is the parameter no#4 bound to" and decoding each parameter in your brain, keeping track of which is which, making sure you didn't use the wrong number somewhere is certainly harder than simply using "production output", well named variable — you could simply read the name of a parameter. Additionally, when a parameter is identified by the name, then there is no need for a separate "variable" field (which also reads a bit backwards — first a value and the name second?).

I'm a developer and the current 0-9 based system really reminds me of a tedious excercises with the RAM machine (or asm), where you had to remember what each register does etc. Maybe a fun puzzle for circuits, but a pretty tedious job for a QoL feature. I'm pretty sure now, that simple variable-like declarations could be much friendlier: `name: product` input would define a property named "product". Maybe it could be enhanced even further: a select box with predefined functionalities for deriving parameter value: "input" to mark parameter as configurable, "ingredients" would return ingredients array/nth ingredient, "stack size" would return stack size of a selected item and considering your addition of "weights" in the space age, "weight" returning the weight of an item and finally "formula/derived" would show a formula box. Basically, it would be nice to have access to item metadata inside derived parameters (and maybe an API to extend the list of functions in mods).

I also think that there shouldn't be a checkbox next to each and every parameter — this makes them scattered all over the place. Possibly a single "inputs" section up the top (similar to signal groups/sections), that would clearly indicate what parameters are for configuration and which parameters are derived or a previously mentioned "parameter type" selection box. This way the UI could be simplified by avoiding "formula" checkbox and others. A good indication that the UI still requires some work is on the image below. If "7" doesn't have a name, isn't assigned to a parameter signal, is not exposed as a parameter and is not derived, then what even is it and why is it present in this list?



I think there is yet a better way to present it and refactor it a bit and I hope that the current "signal based" parameters won't be the final version of it. I understand that it was just finished and is not yet polished, so I'll be waiting in anticipation for the final shape of it.

Nevertheless — great work!

[Shingen]

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. This should create a new blueprint that you could use and then discard, or you could place in your blueprint collection next to the still remaining parameterized blueprint. This could be extended further to allow the same for a whole blueprint book. If all the blueprints in the book have the same parameters, you could generate a new book with all the options pre-set.

Just build it once and use copy-paste. You can also quickly make a regular blueprint out of it if you want to.

copy-pasting doesn't copy trains, and making a regular blueprint after placing the parametrized one may be unnecessarily troublesome if you have other entities in the area (that actually applies to copy-pasting as well).
if it's not hard to add, i believe it would be a nice option to have.

[pleegwat]

One thing seems to be missing: Getting the amount of an ingredient.

And stack size. And number of items per rocket.

[OfficerSalzig]

I hope we can insert the parameters into train stop names within blueprints, so if we configure an iron plate train stop, we only have to change one parameter to iron plates and the train stop name will include the iron plate emoji

[Acacel]

I like the new blueprint, especially with the new train system it saves a lot of time.
Again very good work, i hope we can test all this new things soon.

[ElderAxe]

I hope we can insert the parameters into train stop names within blueprints, so if we configure an iron plate train stop, we only have to change one parameter to iron plates and the train stop name will include the iron plate emoji

They said it is possible when reconfiguring. So I believe it will be possible when setting up a new blueprint as well. I think you need to enable parameter signals to be active in the world from settings and use that signal while naming your station.

Practically every setting and number you can have in an entity can be reconfigured by this feature. Inserter filters, assembler recipes, circuit network settings, combinator configuration, logistic requests, inventory filters, even rich text icons.
The last one can be used to change the name of the train stop, as long as you make a rich text part of it.

[morsk]

copy-pasting doesn't copy trains, and making a regular blueprint after placing the parametrized one may be unnecessarily troublesome if you have other entities in the area (that actually applies to copy-pasting as well).
if it's not hard to add, i believe it would be a nice option to have.

If you hold Shift while releasing the copy-paste selection, it brings up the UI and lets you include trains. This is the main way I make trains.

I wouldn't say no to this "instantiation" feature though.

[TheKid0z]

I really think this feature can be extended to circuits as well. Like change the recipe of the assembler with circuits. The code is already here now just have to port it to outside of blueprints. Don’t hold back Wube!

[Upserter]

I really appreciate the effort that goes into improving the game experience for power users. I hate to come across negative, but part of me does feel that this goes too far, while also not going far enough. Something about it reminds me of "low code / no code" tools, or perhaps GUI query builders like you might find in SAP BusinessObjects. They look great at first, and they get the job done for many, but in my experience they have a couple of unfortunate failure modes:

1) They aren't quite powerful/complex enough and users get frustrated by their limitations. In the case of parameterised blueprints, there are all kinds of extra features you could imagine a player wanting: maybe to put an if-statement into the variable definition somewhere, or to set the belt tier using a parameter, or to hide/show elements depending on a parameter value, or to use a math expression that you hadn't anticipated. Once you give users a sniff of this kind of configurability, they will inevitably yearn for more. The programming analogy that comes to mind is the C preprocessor - initially just a simple, optional parameter substitution facility. But it was quickly expanded to be nearly Turing-complete in its own right.

2) They are so complex that they are tantamount to doing real programming, but without the support of real programming tools, and real programming would actually be easier. This is where Enterprisey tools often end up. I've seen some horrific "no code" applications that would have been dramatically simpler if a few lines of Python had been allowed.

Maybe you'll manage to find a balance that works for Factorio, but I can't help wonder if you should just bite the bullet and give us a Lua Combinator. Not in a cheaty sense - just give the player programmatic access to defining blueprints. Take input values from the circuit network. Modify a blueprint object using Lua code, or define one from scratch. Keep the parameter-supplying GUI that you've built here, but allow the player to embed Lua code into the blueprint which does all the work of deriving values and handling dependencies - and more. Output a blueprint item. Insert it into a roboport to have bots build it at a specified location.

[firestar246]

Oh... my... goodness! Was just thinking about how something like this could be useful. I CANNOT WAIT for the release!

[quyxkh]

I like it, I've had this hankering for a "fusable constants" combinator, just like a constant combinator but with a special condition you can set, if that condition ever matches the combinator latches its inputs and becomes a constant combinator with those values forever more. Here's one use for that.

It occurs to me you could do this with these parameterizable blueprints if you make it possible to use blueprint overlap to supply values, pin or default parameters to signals or recipes or other settings in existing, already-placed blueprint components. Then extending a production line could be a blueprint with a repeated section, the second section's settings including values parameterized on / calculated from the first. So copy-settings, add 1 to X.

[MrGuffels]

Biggest thing I am curious about is what does this look like when you are importing an entire base from a blueprint but only need to change one thing. (Like having to change all the Tier 2 Prod and Speed Mods in this (https://factorioprints.com/view/-N1-ekMYWx_pPmZepQep) to tier 1s)

[StormTAG]

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.

Incidentally, bravo to whomever implemented the text search. The partial matching makes finding what I need a breeze as, even with giant modded item lists, I can usually find what I want within a few keystrokes.

[AntiElitz]

This sounds really cool! Will you be able to get input parameters be set from an external source or condition of the Factory? like from a roboport network?

[astroshak]

Sounds cool, I guess? Not really sure how much I will make use of it. Will have to see when 2.0 comes!