Friday Facts #392 - Parametrised blueprints

Regular reports on Factorio development.
Terrahertz
Fast Inserter
Fast Inserter
Posts: 128
Joined: Mon May 15, 2017 7:49 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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 :D

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.
Last edited by Terrahertz on Fri Jan 05, 2024 12:53 pm, edited 1 time in total.

hojava
Burner Inserter
Burner Inserter
Posts: 11
Joined: Tue Feb 26, 2019 11:32 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by hojava »

lonjil wrote:
Fri Jan 05, 2024 12:12 pm
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
Inserter
Inserter
Posts: 40
Joined: Sun Jun 24, 2018 7:06 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by Hanakocz »

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

ElderAxe
Fast Inserter
Fast Inserter
Posts: 135
Joined: Thu May 18, 2017 8:04 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Screenshot 2024-01-05 153739.png (176 KiB) Viewed 4055 times

User avatar
koliw_br
Burner Inserter
Burner Inserter
Posts: 10
Joined: Fri Nov 11, 2022 9:38 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by koliw_br »

Image
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
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Mar 24, 2021 6:42 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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?

Image

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!
Last edited by Tooster on Fri Jan 05, 2024 1:44 pm, edited 6 times in total.
Look mom, I made a mod ^^ Barrel Stages

User avatar
Shingen
Long Handed Inserter
Long Handed Inserter
Posts: 92
Joined: Fri Jan 04, 2019 3:25 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by Shingen »

hojava wrote:
Fri Jan 05, 2024 12:40 pm
lonjil wrote:
Fri Jan 05, 2024 12:12 pm
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
Filter Inserter
Filter Inserter
Posts: 275
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by pleegwat »

Terrahertz wrote:
Fri Jan 05, 2024 12:39 pm
One thing seems to be missing: Getting the amount of an ingredient.
And stack size. And number of items per rocket.

OfficerSalzig
Manual Inserter
Manual Inserter
Posts: 2
Joined: Thu Aug 24, 2017 4:23 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Inserter
Inserter
Posts: 26
Joined: Thu Apr 27, 2017 10:10 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Fast Inserter
Fast Inserter
Posts: 135
Joined: Thu May 18, 2017 8:04 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by ElderAxe »

OfficerSalzig wrote:
Fri Jan 05, 2024 1:07 pm
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.

User avatar
morsk
Fast Inserter
Fast Inserter
Posts: 133
Joined: Fri Dec 15, 2017 1:00 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by morsk »

Shingen wrote:
Fri Jan 05, 2024 12:51 pm
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.

User avatar
TheKid0z
Burner Inserter
Burner Inserter
Posts: 7
Joined: Mon Jul 22, 2019 1:46 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Inserter
Inserter
Posts: 34
Joined: Fri Oct 06, 2023 8:33 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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.

User avatar
firestar246
Inserter
Inserter
Posts: 29
Joined: Sun Feb 19, 2017 11:25 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by firestar246 »

Oh... my... goodness! Was just thinking about how something like this could be useful. I CANNOT WAIT for the release!
For by grace are ye saved through faith, and that not of yourselves: it is the gift of God: Not of works, lest any man should boast. For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord.

quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Burner Inserter
Burner Inserter
Posts: 12
Joined: Sun Mar 05, 2017 7:47 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Long Handed Inserter
Long Handed Inserter
Posts: 66
Joined: Wed Feb 10, 2016 12:40 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Filter Inserter
Filter Inserter
Posts: 451
Joined: Sat Aug 29, 2015 11:37 pm
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by 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
Filter Inserter
Filter Inserter
Posts: 614
Joined: Thu May 10, 2018 9:59 am
Contact:

Re: Friday Facts #392 - Parametrised blueprints

Post by astroshak »

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

Post Reply

Return to “News”