Hi, this originally started as simple request to add parameter control to blueprints, then I figured I should at least offer my two cents on how you could implement the idea, and then I realized how much effort it actually is to make parameters as flexible as possible. I'm asking for a LOT of stuff here, and I understand if you just say "nah too much" lmao. I do think it would be a good idea though, and I'd love to discuss and try to simplify this. I'm certain I'm overengineering the idea in some places.

As far as I can tell, there's no way yet to adjust parameters of a blueprint when deploying (which is fine, there's hardly been any time to update).
It would be super nice to be able to do so, is this feature planned? I have a proposal for how the user-end of things could be.

I know of two types of parameters: constants and the special "parameter" signal which is replaced with another signal. I propose splitting these into two lists, retaining the order in which they're declared in a blueprint.

For the list of parameter signals, the deployer will assign signals to the parameter when a signal's value matches the index the parameter is at.
For the list of constants, the deployer will assign constants in order by reading the values of predefined signals (configurable in the deployer).

As an example, let's say we have a blueprint with five parameters (blueprint string will be put at end of post):
- Parameter signal 0
- Parameter signal 2
- Constant value (default 5)
- Parameter signal 1
- Constant value (default 4)

This blueprint is then placed into a deployer which has the following signals being sent to it:
- Electronic Circuit: 1
- Steel Chest: 2
- Iron Gear Wheel: 3
- Virtual A: 8
- Virtual B: 0

When activated, the blueprint will be placed using these parameters:
- Electronic Circuit
- Steel Chest
- 8
- Iron Gear Wheel
- 0
NOTE: The number IDs of the parameter signals don't match the order the blueprint declares them, hence why Steel Chest goes to the second listed parameter signal, rather than "Parameter signal 1". I think this is desirable behavior, as it should play nice with mods that may add more parameter signals.

For this to work, the block would need some reworking with how it handles its "configuration" signals like X, Y, etc. For the most flexibility, I think these are things that should be configurable in the block itself with a panel on the right side, much like the roboport.
Basically, each signal type which currently has hardcoded behavior would become something you can define the signal for, and maybe even further you could customize which color these values are read from. For example, the deployer could be set to read its X and Y offsets from Virtual A and Virtual B instead, and only on the red wire. And regarding constant assignment, above I used Virtual A and Virtual B to assign the two constant values, but I think these could also be configurable in the same way. So you could define it to instead read constants from the Iron Plate and Copper Plate signal as the first two. This would also allow the block to trigger on a different signal type, making obsolete the map setting that determines whether Virtual 0 or Construction Robot starts blueprinting. It would ALSO make the deployer itself something that could be parameterized. I have no idea why you would use that, but I'm sure some mad genius out there can make use of it.

Basically: every signal the deployer already responds to would become configurable in the UI and parameterizable. The deployer would also gain options to filter reading from red or green for those options, as well as for the new options which determine which signals (and in which order) constant values are read from, and which color will be read from to assign parameter signal types. As one final option, you could also make it so that the default constant values can be read into signals (but maybe that's too much with everything else I've said..)

Thoughts?

BP Code: https://pastebin.com/dZkdqDC4

Yeap, there are quite a lot of overcomplications.

1. Blueprint parametrization.
   The API does not have the ability to interact directly with the parameters. It is possible to implement it, but it will take time and an additional set of signals.
   Special parameters are not a problem, because it's just replacing one item with another (I'm not sure about the ingredients.). But the problem with numbers is: you will need to specify which number to change to which one. Formulas will also be unavailable.

2. Additional set of signals.
   I'm thinking of adding some kind of deploer attachment entity into which you can send additional signals for parameters.

3. Deployer configuration and flexibility.
   In short, I'm against it.
   Firstly, with the help of an arithmetic combinator, you can convert any signal into any other (I added the "deployer deploy signal" option to avoid item signals so that it doesn't conflict with the filter for the deconstruction plan).
   Secondly, flexibility has a negative impact on UPS (The signals are read every tick for each mod entity).
   Thirdly, custom parameters are not always saved in the blueprint (API problem).

I'm thinking of removing the possibility to select signals in the scanner in the future. It remains for me to figure out in what form to add the cheat sheet for signals in the game...

Oof. Well, I didn't feel good about asking for something without providing at least an idea so I had a go at it. Nice to know you were thinking about supporting it.

Regarding point 1: since you don't like the idea of extra configurables, what do you expect number replacement to look like? Again, the first thing I think of doing is mapping signal values to indices, maybe replacing the first numeric parameter with the value of Virtual 0, second with value of Virtual 1, etc. That doesn't seem too different from what you already do with mapping certain virtual signals to various options of placement, like Virtual X and Y.

Regarding point 2: I quite like the additional block idea, that does sound convenient. What do you expect that to look like from the player perspective?

Regarding point 3: tragic. I didn't know about the UPS hit. I'm inclined to say it shouldn't matter that much (how many deployers are you going to really have built at the same time?) but in principle, for a game like Factorio UPS should be a major concern almost always, so I'd agree with you. The API problem is also a really unfortunate concern.

For the cheat sheet, maybe it could work well in tips and tricks? In my head this would look like a category dedicated to the block, with an entry for each set of related signals and their effect. Then the animations come naturally, as it would just be demonstration of the signals' behaviors. Initially I wanted to say the Factoriopedia, but I don't know how that would work as I believe that's tied to items/entities/recipes, and doesn't support somewhat detached concepts like an extra info page.

EDIT: I went and had a look at the modding tutorial and the API more closely, and I see exactly what you mean now with point 1. I'm going to keep looking at the API and see if I can dig up something.

It's okay, I got the basic idea. You could just say, "please make support for blueprint parameterization" =)

1) Blueprint parametrization. (number replacement)
I plan to add two sets of new virtual signals: "Found this number (slot number)" and related "Replace with this number (slot number)".

2) Additional set of signals. (new block)
Uh, it will look like a constant combinator that is placed next to the deployer. The point is that there will simply be an additional connection point where signals can be sent independently of the main unit.

3) Deployer configuration and flexibility.
"how many?".... YES!
Ahem. I have seen examples where the deployer is used for a simple function: to remove a chest.
Or move a miner forward (with a mod for mixed resources everywhere and a ban on building on ore).

4) Сheat sheet.
I haven't figured out how to add anything to the tips and tricks yet. =(
Although I know a couple of tricks...

Okay! I'll leave you to it. I hope I wasn't a bother, when I see a problem I like to design solutions. It's why I play Factorio and why I write code, but I shouldn't try to act like some consultant here. I look forwards to the update :)