How about persistant blueprints?

[mrvn]

This idea is only half formed but maybe it's interesting to some or you have ideas to improve it.

I've been playing with blueprints a lot. Who hasn't? But frequently I've placed a blueprint a dozen times and then I want to change something. For example I notice that 2 power poles could be replaced by one. Or a yellow inserter is too slow to keep up and needs to be a fast inserter. Changing all the places the blueprint was placed is a pain and should really be automated. It's the name of the game, isn't it.

So I was thinking that there should be persistant blueprints, called blackprints from here on. A blackprint consists of a source area, possibly on another surface like the Blueprint Lab but could be on the main surface too. It can then be placed many times on the map like a normal blueprint. But if something is changed in the source area then all the placed copies of the blackprint are updated the same way automatically. Not magically though, you get deconstructions and ghosts placed and then construction bots have to do the updating. But hey, that would be automatic.

I think a black print should have an entity that gets placed as part of the black print. In the source area a blackprint controller is placed that monitors the region of the blackprint for changes. Hovering over it would highlight the controlled area and could show the number of copies of the blackprint. It could have a GUI that shows minimaps for where the blackprint is placed similar to the train menu. In the placed blackprints the part of the controller would be taken up by a receiver. The receiver would monitor the controller for changes and enact those changes by placing the ghosts. Again hovering over it would highlight the controlled area. The GUI could also allow swapping controller and receiver roles, making the other area the controlling source area for all the copies, removing a placed blackprint entirely or removing the receiver leaving the buildings behind.

Comments?

[eradicator]

Sounds moddable except for the "highlight the area" part. Because nobody has written a proper formal request for that yet.

[zOldBulldog]

Sounds cool but I think there are a couple simple things that are needed first:

1) Cloud persistence for blueprints, even if you don't sync your games with the cloud. As a matter of fact, blueprints should be persisted first, as a defense against accidentally shutting down the computer before the cloud sync is complete (or... To make the cloud sync hold up the shutdown until it completed its job).

2) A cleaner interface for blueprints. The multiple copies that get made now are a nuisance. I can see being able to put a shortcut in the taskbar, but other than that they should stay in the master storage. Of course, this should not be done until (1) is complete, since currently you can only transfer blueprints between computers by putting them in a game's storage and then cloud syncing.

[mrvn]

Sounds cool but I think there are a couple simple things that are needed first:

1) Cloud persistence for blueprints, even if you don't sync your games with the cloud. As a matter of fact, blueprints should be persisted first, as a defense against accidentally shutting down the computer before the cloud sync is complete (or... To make the cloud sync hold up the shutdown until it completed its job).

I always turn clouds off. Pointless waste of CPU/GPU power just to show some reflected shadows on water.

Seriously. WTF? You want a change of a blackprint in one game to affect all copies of the blackprint in all your other games? Insane, especially when one game has loaders and the other not even bobs adjustable inserters.

2) A cleaner interface for blueprints. The multiple copies that get made now are a nuisance. I can see being able to put a shortcut in the taskbar, but other than that they should stay in the master storage. Of course, this should not be done until (1) is complete, since currently you can only transfer blueprints between computers by putting them in a game's storage and then cloud syncing.

Clearly backprints would have to be different. A blackprint is always a reference to the source area so making copies makes no sense.

[zOldBulldog]

ROFL mrvn!!! Steam Cloud persistence, not persistence of clouds.

I meant fixing the persistence of BLUEprints when cloud synched. Both points are a prerequisite of any work on blackprints, to avoid having to do it twice, since both need to feel natural and efficient, so even with their differences both would have some common design elements.

And given that blueprints - as effective as they are already - have a very flakey way of functioning in their current implementation, it is inevitable that they will be revamped sooner or later. So, they need to either first fix blueprints and then do blackprints, or do both at the same time.

[mrvn]

I don't even want them synchronized across games. So synching them across steam is pointless for this.

Backprints could be synchronized as blueprints for starting new ones in other games. Actually you could place the blueprint into the blackprint controller building to select what it should build initially or have a recipe blueprint -> blackprint controller. Other than that I don't think blueprint organization affects this idea much.

[zOldBulldog]

I don't even want them synchronized across games. So synching them across steam is pointless for this.

Backprints could be synchronized as blueprints for starting new ones in other games. Actually you could place the blueprint into the blackprint controller building to select what it should build initially or have a recipe blueprint -> blackprint controller. Other than that I don't think blueprint organization affects this idea much.

I think you are misunderstanding me. I am NOT suggesting in any way that they should synchronize blackprints.

I was just saying that fixing existing blueprint problems needs to happen before or at the same time as the introduction of blackprints, to save the devs from having to mess with blackprints twice (once to create them, once to adjust them to maintain the same "feel" after fixing blueprints).

I also realize that most players only use one computer or have such bad internet that they intentionally disable cloud sync, so they don't need or experience the problems that current blueprints have when you hop between a desktop and a laptop. Still, such a blueprint fix will inevitably come before they release 1.0, as otherwise the game would look and feel a bit sub-par and that is bad for sales.

And I totally love the idea of blackprints in the ways you describe them.

[4xel]

I think a more obvious and useful step to preppare anything like a blackprint is implementing the possibility to edit a blue print.

As for black print, I'm not a huge fan of hidden information, so the way I would go about it is with a blackprint beacon to put on the corner of each area you want black print edits to be reported.

[mrvn]

I already had in mind to have a controlling entity for the blackprint. For one it would be the interface for managing the blackprint. Like split it off so it no longer follows the source or becomes the new source for changes. It would also eat resources to build so blackprints aren't totally free.

Another thought was that you have to surround the controlled area with a special tile or fill the area with it. Everything within the area would be controlled by the blackprint. Want to control a larger area then you need more resources to surround or fill the area. Filling in the area might be better for showing what area is affected by the blackprint.