Lack of static parameterisation a technical limit on completing param system / implementing feature requests

[Sophisticaited]

TL;DR

Blueprint parameterisation variables are calculated dynamically, based upon the order of parameters in the blueprint list. It seems like this imposes a technical limit on the way that blueprint parameters function, which prevents other supported feature requests from being implemented.

While things are currently 'working as intended' and so the absence of the unimplemented feature requests are not considered a bug, it does prevent parameterisation from being useful in ideal use cases. One might say the parameterisation system is not 'fit for purpose' in ideal cases where one would expect it should be fit for purpose.

So, not a bug, but the underlying technical implementation prevents features from being implemented that would help blueprint parameterisation do the thing it appears it was added to do.

What?

Take a small little sub factory for lvl 2 modules, as an example:

07-25-2026, 17-13-14.png (771.26 KiB) Viewed 173 times

Now, it feels like with the parameterisation system you should be able to take a quick blueprint, and parameterise it... so you can simply place the new blueprint and say "make this but for speed modules", or "make this but for quality modules", etc. The expectation is that this should be trivial, given the only difference in lvl 1 module recipes is the output product, and the only difference in lvl 2 module recipes is the module input and output.

Because the parameter calculations are done 100% dynamically, when you try to do this, you find that you cannot change the indexation of the "ingredient of" parameter:

07-25-2026, 17-18-21.png (109.58 KiB) Viewed 173 times

Consequently, without adding redundant factory buildings (such as combinators) to add dummy signals (to act as #1 index, #2 index, etc of the 'ingredient of' paramter) then the parameterisation doesn't work and you frustratingly get this result:

07-25-2026, 17-20-24.png (1.3 MiB) Viewed 173 times

Now, if the parameterisation were not 100% dynamic, but instead was only partially dynamic, a feature allowing additional static parameters could be introduced and accessible from the parameter GUI. This appears to be a well supported feature request (116330).

(I expect that parameters must be partially dynamic, because the parameters are only settled when placing the blueprint... but indexation is also currently dynamic (not sure it needs to be) and static dummy parameters are not currently supported)

The second issue is if you try to work around this for the same result, by setting the level 1 module as the "0" parameter and trying to derive the appropriate level 2 module from the level 1 module. Here, you are presented with the following drop down selections:

07-25-2026, 17-26-54.png (346.55 KiB) Viewed 173 times

The "1" parameter can be set to be "Independent", "Ingredient of", or "Product of". Intuition suggests in this context that "Product of" should produce the opposite result to "Ingredient of". That is, you might expect it to map to an item the parameter is an ingredient for, rather than an ingredient for crafting the parameter.

However, "Product of" a parameter only maps to the parameter itself. "Product of" parameter #0 is parameter #0.

This seems to serve no purpose. If you have access to parameter "0" already, then what use is the product of parameter "0" which is "0".

Whether "Product of" was intended to produce the opposite result of "Ingredient of" or not, what would be useful here is an option for "Used in" or "Output of" (a well supported feature request here: 120242).

But this faces the same limitation: custom indexation is not possible because there no statically customisable parameters available in blueprints. For example, if prod mod 1 are the "0" parameter, and you wanted "1" to be what prod mod 1s are "Used in" (i.e. map "1" to prod mod 2), there would need to be a way to distinguish between prod mod 2 and purple science. An index would be required, because prod mod 1s can be made into both:

07-25-2026, 17-49-11.png (14.43 KiB) Viewed 173 times

If some static parameterisation were available as a technical feature, then these well-supported feature requests could be implemented (I expect, quite simply).

Why?

It seems like this modules example is the most basic (but non-trivial) example of why parameters as a feature are useful.

But it doesn't seem to work. It seems like the feature is not fit for purpose, not working as intended, or is incomplete. If the technical limitation of having only dynamically-calculated parameters were overcome, then well supported feature requests could be implemented that make the parameterisation system much more useful and intuitive.

Post-script

This actually started as a bug report, but when I saw the other posts it because less clear whether it is a bug report or a feature request (or both, or two of either).

Also, really appreciate the game, the new content, the engagement with the community, and all the work and effort going into the game. I've only posted because I love your game, and would love to see it continue improving. I just hope this post is helpful. Thanks <3