Friday Facts #392 - Parametrised blueprints

[GottZ]

so.. I still need dozen of blueprints for individual items, to create train stops and the actual trains. that's a bit sad.
the parametric stuff is awesome. don't get me wrong there.. it's just only delivering 80% of what is required for trains to work.

It's especially funny, since the blog shows train station blueprints, but doesn't allow setting train station names.
I also noticed I can't set train station color within the parameters, and since it can't be set via circuit network either, this really feels like a 80% solution that was too hard to finish to 100%.

In essence, this makes me want to build a blueprint book via Lua instead of using the UI for parameters.

[SirSmuggler]

but doesn't allow setting train station names.

Mabye you can't sett the text-part of the name i BP-parameters, but you can sett the icon-part of a station name as a parameter. I have done this my self. I've got an generic ore-station BP and the train station gets the apropriate ore-icon from a parameter.

[GottZ]

Mabye you can't sett the text-part of the name i BP-parameters, but you can sett the icon-part of a station name as a parameter. I have done this my self. I've got an generic ore-station BP and the train station gets the apropriate ore-icon from a parameter.

oh you are right!

11-07-2024, 15-16-14.png (16.86 KiB) Viewed 3210 times

the train name is changed too, even though it's not listed!
that's a bug I guess.

[TheDeadFerryman]

Hi!
First I'd like to say that this feature is huge. I mean, HUGE.
I had an experience playing Bobs+Angels a while ago. I decided to go with modular train-oriented base (basically City Blocks) with trains orchestrated by LTN.
And I was really dried up fiddling with combinator settings for each and every new station, and then trying to catch errors due to some value set slightly incorrectly on one of the stations.
Now with this it would be much less irritating (not to mention that with new train features you wouldn't need LTN at all in most cases).

However, there is one feature I feel missing - detached intermediate variables. I mean, there's no way now to declare a variable that wouldn't be physically present in the blueprint (like in one of combinators). I'm currently building a modular rail station system and I need to squeeze in a constant combinator to hold these variables
that I only use in formulas. E.g. I need train length (wagon-wise) and wagon slots count as inputs, which I then use in a formula to specify the total train capacity.
These input values are not supposed to show up in any of the result combinators, but there's no way to do that. I tried to configure everything first in a constant combinator then delete it from the blueprint, but this also deletes the variables.
It's not like it is a big deal to have a constant combinator that does nothing once built in the world, it just feels... ugly

[Seppl1]

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.

I cannot stress enough how true this is!

that I only use in formulas. E.g. I need train length (wagon-wise) and wagon slots count as inputs, which I then use in a formula to specify the total train capacity.
These input values are not supposed to show up in any of the result combinators, but there's no way to do that. I tried to configure everything first in a constant combinator then delete it from the blueprint, but this also deletes the variables.
It's not like it is a big deal to have a constant combinator that does nothing once built in the world, it just feels... ugly

Even accepting that there is an extraneous constant combinator, it's extremely tedious to set it up. You need to stuff it with signals that you can later use as variables. Single-letter variable names. "Did I use 'S' for 'Storage capacity', or 'C' for 'storage Capacity' here? What was 'W' again? Ok, use 'T' as 'Threshold'. Wait, I need an upper and lower threshold." And then you look at the parametrization GUI and still get confused by a list of meaningless letters and numbers.
You can give things longer names in the parametrization GUI, but you need to set up all signals before you get to that point, because you can't modify the contents of the blueprint (at least not in a useful way) once you create it. You've spent 10 minutes faffing about with the formulas and you realize that you forgot a variable? Or even just that something would be easier to think about if you extracted it out into a separate variable? Well tough luck, because now you need to throw away all of the work you already did, create a new blueprint (or select new contents for the existing one, which also deletes all of the parametrization) and start over.

I hope I don't come off as too negative. Parametrization already saves a ton of time, and I'm happy that it exists.
I'm just stuck in this frustrating middle-ground where I want to use the time saving for something but I don't want to go through the tedium of setting it up.

[Seppl1]

I'm chewing my way through building a modified version of the popular AutoRail pickup and dropoff stations, and this is what irks me:

I've created a text document that lists various... things that are used in the blueprint. And it took a lot of restructuring to even write a well-structured document for this, because conceptualizing how things form logical units in this system is not easy. I dunno, I just grouped things approximately by what I would consider variable names:

Code: Select all

Item
    Parameter Item = Iron Plate

WagonCount
    Item = T
    Parameter Value = 2
OverrideBatchItemCount
    ' If non-zero, then use this, otherwise calculate from WagonCount
    Item = O
    Parameter Value = 0

WagonItemCapacity
    Item = W
    Formula = 40 * WagonCount * p0_s
    Value = 101
BufferItemCapacity
    Item = B
    Formula = 96 * 3 * WagonCount * p0_s
    Value = 102
BatchItemCount
    Item = M
    ' If(OverrideBatchItemCount <> 0, OverrideBatchItemCount, WagonItemCapacity)
    Formula = sign(abs(OverrideBatchItemCount)) * OverrideBatchItemCount + (1 - sign(abs(OverrideBatchItemCount))) * WagonItemCapacity
    Value = 103
UpperThreshold
    Item = ^
    Formula = BufferItemCapacity - WagonItemCapacity
    Value = 104
LowerThreshold
    Item = v
    Formula = UpperThreshold - BatchItemCount
    Value = 105
Priority
    Item = Blue
    Value = 280

Dynamically calculated:
    Blue = -300 * Value(Item) / LowerThreshold

TrainStation.Enable = Value(Item) < LowerThreshold
TrainStation.Priority = Priority  

The ordering of items in the parametrization dialog that don't have the "Parameter" checkbox checked is not retained, so sorting things by how they make sense to yourself is pointless.

What is the difference between the upper and lower row of parameter items, aside from the former having a stack size and rocket capacity?

Signals and their values become detached from each other in the parametrization dialog, making it even harder to track which item corresponds to which thing.

Typing formulas in the "Formula" text box is like trying to assemble an IKEA shelf while looking through a toilet paper tube (because it's tiny; it can fit 9 digits and there are no scroll bars). The "Variable" text boxes are even smaller (4 to 5 characters).

How can I quickly find out what functions (and other constructs, because I need a ternary operator / inline if) I can use in formulas? It might be in the Tips and Tricks, but I'd have to close-
JESUS CHRIST! I just clicked outside the parametrization dialog because I wanted to click on the Tips and Tricks icon in the top right corner, and it closed without saving my changes and without asking for confirmation!
Anyways, it's not there. I looked at the original blueprint (that is, I copied the formula out of the textbox and pasted it in an editor) and it uses a mathy trick as a workaround to there not being a ternary operator: "want * sign(want) + (p0_s * 40 * wag) * (1 - sign(want))"
Also see viewtopic.php?t=118100
(I did find https://lua-api.factorio.com/latest/con ... ssion.html since then, but having this information handy in-game would be nice.)

Ok, I parametrized everything as needed. Test it, aaaaand.... of course I forgot to change a decider's input signal. Well. Time to redo everything again.
Oh! Positive surprise! If you only change signals, the parametrization isn't thrown away! That's good!


Ok, on to the pickup station:

Code: Select all

Item
    Parameter Item = Iron Plate

WagonCount
    Item = T
    Parameter Value = 2
OverrideBatchItemCount
    ' If non-zero, then use this, otherwise calculate from WagonCount
    Item = O
    Parameter Value = 0

WagonItemCapacity
    Item = W
    Formula = 40 * WagonCount * p0_s
    Value = 101
BufferItemCapacity
    Item = ^
    Formula = 96 * 3 * WagonCount * p0_s
    Value = 102
BatchItemCount
    Item = v
    ' If(OverrideBatchItemCount <> 0, OverrideBatchItemCount, WagonItemCapacity)
    Formula = sign(abs(OverrideBatchItemCount)) * OverrideBatchItemCount + (1 - sign(abs(OverrideBatchItemCount))) * WagonItemCapacity
    Value = 103
PriorityRange
    Item = R
    Formula = BufferItemCapacity - BatchItemCount
    Value = 104
Priority
    Item = Blue
    Formula = -(255 * BatchItemCount + 25 * BufferItemCapacity) / PriorityRange
    Value = 105

Dynamically calculated:
    Blue = (255 + 25) * Value(Item) / PriorityRange

TrainStation.Enable = Value(Item) > LowerThreshold
TrainStation.Priority = Priority  

I used a decider that tests for something > 0. I didn't keep in mind that this zero is lobbed together with the zero for OverrideBatchItemCount (which I luckily spotted because I happened to use that for testing). So I had to make a correction to the blueprint.
I pasted the blueprint and hit E to cancel the parameter replacement. I changed the zero in the decider to 106 and replaced the blueprint contents. Then I opened the parametrization dialog and saw that some of the formula text boxes were showing errors. "Unknown variable 'p0_s'". And sure enough, the "Item" parameter got reset. (The other parameters are still there.)
I only noticed this because I used the stack size in formulas of other parameters. This is something I'm sure I wouldn't have spotted otherwise, and that I would only notice way later when I'm trying to use the blueprint in a real game.
It doesn't do this if I don't change the constant in the decider.

And I can't even do what I want to do here. If I change the 106 in the parametrization dialog to 0, it will get merged with OverrideBatchItemCount (which I want to be 0 by default) again. So I have to live with it being 1 instead.

It's really surprising to me how janky this is, compared to how polished the rest of the game is. I hope you'll improve it soon!
I even have a few suggestions of how to do this, but I don't know how feasable those are. Listed in ascending order of awesomeness:

• Allow selecting the parameter items outside of blueprints. If I cancel a parameter replacement when placing a blueprint, I can see the parameter items in the GUIs of various buildings. E.g. an arithmetic combinator calculating "Parameter 0" * 280. If I ever (e.g. accidentally) replace the parameter item with something else, there is no way of undoing that. The "Unsorted" category still shows quality, wires, remotes, etc., but the parameter items are not shown. Something similar for numbers would also be great, but probably more complicated. It would allow players to decide ahead of time "this is going to be parametrized later", instead of having to select things afterwards.
• Allow editing blueprints more completely. Removing buildings from blueprints by right-clicking them in the preview is already a thing. Expand this by allowing players to place down new buildings, and add and remove wires. At the very least, allow clicking on buildings in the blueprint to open their GUI and change their configuration and parametrization directly from there. Allow scrolling and zooming in the preview to facilitate editing.
• Make blueprints effectively a surface (at least during editing). Add an "Edit in god-mode"-button (or something like that) to blueprints that, when pressed, creates a surface, places the blueprint down once in the surface, and gives the player editor-like controls (very similar to what the Blueprint Sandboxes mod does). Upon exit, the contents of the blueprint are overwritten with the contents of the surface. This would make editing blueprints smooth as butter. Additionally, the context of being in a "blueprint-surface" would allow for this: Instead of the parametrization dialog simply listing a flattened list of everything in the blueprint that is, in princible, parametrizable (and it only being accessible once the contents of the blueprint are effectively finalized), let players write a list of "variables" that they can reference while changing building configurations.