So I had this clear vision: Now we have the blueprint-book. You store in that blueprint-book some blueprints to build walls for example; wall-corners, entries/gates, defenses etc. Then it makes also totally sense to store the needed configuration of your tool-belt, the requested items and so on. And that is stored within the same blueprint-book, of course.NegativeTwelfth wrote:I imagine it similar to how a handy(wo)man has many different toolbelts and toolboxes of different configurations and with different tools to be used for different general tasks (plumbing, carpentry, painting, etc). With this buildin, a player working on the main factory would set their requestor slots for what that area requires and their toolbelt for assemblers, poles, belts, etc.. Someone knowing that they are going to work on outposts might trash things like assemblers and circuit network cable, and set their logistics request slots for more walls and turrets. The player would obviously have to wait for these items to be taken away and delivered via logistics bots but it would be using automation to make one more thing in the player's life, well, automatic.
So instead of having a special device like in the above suggestion I suggest to use blueprints for configuring this.
In other words: Blueprints cannot only store constructions, but they can also store a character-configuration.
Some use-cases:
Using already existing blueprints of more or less big constructions onto the player
Will result in a request (once!) for all the missing items in that blueprint. A prerequisite is of course, that we have one-time-request-slots.
More features (just stupid ideas):
- Repeat actions like with the crafting queue.
- There could be a "request-queue", with the blueprint-symbol for each request.
- If I use the blueprint I formerly requested, game tries to take the items only from the player.
Relationship between current Blueprint and then
I think we need some kind of different blueprint-icon, if the blueprint stores a configuration (not a construction), to distinguish between current blueprints for construction and blueprints for storing configurations. Both at the same time makes no sense, but there are some relations between both. See for example above!
And well, I'm not sure, if that is not better an own, new type of item. But a change is simple, not much afford to change that.
Storing Parts of Character Configuration
My idea is simply to take a blueprint, and then click/drag on that parts of your configuration, that you want to have stored. Nearly the same interface as the current blueprints, but you can mark for example only SOME request-slots. Only the marked/stored slots will be changed, if the blueprint is used. You have of course an editor to change the config, name it, store it on disk...
Using a Configuration Blueprint
Just open it and use it. Config will be changed immediately.
You can place that config-blueprint of course in the toolbelt. Which will get very interesting, if you change the config-blueprint with each change, too. With that functionality you can change between two configurations without needing two tool-belt slots.
Example: You create two blueprints. One that changes your power suit to "fight mode" (much shields...). And the other switches to "construction mode".
Now you add to the blueprints, that the "fight mode" will change the quick-bar-slot 1 to "filter construction mode blueprint". And vice versa. Now you can change between fight and construction just by pressing "1" and right-click. (Ok, this sub-feature is eventually too fancy/complex
)Some dreaming is allowed:
Usage as "Configuration of Other Entities"
Having this way open, why not also use that blueprints to store configurations of module-settings for assemblies. Train-setup. Configuration for inserters/combinators.
Change Worldwide Module Settings/Train Routes
The point is here: If you change the configuration of that blueprint it will be stored in all entities you have copied the blueprint into.
Which means: Change the configuration of the modules of the blueprints you have formerly copied and your construction bots begin to remove the unused modules and replace it with the wanted.
Or for trains that kind of blueprint brings also the - in my opinion needed - train-routes: Set blueprint on two trains. Let them run. Now change blueprint and the trains follow automatically the new rules.
Automatic Configuration Change of That
Now imagine: I place one (or more) config-blueprints in a "blueprint-modifier". Which works more or less as an inserter. And it can switch parts of that configuration on/off or exchange it with other configs.
