A Blueprint Printer - creating multi-purpose factories in a different way

[ssilk]

When re-reading this I had suddenly the picture of a device in my mind: A blueprint-deployer or blueprint-printer.

That device has 5-10 slots, each can hold a blueprint. Think to a chest with 10 slots, placed on ground.
And what it does is this: Depending on the watched input-signal it chooses - by the value of the signal - that slot that matches the value of the input and places the appropriate blueprint on ground in the configured position/orientation (*).
Afterwards If the input-signal changes it first destroys the area, that has been blueprinted before and then places the blueprint that matches to the value of the input signal. If there is no blueprint in that slot, the area keeps cleaned.

The device may show also the area that is covered by all layers of blueprints, so that you do not accidentally overbuilt that.

Simply that. I think someone can also make a mod for that.

PS: A similar suggestion by me: viewtopic.php?f=6&t=7406 Build Action Repeater
--> This suggestion is just the prerequisite of that.


(*) In my opinion this is a special step if you say "This blueprint works in that place/orientation". It converts a blueprint, which is something like a non-specific plan to something much more specific, like a "construction-plan". I think the game should represent this difference somehow.

[quadrox]

Interesting idea.

How large would the coverage area for the printer be? Or would that be blueprint dependent?

Make it too small, and you can't do much interesting with it, make it too large and the auto-clean will/can get in the way of existing stuff.

[mrvn]

And don't forget that for a large area you need to always have roboports in the design even for a fully clean one or some parts will be unreachable for cleanup. Sadly deconstruction plans aren't smart enough to leave a roboport and power till the last.

[ssilk]

How large would the coverage area for the printer be? Or would that be blueprint dependent?

Blueprint-depended of course. I see problems with very big blueprints, cause I guess the current way the construction bots works is not reliable enough when constantly deconstructing/constructing when there are roboports. See mrvn's comment. (**)

Interesting side effect: The blueprint that is printed might
a) contain more blueprint-printers, that are filled with more blueprints (*)
b) include itself (the printer), so when the condition changes it will remove the blueprint-printer and might create a new one at another position.

That two ideas would enable slowly growing, self-replicating factories. Super interesting stuff, cause that CAN create an incredible amount of complexity with very view changes to the game from a basically quite simple element. I think to keep the complexity somehow under control is a big part of balancing this, but I have no idea yet, how that might be done. But I think it is important to say, that this kind of complexity is not so bad as - for example - introducing new types of belts. That is more or less wanted complexity cause it increases in that case the gameplay-value.

So I added it now to viewtopic.php?f=80&t=27054 Self Replicating (e. g. with Blueprints)

What surprises me is (I currently learn a lot about how to program mods) is how easy that might be implemented compared to other ideas around self-replicating.

Make it too small, and you can't do much interesting with it, make it too large and the auto-clean will/can get in the way of existing stuff.

Well, the area for construction/deconstruction can be different. Why not? Which might introduce even more complexity, I think that is not needed.


(*) so we need a "blueprint-copier" to create enough copies of a blueprint. That device looks out for any needed blueprint.
The blueprint-printer simply "requests" a blueprint - like a requester chest, which (as above mentioned) might work like so, if it will be impemented as a mod - and the copier registers those requests and automatically creates another copy of that blueprint and provides that to the logistic system like a provider chest.

Edit:
(**) What come into my mind after reading: We might need a "layered-deconstruction", that deconstructs step by step. First all production facilities, belts, inserters, chests. Chests should also be emptied (by replacing them with active providers first), so that logistic bots might help. Then circuits, combinators and so on. Then we can remove power and roboports. And at the end the blueprint-printer, but before it is removed he can print the new blueprint.

That should be also done for the construction. First we need power and roboports. Power is difficult, cause on one side it is important to reproduce the cable-connections exactly in the same way. But that will make problems, if the blueprint have some kind of "direction", that permits to connect a far roboport. Far roboports at the edges are also kind of unreliable, cause a forest or something else can prevent the roboport to be placed, cause it is out of the range of the robots to reach the trees that needs to be removed. If the roboports are all online then the "rest" can be placed.

[mrvn]

I'm thinking of the following setup:

- Type A printer contains a roboport, laser turrets going 2 ways building a corner and power for them and going to the inward corner.
- Type B printer contains a roboport and a straight line of laser turrets and power for them
- Type C printer contains just a roboport and the power lines as Type A and Type B have
- Start with 4 A printers in a square facing outward with 3 B printers between them on each side. Don't have anything larger than a Type B in the middle square
- Set a counter to the items used in those printers + 4 times Type B
- If available items > counter (test each and all need to be larger) start replication
* Type A:
+ place a new Type A going diagonally outward
+ place 2 new Type B going straight outward
+ place a Type C going diagonally inward
* Type B:
+ place a new Type B going straight outward
+ place a Type C going straight inward (Note: this will overlap with the corner printers, must be symetric so they always match)
* increase counter by 4 times the items in Type B

Now the idea is that you have your base surrounded by a wall of laser turrets and they grow outwards as more items become available on it's own. Type C should probably contain some solar cells and accumulators (include them in the counter).

[ssilk]

Yes, ine of many, no endless (!) thinkable setups.

Other examples: Some kind of "wandering" setup is also thinkable ("wander" into a direction, until finds resources, then change into an outpost) as setups, that just clear a forest.

[mrvn]

Yes, ine of many, no endless (!) thinkable setups.

Other examples: Some kind of "wandering" setup is also thinkable ("wander" into a direction, until finds resources, then change into an outpost) as setups, that just clear a forest.

You mean something like build a miner and see if it produces anything. If so build a processing furnace, if not move yourself and try again.
That brings me to the problem of things being buildable. You can't build a miner unless there are things to mine there. Would the blueprint printer fail there? Just skip the miner but build the rest? Give off some signal that the blueprint is unbuildable?

I hope it won't be the first or at least a switch to toggle failing on and off.

This probing printer might get complex. Just moving until you hit resources seems simple enough. But what if you hit water. you have to move around it. Using landfill is not a sensible option I think.

[ssilk]

You think too much forward.
Fatorio development runs in very small but continuous steps.

[mrvn]

Hey, we only need one "small" step. A blueprint printer. Everything else is combinators we design ourself.

[meganothing]

That brings me to the problem of things being buildable. You can't build a miner unless there are things to mine there. Would the blueprint printer fail there? Just skip the miner but build the rest? Give off some signal that the blueprint is unbuildable?

In 0.14 at least you can place blueprints with miners on unminable spots. In that case the miner is just not copied/placed but the rest of the blueprint is built. The blueprint printer obviously would do the same.

[mrvn]

Still a small problem since you don't detect it other than that you get no output. And only for miners. Should have said belt, not miner. What if the blueprint has a belt where there is water.

Could it be something like this?

Blueprint Printer: 5 blueprints available
Input Signals:
B:4 X:10 Y:15 R:90
Output Signals:
Fast Belts: 10
Inserter: 5
Electric Mining Drill: 2

You send it a signal B (for build) with the blueprint number, X and Y offset relative to the printer and rotation R of the blueprint. It then emits the number of items placed. Maybe it could have a P (for probe) signal too where it only reports the buildable count without actually placing the blueprint.