With the new blueprint parametrization in 2.0, it makes sense that if Recursive Blueprints is ever to update to 2.0 / Space Age, it should support placing parametrized blueprints as well. Here's some ideas for how it could work:
For blueprint deployer inputs:
- The blueprint deployer would gain a second input (whether from a second wire color or a second terminal) to recieve parameters. This is needed to prevent control signals from being interpreted as parameters or vice versa.
* Pros: Doesn't break previous functionality.
* Cons: Might require new graphics / the deployer to be bigger, depending on how circuit inputs need to work; how would the asymmetry of the inputs be handled?
- The [Construction Robot] signal for construction is replaced with the [B] signal, so the [Construction Robot] signal can now be used as an item parameter without being interpreted as a construction signal.
* Pros: Keeps the single input of the deployer.
* Cons: Breaks essentially all old designs.
For parameters:
- Item parameters would be taken from the parameter input by indexing the signal amount. For instance, a blueprint with 3 item parameters could be built with [Iron Ore] as the first parameter, [Coal] as the second parameter, and [Iron Plate] as the third parameter by supplying signals of 1 [Iron Ore], 2 [Coal], and 3 [Iron Plate] to the parameter input. If there are parameters that don't have a signal strength giving them an item, they would be left as the parameter signal.
* Pros: Simple and sort of lines up with how the Set Recipe Via Circuit Network setting works in 2.0
* Cons: Can't use duplicate parameter inputs (every item parameter must be unique)
- Item parameters would be handled the same as above, but using the signal amount as a bit mask. For example, a signal value of 9 (0b1001) would put the signal into parameters 1 and 4.
* Pros: Can duplicate parameter inputs.
* Cons: Not exactly easy to use.
- Numerical parameters would supply the signal value to their parameter (a signal of 200 [Parameter 4] would supply the value of 200 to [Parameter 4].)
* Pros: Simple, probably even better than any way item parameters would work.
* Cons: Arbitrarily limited to 10 numerical parameters, although I don't actually think it's possible to put in more than that given that there are only the 10 parameter signals.
- Item parameters would be handled like numerical parameters by giving each item a unique ID number. This method would also require the selector combinator to have an extra mode added (or add another combinator for this task, but I think this purpose fits right into the selector combinator) to turn an item signal into an ID value (and probably vice versa.)
* Pros: Unifies item and numerical parameters. This would also allow the blueprint deployer to keep one input, as the [Parameter 0] - [Parameter 9] signals aren't used by it.
* Cons: I don't think the game even has a consistent internal ID system for items or signals. (Correct me if I'm wrong on this.)
Please let me know if I've said something wrong/misleading or if you have any ideas.
