Friday Facts #249 - Dead end exploration

[bman212121]

Hopefully there is a way to differentiate between blueprints that were created on the current map, and blueprints that are just stored in the library. I don't use the library at all and actual prefer to setup new blueprints for every map. I definitely can see certain blueprints that it just doesn't make sense to keep building the same thing over and over again, but a lot of the time I'll blueprint a unique creation on each map. My beef with the blueprint library is that you can just end up losing any creativity because you'll just reach into that blueprint library and copy / paste what you did before. So after 4 or 5 maps you don't have to even think anymore, just slap down all of the blueprints you've collected and hook them up.

So I'm not sure exactly which proposal I like the best at the moment, but I hope there is still a way to keep things for a map separate, or have like a map specific library and a player library. There might be a few blueprints that are trivial I'd want to keep in my inventory, but a lot of the blueprints I use on a map I really only want associated with the map I'm on, and not have them brought into other maps. If people want all of their blueprints tied to their person and always have anything they created that's great, but I think I'll end up with a ton of blueprints that I'd want for one map, but don't want on other maps.

Also, what about mods? Blueprints for maps with mods really should be tied to that map, otherwise they will be completely broken and useless in a vanilla game.

[BlueTemplar]

EDITED
EDITED BIS

All/None of the above :
"Proposal 5" :

1. Default blueprints would be linked to the blueprint library, they could be added to the action bar as a shortcut.
2. Library-linked-blueprints could be transformed into items - which would unlink them from the library -
   (and vice-versa, linking a blueprint-item would destroy it, and add it to the library if not already there)
   - for uses like multiplayer sharing, storing them in chests (for whatever reason) and this-game-only use.

Library-linked-blueprints and blueprints-as-items should be clearly visually distinguishable :
say, green for library-linked-blueprints
and a color very different for it for the items (say, the current blueprint blue?)

Maybe these two should also have a different name and/or a different frame?
(Perhaps the frame should stay similar, to indicate that they are related...)
EDIT : showing this distinction very important, as in my proposal we should be able to create a shortcut for a blueprint-item too (it would still not be linked to the library at that point - though could be removed from the inventory - the "shortcut" wouldn't actually be linked to the blueprint-item in the inventory either, and one of them could be changed without affecting the other. Maybe creating the shortcut should actually destroy the item too to prevent any confusion?).

Also maybe the blueprints-as-items might be introduced a bit later, helping with your "too much new stuff at the same time" concern?

[torham]

I think I would vote for proposal 3.

I mostly use blueprint books, and each blueprint is rarely used often enough to put it in the quick bar or inventory. What annoys me most is that if you open a blueprint book, look for a blueprint, use it and hit Q, it is moved from the book into your inventory, creating a totally useless item ( since I have just used it and no longer need it).

[PaszaVonPomiot]

Whatever you do just remove blueprint items. Also let us sort and make descriptions for blueprints. Thanks.

[Rseding91]

I think I would vote for proposal 3.

I mostly use blueprint books, and each blueprint is rarely used often enough to put it in the quick bar or inventory. What annoys me most is that if you open a blueprint book, look for a blueprint, use it and hit Q, it is moved from the book into your inventory, creating a totally useless item ( since I have just used it and no longer need it).

That sounds like you aren't aware you can hold the book as an item and scroll between the blueprints by shift + scroll wheel. No need to open the book and browse around for one.

[torham]

I think I would vote for proposal 3.

I mostly use blueprint books, and each blueprint is rarely used often enough to put it in the quick bar or inventory. What annoys me most is that if you open a blueprint book, look for a blueprint, use it and hit Q, it is moved from the book into your inventory, creating a totally useless item ( since I have just used it and no longer need it).

That sounds like you aren't aware you can hold the book as an item and scroll between the blueprints by shift + scroll wheel. No need to open the book and browse around for one.

I am aware of that, but If I have 10+ items in the book, it is easier ( at least for me) to just open it and search by icon, rather than to scroll through (inevitably) 9 blueprints I do not want to find the one I do.

[Urth]

Both proposition 4 and blueprint-items :

1. Default blueprints would be action-bar shortcuts linking to the blueprint library
2. Shortcut-blueprints could be transformed into items - which would unlink them from the library (and vice-versa, which would destroy the item, and add them to the library) - for uses like multiplayer sharing, storing them in chests (for whatever reason) and this-game-only use.

Blueprints-as-shortcuts and blueprints-as-items should be clearly visually distinguishable :
say, whatever is going to be the default background color for the other shortcuts as background color for blueprint-shortucts (say, green?)
and a color very different for it for the items (say, the current blueprint blue?)

Maybe these two should have a different name and/or a different frame?
(Perhaps the frame should stay similar, to indicate that they are related...)

Also maybe the blueprints-as-items might be introduced a bit later, helping with your "too much new stuff at the same time" concern?

My thoughts exactly. There is no need to manage a linked state or anything. The only this the item represents is a blueprint which can be added to a library after visual inspection and confirmation.

[bman212121]

I think I would vote for proposal 3.

I mostly use blueprint books, and each blueprint is rarely used often enough to put it in the quick bar or inventory. What annoys me most is that if you open a blueprint book, look for a blueprint, use it and hit Q, it is moved from the book into your inventory, creating a totally useless item ( since I have just used it and no longer need it).

That sounds like you aren't aware you can hold the book as an item and scroll between the blueprints by shift + scroll wheel. No need to open the book and browse around for one.

Not the same person, but I'm also aware of this and find that just as cumbersome. The interaction with the blueprint books just seems really weird and it's difficult to hit the right combination of keys to pick up the blueprint and scroll through it and find the one you want. I only use the book because if you don't it clutters your inventory too badly. But then with the book you end up with 20+ blueprints, and you need to use that really oddball key combination to get through the book. It's certainly not obvious or intuitive to try to hold down shift while using the scroll wheel. Then you have to sit there and study the blueprint to make sure it's actually the one you want because there is no label or anything telling you which blueprint you're currently on.

That actually brings up a good point that if we could actually name our blueprints and have a name pop up, that would be far more useful to me than little icons and pictures. I'd rather see a blueprint that's a list of names like a train stop than an inventory screen. The inventory screen makes sense when a picture can accurate represent an item, and any item with that picture is the same item. But using the game items to try to describe what a blueprint is is almost impossible to remember for me. I'll end up with 4 blueprints with a train track on it, but then even if I make one train track + iron plate, and one that's train track + copper plate, I'll never remember what the difference is.


EDIT: Apparently you can put names onto blueprints and those names will show up on screen. It's just completely hidden and not at all obvious that functionality works. Hat tip to Jürgen Erhard!

viewtopic.php?f=38&t=61278&start=100#p369985

[gunmaker]

option 6:: leave it alone.
the current way blueprints are used is used by at least 5 mods. changing it will break the mods and ruin their hard work.
proposal 7:: add blueprints to a marketplace where people can buy blueprints for coal steel iron etc.
this will give people a way to sort thier blueprints and compare to others, as well as giving rewards to those that created them, thus prolonging the game

[Oktokolo]

The real annoyance is not the separation of local and shared blueprints, but that i can't fully update blueprints after creation. Currently, i can't change icons or take a new snapshot without also having to type the name again. If we could do all that from inside the library, that would really help a lot.

I like, that blueprints can be handled like items and always have one in my quickbar for copy paste use (so specialized copy/paste functionality would not be an improvement). I also like that adding of blueprints to the library is an axplicit process. My library of optimized layouts keeps beeing tidy that way.
Also don't forget competitive multiplayer, where blueprints might be considered confidential (at least until they are used and manifest on the ground).

[dasiro]

in vanilla why would you put blueprints on belts or chests? The factory can't use them directly, only the player can use them manually

[<NO_NAME>]

This FFF is so beautiful.
HYPE TRAIN HAS NO BRAKES!

OK, enough praising. Time for some serious critique!

My thoughts on each proposal:

1) I like this one the most. The problem is that pressing "q" will often lead to accidental deletions of newly-created blueprint. After hours and hours of playing the previous version, impulse to press "q" to put the blueprint to the inventory would be very hard to overcome.
My proposal is to remove blueprint only if it is from the blueprint library. If it is from the quickbar, put it back. It is freshly created, put in on the quickbar or delete after holding the "q" button a second or two.

2) I'm not a fan of that. I agree with the problems pointed out in the FFF. Also, I don't feel like there is any need to have blueprints as real items.

3) I am a little hesitant about the idea of blueprint bar as a separate part of UI. It seems good at the first glance but I feel like it has potential to backfire.
What I can tell for sure is that I will be very upset if this means that the blueprint library will be removed and there will be only the blueprint bar. This is very useful to have a view of all your blueprints with nice big icons, so you can easily browse them. I vote for keeping the library and also adding some simple categories to organize blueprints better. (Something like the categories on the left side of blueprint library: "Game blueprints", "Player XXX storage", etc., but manually created.)
I also very much don't like the idea of synchronizing quickbars between games. In one game I may work mostly on rails and have created a nice quickbar setup for that. I don't want it to be replaced by another setup made for yellow science or something. This would be OK only if you could manually export your quickbar setup as e.g. "setup for rails" and then manually import it to other game by some sort of quickbar library.

4) Nope! Limiting number of blueprints and removing the blueprint library? Count me off! And all problems that I've pointed in 3rd point also apply here.

The problem I see with all proposition is that blueprints in the library will be automatically updated.
It's very often that I take some blueprint from the library and remove e.g. walls or some poles because I don't need them in this very particular situation. However, that doesn't mean that I want to remove wall from the blueprint in the library.
I totally agree that we need an easy way to update blueprints in the library but it need to be done with explicit confirmation from the user. The library should be safe place to keep blueprint in, after all. Like a version control system where you don't want to automatically commit every random change you did.
Changed blueprints should be marked somehow, e.g. they could have different color. They should be then easy to update in blueprint library but in a way that makes it hard to do it by accident.

OK, that was a lot of critique but I'm hurting you because I love you and I want the future version to be the best possible. I still like the direction in which the blueprints are going.

[<NO_NAME>]

One more thing which I forgot:
Obviously, there should be a way to give your blueprints to other players. And I don't mean blueprint strings which are good for the forum, not for a random multi player game.
Honestly, I think that the current way of doing that by the blueprint library is the best.

[Koub]

If I think only vanilla blueprints, I'd like them to be specific item types that can only exist in the blueprint library, or on the cursor, and ultimately have their own quickbars where only blueprints be, either as a link to a blueprint stored in the blueprint library, or the content of a blueprint if unstored in the library (or a link to an item that's stored at the end of the link : destroy the link, the object is not there any more).
RE-reading the propositions, It looks a LOT like 1, with a twist : blueprints have their own quickbars - any number you'd like, and beeither on the bottom, along the others, or (my personal preference), vertical on the right (or left, or let people choose) side

[MicFac]

I love that you guys put so much thought into every part of the game!
I personally like proposal 3 best, as it's only problem could be worked around easily: You could just have some hotkey to switch to the blueprint bar, similar to pressing x to change between the two quickbars. As having a 3rd quickbar always on your screen could be annoying, this key (or an additional one) could bring up and hide the bar again. Middle mouse button could be a good default option for this as it's very easily accessible - and blueprints are used a lot. The full blueprint library could still be visible like today or accessible as another tab in the inventory.

[jimbroof]

I'm going to put down some ideas I have for blueprint management, but the general approach I'm going to take is that Blueprints are Source Code. These ideas mostly extend Proposal 2.

The problem of managing blueprints is difficult and in many ways it is analogous to the problems that software developers have encountered with managing source code. You are basically trying to keep track of a variety of different types of solutions to different problems. Some of these solutions will remain constant (e.g. a 4x4 belt balancer), and some will develop over time (e.g. your personal solutions to smelting). Within the solutions that change with time, there are constant components that change rarely if ever (e.g. a nuclear plant will always have reactors converting fuel into heat). How do you keep all these different solutions synchronized within separate games or between separate players without forcing people to go through overly cumbersome processes? Or suppose you have two solutions that branched off of an earlier prototype, and you want to combine them in a way that keeps the constant elements intact? These are the kinds of questions that software developers have worked on for years, so I think many of the same lessons can be applied.

Ultimately, I think that Git providers (Github, BitBucket, etc) provide a reasonable model for blueprint storage. Rather than keeping data static within the blueprints, actions, blueprint libraries, etc, you allow each player to create their own repositories, where each "blueprint" is a single commit within a particular repository. Here are some examples of how this might be implemented:

1. There are 4 different types of blueprints: standalone, commit, branch, and repo. A standalone blueprint works like in the current system (no linking/references). A commit blueprint is immutable, and modifying it creates a new child commit. A branch blueprint always points to the HEAD of the branch and automatically changes as players commit to the branch. A repo blueprint is shorthand for a "master" branch blueprint.
2. When player A gives a blueprint to player B, they are either giving the player a copy (standalone), or giving player B read access to the commit/branch/repo that the blueprint points to. For example, I might have a repo at factoriohub.com:jimbroof/iron-smelting, and so if I make a repo blueprint that points here and give it out, then the receipient now has read access to that repo (write access should probably be handled through a dialog).
3. Blueprint books are now folders with standalone blueprints (stored by value) or commit/branch/repo blueprints (stored by reference). Let the player organize their Blueprint folders like they would organize a file system, where different entries can refer to different components in the player's blueprint repository system.
4. Allow players to create shared blueprint repositories where anyone within a "team" can make changes and improve blueprints over time.
5. Players would be able to fork and merge different branches/repositories in order to let one blueprint grow in different ways, or to let multiple blueprints be seamlessly combined into a larger blueprint.
6. When a blueprint is "pasted" to the world, you could even tag the pasted elements as belonging to that blueprint's branch, and eventually the pasted elements could develop automatically alongside the blueprint. If you paste a branch, the structures evolve with the branch. If you paste a repo, they evolve with the repo.

Here's how this approach addresses some of the issues mentioned in Proposal 2:

Q: There are two kind of blueprint items now: blueprints that are only in the inventory and blueprints are also linked.
A: There are 4, but IMO the added complexity is worth the added functionality.

Q: What happens when you put your linked blueprint into a chest, is it still linked?
A: The blueprint is copied if it's a standalone blueprint, and linked otherwise. Just like in the "blueprint book", the standalone blueprints are stored by value, and the other types are stored by reference.

Q: What happens when your linked blueprint in a chest is picked up by another player?
A: If the blueprint is standalone, it works like it does now. If it's a reference blueprint, that player now has read access to your blueprint's commit (or branch/repo/gist/etc). The blueprint remains linked.

Q: What if you have two identical blueprints in the library that are both linked to each other. Will the player always understand that changing one will change both?
A: Default to standalone blueprints since that is probably most intuitive for new players. Allow players to use more advanced types at their own pace.

I realize that this is a complex solution, and I would understand if it's not feasible right now. but I think it solves a lot of problems and creates huge potential for effective blueprint management and sharing within the Factorio community.

PS: Thank you for taking these ideas to the community; your interactions with the community and your commitment to this game are really admirable and make for a wonderfully positive gaming experience. And I know that, even if you don't like my ideas, you'll find a great solution that works for everyone.

[Jap2.0]

I may be in the minority here, but all I really use blueprints for is copying and pasting setups - say I'm building a rail line and I want it to be consistent, or copying a segment of a wall to build with my personal roboport, or copying a setup in a multiplayer game for consistency. I rarely keep a blueprint for a long period of time, and I don't often put my blueprints in the blueprint library. I also think that having to constantly switch action bars would be a bit cumbersome, and I worry about blueprints taking up space in my hotbar - or extra clutter at the bottom of the screen.

[juhelak]

I think by far the best option is the Proposition 3.

Advantages:
1) there is just one version of blueprints
2) Easy access to blueprints - just remake the Blueprint Tab as a selector and editor of that quick access bar (the GUI would consist of unlimited amount of quick bar selections and you could choose one + drag blueprints from one to another)
3) better than proposal 4, that one feels really messy and it would IMO be better to have blueprints and items separated, as long as you could still access both quickly. Plus the item quick bars should definitely be separated through different saves...
4) Infinite storage and easy access to blueprints (just swap an action bar - one could be for trains, another for smelting setups...)

Disadvantages and their solutions:
1) "Blueprint quick bar isn't integrated with the item quick bar, so you can't use the default 1-10 shortcuts to access blueprints."
-- If you make the blueprint bar just 5 slots instead of 10, you could dedicate a button for using this blueprint bar (example: nothing = 1-5; Shift = 6-10; Ctrl = Blueprints 1-5). It could even be 10 slots big using this method, but I think that would be unnecessary
2) No blueprints as items
-- What if you had an option to create a "physical" copy of the blueprint, and if any player picked that blueprint up, the game would check if he already has the same blueprint in his Blueprint Tab, and if so, it would be destroyed instead of put into his Blueprint Tab?

I honestly don't think there is a single unsolvable problem with this proposal. Combining this one with that Ctrl+C feature would be IMO the best way of doing it.

BTW, we definitely need to be able to edit existing blueprints. That's the most annoying thing about blueprints - having to always delete the old one and recreate it with just one slight change.

[Morranr]

I really like Proposal 4, especially because it would also allow keeping the same toolbar setup that I'm used to whenever I switch worlds - including any changes or updates I make (no more questioning myself - "Wait where did I keep/move these to again?"). The only issue I see with that would be switching between modded and vanilla (or just changing which mods are active). Obviously, the bars could show a question mark or something, to indicate that there's an item there which isn't present in the current game, but say I always keep Express Belts in the first slot in vanilla, but I always change that to a modded higher tier belt in modded? Could we have some way of indicating "best available belt" for that slot, which would automatically update? Or more manually (but more UI intensive) it could be manually configured, like a priority list, the highest priority item in the list that's available in the game gets the slot.

Back to the true topic at hand, blueprints. I think this solution nicely solves all of the major issues for me, and it would be a clean and understandable solution. Perhaps also the "Blueprint Library" could live on as simply a shared multi-player storage? Although that again introduces the questions of if and how they should be linked... but sharing blueprints with players in the same world seems essential, so I can't think of a better solution. If it were just a single-world library (not across saves, as you'd use the Action Bars for that), I would think it would be feasible to have the library be snapshots of a blueprint dropped there (as in, not linked) BUT there should be some mechanism to have that snapshot UPDATE when an updated blueprint is dropped there again. No more finding and deleting the old blueprint before placing the updated one in.

[melind]

A part of me likes the idea of having just global blueprints. I fall into a trap where I don't really create and save blueprints between games with the current system. I build everything from scratch and then save it for the game I'm playing as I go (or often don't save at all). Either way, the process of updating blueprints and books is a huge pain, anything you can do to improve it would be appreciated. I think I like option 4 the best, but the number of steps you have to go through to make a small change in a blueprint is crazy. On multiple occasions I've wanted to be able to have a blueprint editor so I can make small tweaks (such as adding or updating an element) without deploying the blueprint.

I thought I'd mention, this changes could also have an unintended impact on a thing I like to do. I tend to use blueprint items as a placeholder with filtered item slots. For example if I want to half fill a train, or I want a have a in-use train that holds multiple items and I don't want slots to be filled by whatever inserted gets to it first, I'll mark those item slots to hold blueprints so they won't get used. Would be great to have a no-item filter available for those inventory slots.