Friday Facts #249 - Dead end exploration

[Klonan]

https://factorio.com/blog/post/fff-249

[provet]

Was wondering when this would be discussed, nice to see all the though you put into this.

[GeoStyx]

I like proposal 4

[Koub]

While working on the GUI, we reached the infamous blueprint library, and we started talking about how to improve it

I came reading this. Twice.

[faziaty]

I've been thinking about option #1. Maybe a way to solve some problems is to have an "internal", default blueprint book included in each savegame that holds new, not canceled blueprints. This way you won't have two types of blueprints. All would be just references to a bp book.

[mexmer]

while the idea of blueprint not as item is nice and neat, i see one problem with that. and that is sharing BPs in MP.

atm. you can just drop BP into chest, and later other player might use it, of course eventually we all will have same blueprints, or not ... but still this will be impossible with new BP system.

i'm really not sure where is middleground in this (implementation wise)i do like blueprints and i do like blueprint books, i do not like inventory clutter, and bp duplication, whenever i pick one from book.

[Muppet9010]

To me removing the separation of local and library blueprints is the most important thing as it is a constant cause of annoyance. The weird linking idea would be a pain as often clear a locally held blueprint to re-use it for something unrelated and so would end up decimating my library.
Either option 3 or 4 for me. I'm not a big user of quick access and especially not for blueprints as you don't switch them like you would belt types.

I never thought of leaving blueprints as in-game items and have never come across this in MP, but the fact you mentioned it means it must happen frequently. We just access each other blueprint libraries in multiplayer because that's what I'd expect in the current internet age.

Is good to see the discussions and thought that goes into trying to choose an option. Hopefully, it will help people who may disagree with the choice (once made) understand why it was made.

[Amarula]

I vote for Proposal 4! No more worrying about updating my blueprints, quick access to all the blueprints I need, ability to tuck stuff I don't use all the time out of the way but still be able to access it quickly, this is brilliant!

[MrGrim]

Proposal 2 definitely has some problems, but I'd be a wee bit sad to lose blueprints as items. It's mostly because I've developed a habit of storing blueprints in contextually relevant locations. E.g. my nuclear engineering train has a few nuclear blueprint books in it.

Re limits, no matter what somebody will find a way. I know I have more than 30 books..

[TigBits]

I think Proposal 4 sounds awesome.

[Cacho Tognax]

One thing I'd like about idea 4 is the possibility of having the action bar shared between games, so far the only way to have a consistent hotbar across games, apart from manually setting it up each time, is to have a small script mod that automatically sets the filters up. Disjointing the shortcuts from the inventory would allow to have a few hotbar setups(early/fluid/late/combat etc) and not have to care about it across multiple sessions/multiple online games.

[vedrit]

This looks nice and all, but it has its own collection of problems.
There are two kind of blueprint items now: blueprints that are only in the inventory and blueprints are also linked.
1)What happens when you put your linked blueprint into a chest, is it still linked?
2)What happens when your linked blueprint in a chest is picked up by another player?
3)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?
And many more...
It kinds of leads us to not liking this option too much as well.

I think proposal 2 is the best option, and that some of it's problems aren't really problems at all.
1) Yes, it will still be linked. Blueprint items will always be linked, no matter where they are or who is holding in
2) See point 1. This works because servers already keep track of the library for connected players, so the blueprint item is just linked to the library of the player it originated from.
3) While there might be multiple identical blueprints in a library, they should not be able to be linked to each other. When a player adds a blueprint to their library, rather than it saving a reference to another blueprint, it creates it's own entry. This would be beneficial as, say a player wants to create variations of a blueprint. They would create a base or a template, save it, make changes and then save again. Each time would create a new blueprint that they could, if needed make changes to without affecting any others.

Also, why not a sort of hybridization between proposal 2 and 4? There's still a library, so you have a practically unlimited number of blueprints/books, but you can only interact with them by putting them onto the quickbar (similar to setting quickbar filters, maybe?) and by doing so "removes" it from the library so there are no duplications or worrying about which is getting updated, or whatever.

[Sparen]

As someone who typically uses blueprints for either limited use or in organized books, my biggest problem with the current system is the syncing between library and local copy. However, I do not use the blueprint library as my master - instead, I have a dedicated save file for my blueprints, since it is very, very easy to accidentally destroy a blueprint/blueprint book in the library.

This approach is a mess to maintain and I would definitely like to see an overhaul that allows for some sense of syncing and permanence.

Now, to the proposals:

Proposal 1:
As long as there is a way to easily copy and paste instead of having to blueprint for one or two uses, I can definitely get behind this proposal. Since specific book references would be locked to a quickbar slot, they wouldn't get lost or misplaced.

There will probably have to be some way to distinguish references from instances (perhaps using an arrow or a good 'ol *) but other than that I think this proposal looks good.

Proposal 2:
The linking is good, but the confusion and potential for ugly bugs is not. I agree with kovarex on this one.

Proposal 3:
10 slots is extremely limiting, and for those who use a larger number of Blueprint Books devoted to specific builds will be punished by this system. As described in the post, I cannot get behind this proposal.

Proposal 4:
I typically use anywhere between 4-8 blueprint books per game (LHD Rail, RHD Rail, Passenger Rail, Power, and Road Signs for my current multiplayer map), and a number of custom blueprints as well. However, as someone who never switches between toolbars (this may change depending on how the new quickbar is implemented), this means that at least 6ish slots of my visible quickbar are now no longer available for use by standard items. That means more opening inventory, searching, and finding an item.

The problem then is blueprint books of old builds that I keep around in case I need them. I almost never use them, but sometimes they are helpful to have around. Now all of these old blueprint books are clogging valuable quickbar space. I can't even use my Riverworld setup blueprint on any map outside of FMMO Riverworld maps, yet now if I want to keep it around for when one of those maps is run, it has to take up a slot in every other unrelated game.

This proposal isn't bad in my opinion, but it really depends on implementation and how limited-use blueprint books will be handled.

[ZombieMooose]

Loosing blueprints as items means we might not have recursive blueprints anymore.

I like the copy and paste feature regardless.

Dedicated blueprint bar is nice, but 10 bars is a lot to scroll through for one item if you're disorganized like me (and most new people).

[Zeblote]

yes yes yes remove the blueprint items

they are completely unnecessary outside of the library and quickbar, only cluttering everything

[Godmave]

One way to reduce the clutter would be to destroy empty blueprints on curser when you press 'q'. Have them required to be put in a slot if one wants an empty sheet.
As you said, there are two kinds of blueprint use-cases. The "I have a good build I want to use often", and the "I need to copy/replicate this here". But I often have more than one thing I want to keep of those copy/paste things too.
So for my personal preference I would like 5 copy/paste slots, the ctrl+c/v wouldn't be enough for that.

I don't really like the linking thing. Especially in MP that can and will lead to problems. IF it gets implemented you should add the ability to unlink a blueprint.
What would also help with the question of which blueprint is the newest would be a timestamp of the latest change to it on it. A sort by name/time/customposition would be nice too.

[Ratzap]

What about mods? Some mods break the blueprint library, save it as a copy and force a fresh empty one.

[SootStack]

For proposal 4.

I would love a button which opens up all 10 rows at once on screen and allows me to add more rows and assign an Icon to the row.
This way its more like an inventory. If i have to scroll through bars one at a time, it would be difficult to find the right bar.

[DanGio]

This is too complicated for me ! I want to playtest solution 4 and maybe 3 too. But I know I completely agree with the "troublespotting" part of this FFF, so I'm very confident you'll find a way to do this that brings QoL and ease of use for everyone. I'm currently having like 5-10 blueprint books in my library.

[quinor]

There is a big issue with the proposal "one blueprint bar to rule all games": what about mods and blueprints with custom entities, how are they gonna behave between games?