Recap of existing features
Currently we have 3 distinct types of tools: Blueprint, Deconstruction Planner, Upgrade Planner.
There are also blueprint books which are collections of the previous and can give direct access to a particular tool by using the scroll wheel (after picking up the blueprint book under your cursor), and copy/cut/paste which are just quick blueprinting(+deconstruction) shortcuts.
Blueprints are precise specifications of structures in a finite space, including modules, logic conditions, wire connections, and more, even trains! Basically everything except inventory contents (except for train fuel)...
Deconstruction planners are just specifications of filters which you can drag over an area and mark anything that matches for deconstruction, plus a bit of special logic for handling tiles and un-marking.
Upgrade planners are similar to deconstruction planners, but with an (implicit or explicit) A-to-B mapping for replacing a limited subset of structures.
The similarity between deconstruction planners and upgrade planners is perhaps why they also have (or should have) a similar name and blueprints have a distinct name that corresponds closely with the precision and static nature of real-world counterparts. Which is to say that any changes made to to the blueprint system should not take the concept too far from our intuition about what "blueprint" is, and that's my reasoning for making "Blueprint Planners" a distinct feature, instead of baking the following ideas into blueprints directly. Without further ado...
What is a Blueprint Planner?
A Blueprint Planner is sort of a dynamic blueprint. It speeds up the placement of (what are or would be) lots of individual blueprints. The goal is to make it possible to customize the placement and tiling behavior beyond simple grid snapping, to potentially even be able to recreate the logic of smart belt dragging (automatic undergrounds and corners), but at a higher level of abstraction.
There are four general directions / "areas of opportunity" for this feature:
- Custom tiling behavior (joinery)
- Custom snapping behavior (submodules and add-ons)
- Deconstruction/upgrade orders
- Parameterization (point-of-use configuration, accomplished either by blueprints/books or by scripting)
Custom tiling behavior
You would be able to specify a separate blueprint variation for each possible tiling connection (all 16 combinations of the adjacent grid cells -- you don't have to define each one, only the ones of interest to you). This would allow you to do things like inner corners and outer corners for your defensive walls or multi-belt/pipe busses seamlessly.An alternative, simpler but more limited approach (and technically more feasible I think), would be to let you define up to 4 different tiling variations:
- Initial (required, default)
- Straight
- L Corner
- Reverse L Corner
With this approach you could still accomplish common scenarios like the defensive wall example, but the game would be able to select the correct variation immediately as you drag across grid cell boundaries. The ability to adjust the variation retroactively would be more powerful as you could customize "T joints" or "+ joints" (4-ways), but it is perhaps rarely needed.
Custom snapping behavior
You would be able to define hard requirements for blueprint placement (like the presence of existing structures that would join up with the blueprint, like belts and pipes or electric poles), and the game would search for ways to satisfy these requirements. (For performance reasons it may be necessary to allow us to define explicit markers to trim the search space.) You could have a blueprint (planner) that must overlap with an existing roboport or some other marker or circuit network contraption.This would clarify the usage of certain blueprints as add-ons/encapsulators.
Additionally, a blueprint planner may define attachment points for submodules (other blueprints or blueprint planners) at specific coordinates, on which you could later use the pipette to instantly put these matching submodules under your cursor. This could be used both for submodules as well as a convenience for extending existing tileable production lines (a bit like the rail planner).
Deconstruction/upgrade orders
A blueprint planner should be able to mark specific squares to be deconstructed before its blueprint is applied, similar to shift-clicking with regular blueprints to deconstruct trees/rocks. This would allow blueprint planners to act as upgrades or to do other modifications/fixups as needed. It would be especially useful together with the previous submodules/add-ons concept. For more control, it may be possible to conditionally deconstruct only entities of a specified type (or list of types).Parameterization
In your blueprint planner you would be able to set up a small form which the user of the bp planner could fill out in a simple question-and-answer style which could simplify the selection of small variations that we currently have to do solely via bp book hierarchies (which aren't text-searchable and the scrolling feature becomes unwieldy pretty quickly). This could be used for things like rails, examples being "Do you want to include solar panels and accumulators? Y/N" and "Block length: 1 | 2 | 3 | 4 | 5" (with scripted blueprint generation you could enter any positive integer, but I'm not suggesting that, see footnote). For production lines, you might want to toggle whether heavy oil is brought in and turned into lubricant or whether lubricant is already made elsewhere and brought in directly. The user probably shouldn't be prompted with this form every time, so it's probably something you'd see when you right-click the blueprint planner to configure it, similar to regular blueprints.Putting it all together
With the combined power of these features you could have some very nice, streamlined blueprint planners that are quick and easy to use. You could repackage some huge nested blueprint books into much more ergonomic blueprint planners.
For example, you could have a defensive wall blueprint planner which includes a resupply train station on the initial click, lets you choose wether to include gun turrets and, if so, wether they should be belt-fed or requester-chest fed, and it automatically extends and forms correct corners as you drag. Every so often you could have attachment-points that let you convert that segment of wall to a gate segment (just press Q while moused over the blueprint planner pipette spot and you get a conversion blueprint that snaps to that exact position -- you could also have different variations, one type of gate for pedestrians, another for trains).
Note
Some of these features (mainly the custom snapping behavior) would likely require or benefit from the game remembering where blueprints have been used on the world surface, which I think is tricky to do. (What happens when you modify an already placed blueprint or something inadvertently is destroyed? How much fault tolerance should there be? What about memory/performance problems?)
In its most extreme form, this feature would essentially be a blueprint scripting system (with actual code or with visual tools). Also, all or most of these capabilities would be possible with the existing circuit network if given a way to reference blueprints from circuits and to automate the placement of those blueprints, but it would not give you good feedback and it would be slow as it would have to run logic (after getting electricity going) to adjust itself. To be clear, I'm not really suggesting a full-on blueprint scripting system or automated blueprints. I think integrating a focused subset of these capabilities into the game in a way that is approachable to average players would be worthwhile.
Discuss
What do you folks think? Are there any particular blueprinting features you have thought of that would fit right in here? Would this be too much / too OP for vanilla? Could this be accomplished with mods?
