Friday Facts #249 - Dead end exploration

[Trblz]

It all depends on HOW and WHY you use the blueprints in the game.

These are my 3 categories of blueprints
[1] Short-term blueprints (current functionality) - these are 1 - 4 blueprints on the action bar to quickly blueprint and paste certain designs and then wipe them. An example is a specific storage chest-inserter-assembler setup you need to copy paste multiple times)
[2] FIxed-blueprints - thsese are sets of blueprint(book)s that you always want to use in the same way. An example are train track setups (2/4 way, T, X, corner) or cityblock designs.
[3] Work-in-progress - Designs that need to be updated - blueprints that are not 100% 'perfect' or need to be updated a lot during the game. This is to make sure of higher level assemblers or inserters.

In the current system I find it tedious to update my library and at the same time i've deleted the wrong blueprint too. Whether or not the BPs are in library or only in action bar depends on HOW they are linked.
With this current system I tend to have 2-4 blueprint books, 4 short-term plus delete and upgrade planner in my action bar - 10 in total. With some QoL mods this is works fine for me.

Now coming back to FF#249:

If I can link a blueprint book to the action bar and manage ACCESS RIGHTS per book to
* READ-ONLY - for the fixed blueprints
* WRITE-ALLOWED - for fixed blueprints that need to be updated after all. If there is a way to do version management then awesome.
* SHARED-READ - for MP where the (administrator?)-owner only can make changes to the book
* SHARED-WRITE- for MP where all can make changes to the book

then a linked-book into the action-bar would be enough for me. That puts me in between option 3 and 4

[bman212121]

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.

I'd actually go one farther. Let's say you were playing PvP games. You'd really want a system that would just let someone drop a blueprint into an area a team would have access to, so that any player on that team could make use of it. Removing blueprints as an entity would certainly make it much more difficult to make use of sharing them. I could even see like a creative co-op mode where teams compete to build blueprints, and the game pre-populates what you need to build to win. You'd need to have a way for players to gain access to those from the map, otherwise it wouldn't work.

I definitely think they need to be separate from the inventory and item bar so they don't count against your space. But I could also see being able to use mechanics like holding a blueprint in your hand and just dropping it on another player to give it to them. But you might be able to get away from any of that if there was just a full blown blueprint menu system where people could cruise that and search for players, their blueprints that would take away most of the need to try to transfer them. It would be nice to give the server admins some control over blueprints. In the case of PvP games again, if everything is in the menu the server admin could setup which players can see each others blueprints, and just flat out disable the ability to get into any stored blueprints that a player might have, and disable the ability to import any blueprints.


So yea for me I guess none of those proposals. I'd be fine with blueprints getting their own menu / library, and their own hotkey space. If it's in hand you could drop a shortcut to a blueprint onto another player, but I don't think I'd want blueprints to mingle with game items. Someone stated they like putting blueprints for certain things near them, and I don't know that you necessarily need that, but really you just need the organization aspect. If you have a blueprint menu and you could actually organize blueprints under a folder or label, then you could group the nuclear blueprints together, and the circuit blueprints together, etc etc. I think that any hotkeys or other aspects of them should just be links to the original blueprint, and then you could have controls on how those get updated.

So for controls by default you could get a link to a player owned blueprint, and it would be read only. The player could flip a switch to allow someone to update it, and by default the original players copy would be read / write from their copy. If you say put a blueprint onto a map storage, that could be setup to be read / write by whoever the server admin says has read / write access, but maybe new players only get read access to it. You could do the same for teams, where anyone on one team would automatically have read / write, and if you're not a member of that team than you just don't see it at all. If a player wanted a "map" or "team" blueprint, they could copy that item into their personal storage and then it would be a new entity that they can modify as they please.

[Reika]

I do not want persistent hotbars. They will cause a great many headaches for those of us with modlists that often change, and saves that are radically different from one another (but used in parallel).

Someone else explained it more thoroughly, and suggested an alternative, superior solution:

https://www.reddit.com/r/factorio/comme ... n/e1ipm3w/

More problems with persistent hotbars:

They break or become useless clutter whenever you change mod loadouts
They cause clutter whenever you switch between saves where you use different sets of blueprints
Blueprints in hotbars become useless clutter whenever you connect to a server that doesn't allow imported blueprints
When are the blueprints actually loaded to the server? On connect (causing massive lag whenever somebody connects with his bigass library) or on use (requiring a load-in time for a thing in your hotbar)?

How about this Proposal 5: Blueprints are still items, but everything is better. The player simply has a separate, scrollable 'blueprint' inventory where only blueprints go into (in exchange, blueprints cannot go into the player's main inventory). This inventory is visible in a "blueprints" inventory tab like the other tabs you plan to add (logistics, crafting, loadout), where you can move blueprints to and from the blueprint library, which by the way is visible in the same tab, above/beneath the blueprint inventory, alongside a blueprint trash can slot.

With that, players will be able to manage their blueprints with absolutely minimal hassle, being able to select the blueprints from their (organizable) blueprint library that they want to use in this world, being able to use E and 12345 to select blueprints like they're used to selecting literally everything else, while still being able to use blueprints like items (e.g. to drop them into the world or into other players), and also being able to avoid using the blueprint library completely if they wish to do so.

This suggestion would make blueprints and the blueprint library much more streamlined to use, just the way I'd like to use them (trying hard to avoid status quo bias here), and you wouldn't actually need to code any super special special behavior for blueprints. This system will also work independently of whether you decide to make the hotbar virtual.

The only thing this suggestion does not address is the ability to copy-paste with temporary blueprints.

[Tev]

I am using current blueprint system extensively, and it works great. Not big user of library (as I spend a lot of time on single map), and I guess its UI can be improved, but PLEASE don't mess with great blueprint system just because you added unpolished version of blueprint library!

Only proposal 2 doesn't remove any substanstial functionality, so it seems like only option (besides user-propoed option 6 above, 5 seems good too). And you are doing it quite disservice by just brushing it off the table without thinking - I understand programers' desire to simplify things, but current system is good, and your "simplifications" are just feature removals. (I mean - you seriously considered new blueprint action bar that would not use standard shortcuts? Really?). This post addressed just a few flaws in your arguments around option 2, I can add more:

There are two kind of blueprint items now: blueprints that are only in the inventory and blueprints are also linked.

I don't see how is this a problem. (Maybe some implementation problems?) From gui perspective this seems trivial, just add "this is linked to library" clickable text to the blueprint overview that will open the library version.

What happens when you put your linked blueprint into a chest, is it still linked?

It could become unlinked the moment it leaves inventory / action bar. Or just stay linked all the time. Again - why is that a problem? Any advanced (e.g. related to library) blueprint functionality will have to be explained in tutorial / multiple tips anyway, so why not just document the exact behavior and not treat any potential question as a "problem". (I mean - pipes are much worse anyway)

What happens when your linked blueprint in a chest is picked up by another player?

This is mostly just repeating previous point. And this has several easy fixes - either make the blueprint read-only, unlink it when someone other than creator modifies it . . .

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 how exactly would this scenario occur . . . (I mean circular dependency)? There would have to be explicit feature to link blueprint already in library to another one in the library . . . just don't do it?

Of course I am biased because I use blueprints heavily in my megabase and most of the proposed solutions would make some things I do all the time tricky or clunky. But really don't rush this change, especially with such poor reasoning . . .

EDIT: I hope it will be allowed by mods to keep the old system, else this would make me postpone the update indefinitely . . .

[irbork]

I like the last proposal the most.
I only miss the store-able blueprints, not because I used it so much, but because I always dream of a mod where you can put a blueprint into the chest and all the required items will get requested in requester chest. But for this modders can create some new item (Blueprint Request Order?) that will be used only for this purpose.

[FrodoOf9Fingers]

I'm a fan of the last option.

Though, I would very much like to see a "profile" system attached, such that you have the quick bar setup the way you want in one game, but can have it different in another game. Even in the middle of a game, being able to change profile during a playstyle transiton (to being train based, for instance) would be super awesome.

Keep the global blueprint library, but just add a check box next to the name field of the blueprint determining whether the blueprint is "global", or able to be copied from the library to a different profile. Or have some other system for sharing blueprints between profiles.

[torvawk]

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.

I am agreeing with this, in fact, I was going to post my own posting but found this first. I think you are right, all blueprints need to be linked. But you already have game specific blueprints and global blueprints. An item blueprints always need to be linked back to one of the two. In MP games you may have to limit it to the game specific ones. That does open up the chance of having version differences between the game blueprints and your global ones. However, I think what you need is a replace feature of the blueprints. I think if you like enable a drag and drop from global to game blueprints, there should be an option to replace an existing blueprint or add it as new. Maybe default drag is new and ctrl or shift drag is replace? That way you can assist the UI based on the modifier key.

Again for single player games, you can have links back to blueprints that are either game specific or global. For MP games it must link back to a game-specific blueprint. As this poster said, it would still allow in-game sharing of blueprints as items and context blueprint storage as well.

I also agree with the multiple action bars. I know my action bars evolve as I go through the game. Implementing the above should allow you to implement the action bars as either game specific or global which would limit which blueprints can be linked in a particular action bar. UI-wise how to keep a clear distinction of the action bars may mean you need to tie the blueprint system and the action bar system together somehow. Maybe you have a "bars and blueprints" UI and the bars are actually linked back to the UI. That way just like the blueprints you have game and global blueprints you can link, you would have game and blueprint action bars you could link to.

As to introducing them in smaller chunks, maybe you can tie it to some technology. There is a second toolbelt technology. Well, that could introduce the multiple action bars and the game and global specifics of it. Blueprints gets tricker as many want them from the beginning as a means of communication before you get bots. I can only suggest maybe an optional mini tuturial when construction bots is unlocked.

[RobertTerwilliger]

If you want people to select - create a poll.
I'd vote for #4.

[Agamemnon]

Hello,

I registered just now just for this very topic. I don't really like any of the proposed solutions, because I think, you are missing an easier, more elegant solution.
Sorry, if this comes over as condescending (I get that sometimes, because english isn't my native language) it is not meant to be anything else than a lighthearted suggestion:

You are right in your analysis that having blueprints that are a reference to the library and blueprints that are physical items are two very different things. My suggestion thus is: truly separate them!

Make a new category of item that fulfill the role of blueprints in the gamespace but name them "Plans". Make them have icons on a papery background for easy recognition. They can be dropped, copied, given to other players... whatever. They are just items and behave as such. Especially: They are not linked in any way to the contents of the blueprint library.

On the other Hand, you have the old "Blueprints". With a blue background. They are just referencing data in the library and cannot exist in gamespace at all - only in the library, where they exist as unique objects.

Now for the interaction between the two: If you drag a Blueprint into the hotbar, or inventory or any other place, it becomes a plan instead. If you drag a plan into the library, it becomes a new blueprint/overwrites an existing one(with prompt, please!). And if you want to get rid of a plan that clutters your inventory... you just drag it into a little trashcan icon. Oh, right... I forgot: I really wish Factorio had a trashcan, finally. Not the logistics one. One that can destroy items for good. I rarely need it, but every time I do, I am sad that in order to really do that I have to put down a chest and blow it up.

Oh, and for the ease-of-use copy and paste clipboard version: Good Idea, but make that a separate feature and all you need is a button in the blueprint library UI to "create blueprint from last selection" and it would be fine.

/my 2cents.

[Allaizn]

Expand on the action bar concept of mockup 4 to having an possibly infinite amount of "additional" pages.
I haven't had the case yet, but it's incredibly easy to gather even 100 books (which then wouldn't leave any space for "normal" stuff): "Rail Compendium for 1/2/3/4/8 lanes right and left hand", "CarGo yellow/ red/ blue", "TankGo yellow/ red/ blue", "Belt Balancers yellow/ red/ blue", "Belt based Science Early/ Mid/ Late game", "Bot Based Science Mid/ Late game" are 26 books and I didn't even try that hard to come up with them. Add to that multiplayer, where I may meet with another player with a "complete" set and we'd want to compare? And don't get me started on modded, where I'd like to have even more books (even if you seperate the libraries by mod versions without ending in a total mess)
It's of course not your everyday blueprint library, but enabling infinite amount of books doesn't hurt new players, but it hurts me if you restrict it on a whim.
Apart from that I like the fourth mock up quite a lot, especially that it's persistent across saves! So here's my own improvment onto it:
Let's start with an image, since that's way better than any words I could come up with:

Visible on action bar open, pink means transperant

MockUp1.png (149.59 KiB) Viewed 6270 times

• Such a list opens on key press of the current [Switch Hotbar] key, which I'll denote as [X] from now on, and begins selection of a new page, that is always boxed in a red thing (make it not just a border, but a bigger, bulkier thing to help those with color blindness & bad lighting on the screen). The selection is aborted with [Shift]+[X], a click away from that GUI (e.g. on the world). Everything else, that's not listed down below is regarded as a confirmation, and closes the GUI. This includes for example the movement keys.
• It's mostly the same as the mockup of proposal 4 in the FFF, but there are a few differences:
  1. I copy pasted some graphics of the recently shown palette (just to get a better feel for the look)
  2. The action page number should visually be much smaller than in the FFF mockup: it shouldn't get the attention of the player unless he wants to find it, so why waste screen space by making it huge and player time by therefore making it distracting? (My mockup is still too big, but my paint skills couldn't do better)
  3. Make the numbers much bigger than they currently are, and show them! The player will know which item he put there, but the count is relevant for many cases. Displayed numbers would allow players to take a quick look in here to ascertain if they have enough of that item for the next outpost/ factory, without the need to manually count item stacks.
  4. Scroll bar for potentially inifinite number of pages!!!
  5. Split the upper 5 and the lower 5 to bring a little more order into the whole thing. Finding a certain slot by row number and column number, as well as finding the row and column number of a certain slot, is much easier in a quadruple 5x5 than a dense 10x10 array.
• Scrap the current multiple toolbars, and instead display the n most recently used pages. Highlight those pages: keep the number of highlights constant, regardless of the amount of toolbars, and low. More than 4 highlight will look cluttered IMO. Repeated presses of [X] cycle through these, e.g. first time [X] opens the page selection and highlights the most recent used page, second [X] highlights the second most used page etc.
• Pressing a slot hotkey after the first [X] press (and only then!) selects the corresponding page and closes the GUI. [Alt] + Numpad could allow for the multi digit case. It's okay to break here, since only experienced users will ever get that far, and they'll then naturally sort the most important pages to the top, and less frequently used ones into the tens, or hundreds.
• [ArrowUp]/ [-Down] scrolls visually 1 up or down. [Shift]+[ArrowUp]/ [-Down] does 10, [PageUp]/ [-Down] does 50 (100?). This is useful once there's more than 10 pages.
• Allow copy/paste of slots via [Shift]+[Right Click] -> [Shift]+[Left Click] on the slots. Same for pages via their number field. This makes it much easier to set the pages up in the first place, and modifying them also gets easier.
• Make a "blueprint trashcan" in form of a blueprint book that stores all the blueprints dropped by "Q" without deleting them. The user can then either empty the whole bin by deleting the book, or recover the necessary blueprints. This will be way more convenient than any algorithm that tries to predict which prints to toss and which to keep.
• Maybe add a big display button that enlarges each icon of a row to 2x2 to make blueprint/ -book visualization and ordering easier.

I'd also suggest to make [Shift]+[Right Click Drag] the copy, and [Shift] + [Left Click Hold] the paste (where pasting is done on mouse key up, and aborted with [Shift] key up), that allows it to be much more streamlined with every other copy paste in the game.

Edit: oh, I kinda went more into a discussion of the action bar than the blueprints, but I think its important nonetheless

[teekyman]

My thoughts in order of priority:

1. I strongly dislike blueprints as items. The clutter is too much. I haven't played multiplayer, but I see no reason that blueprints *should* be put on belts or in chests. There should be a more sensible way to share blueprints, like with a search function.
2. I like the quickbar as actionbar idea, with the ability to switch between multiple action bars and a persistent action bar across multiple games.
3. I like blueprints and items together on the same action bar. I might want, for example, to keep blueprints for mining setups alongside miners themselves, if I want to make adjustments.
4. I'm not sure I like the loss of a blueprint library, since having all your blueprints in one place is nice, and I don't see a great way to move blueprints between books without a library. If you keep the library, I like blueprints-as-references more than out-of-sync blueprint types.
5. Since different mods might need different actions and blueprints, 30 books/10 bars may not be enough for people who play lots of modded games (unless you have sub-books, but that makes the UI more cumbersome when scrolling through a book). I'd want to have an "action bar library" so that you can manage/scroll through many action bars, load up the ones you want for the game you're playing, of course with the ability to attach a name to each bar to make it easier to pick out the ones you want.
6. I haven't played multiplayer, but it seems like Proposal 4 leaves no way to share blueprints between players without constructing/copying. This is another reason to keep the blueprint library (or have a sharable action bar library and let people share action bars).


TL;DR Mostly proposal 4, keeping the blueprint library or maybe with an "action bar library"?

[sinsiliux]

I don't particularly like any of the options, mostly because they still treat blueprints as items to some extent. My proposal would be:
1. Get rid of blueprints as items completely.
2. All blueprints go to blueprint inventory which is very similar to current blueprint library: left side - blueprints of this game, right side - shared library. It opens with "B".
3. Blueprint inventory size is unlimited, with scrollbars if needed.
4. Clicking blueprint in blueprint inventory doesn't create an item. Rather it creates a special blueprint instance. This instance can be used to create ghosts for building multiple times and then dismissed with Q. Dismissing unbinds it from cursor, but still keeps the original in blueprint inventory.
5. For blueprints you need access often - you can move blueprint to quickbar.
6. Two options for multiplayer sharing: either there's dropdown to see other players' shared blueprint library or just share or blueprints of this game (left side of inventory).
7. Add ability for mods to interact with blueprint objects so that current blueprint mods can be updated and would still work.
8. To create a new blueprint you click a button in blueprint inventory and proceed same way as you would now.

The only minor downside is that people will have to get used to clicking "B" instead of "E" to interact with blueprints.
IMO it solves all the problems developers and forum users laid out.

[SkullTitsGaming]

I would suggest a modified version of proposal #1, in which next to the 10 Hotbar slots( implemented however y'all see fit) there was two more slots, one triggered with the "B button, and the other (for deconstruction) triggered with, say, SHIFT+B or the like.

Upon pressing B, the most recently used blueprint shows up. Pressing B again (or some other access method) opens up a customizable file tree, in which folders (like the previous books) are listed, and contain as many subfolders as the player requires, until eventually coming to bottom-level blueprints.
I imagine something like this:

Code: Select all

+Add Blueprint...
>Bobs/Agnel ONLY
>Trains
>Science
|-->Red
|-->Green
|-->Military
|--|-->1 SPM [Blueprint]
|--|-->2 SPM [Blueprint]
|--|-->10 SPM [Blueprint]
>Defenses
>Combinator Magic
>Bus[Yellow]
>Bus[red]
>Bus[Blue]
...

After selecting that blueprint, it remains the most recent. Perhaps allow mouse wheel to also scroll through the list, as well. Either way, it puts blueprints into their own UI area, clearing up inventory clutter.

Questions to be answered:
_How do I Share my blueprint with a friend?
Perhaps just select it and press Z to create a temporary copy which degrades over time; if the friend doesn't pick it up, it gets left in the dust. Or, have a third slot that fills when shift-clicked by another player which holds a "inbox" queue for potential new blueprints to file within a player's own list.

What if I want to delete the blueprint?
Open the blueprint tree by pressing SHIFT+B. Select the blueprint you no longer want, and click delete (or edit, if you prefer).

I use at least 2000 blueprints and this seems like a lot of scrolling.
That is not a question, but choosing how to more efficiently organize your own blueprint system is up to you. Also, how the hell did you use 2000 bluepri--- actually, forget I asked.

What about blueprint-like mod items, like Upgrade Planner, or Ore Eraser?
Implementation would likely be up to the modder in the end, but perhaps adding the ability for modders to add extra slots to the "blueprint bar" would help solve this issue; else, the eraser/upgrade planner items simply remain their own items.

I use the recursion mod to build my bases grey goo style/I use FARL/What about mods which rely upon blueprint items for their functionality?
Perhaps a) allow for an in-container GUI to open the blueprint library and save a copy to the blueprint slot of a container, b) allow for the creation of blueprint items if a mod maker needs it.

How do i share my amazing and totally unique Kovarex Enrichment Process blueprint with Reddit?
Inside the GUI you click "show blueprint sting" just like always. Importing works the same, only under the "add blueprint..." option.

[Cobolt]

I like the look of option 4 myself. This also means we can setup an action bar for specific tasks and can easily swap from deconstruction to defense for example.

[Teprifer]

I was just thinking about this issue just last night! Slightly creepy, but carrying on...

My vague thoughts were along the lines of the hot bar idea, except not attached to the toolbar, instead a little bar on the left side.

This would be a scrollable up/down vertical toolbar only 1 icon wide.

In each slot would be a book, mousing over the book would expand out the contents of the book and you could select a blueprint to attach to your mouse (NOT an item).
Right-click would allow you to edit the blueprint, original thoughts was in the current blueprint type dialog, but how about re-using the tutorial creative mode type screen to make changes to a blueprint?

This would very tightly show the link as a persistent blueprint library. To edit an existing blueprint right-click it, to make a blueprint of something in the world you'd click a 'new blueprint button' (or key bind!), drag over the area in question as you do now, then the current dialog would pop up, along with a request for which book to put it in, or to create a new book.
It could also offer the option to edit the blueprint as outlined in the above description.

This could tie in with the ctrl+c and ctrl+v idea you're referring to.

Another nifty idea would be to have a 'best of' button, this would be for belts, splitters, undergrounds, inserters(type for type, basic inserters vs stack vs filter), in which regardless of which type was in the blueprint, placing it would put down the best level you have access too.
This would enable re-using blue belt blueprints in early game when you only have access to yellow belts! This would greatly reduce the number of blueprints required and number of changes to make as you progress through the game.

(Just attaching to this, an easy way to upgrade all belts and inserters of a type in an area by dragging a box around it would be very very lovely!)

A slight variation is to only have one icon visible on the bar and on mouse over it quickly expanded down for those who don't like too much visual clutter.

I look forward to the changes regardless!

[Therax]

How would Proposal #4's concept of a persistent action bar work across different saves? If I have one save where I'm megabasing with blue belts, and another where I'm still using yellow belts, do I need to reset my shortcuts every time I change maps? What about multiplayer servers? Different sets of mods in different maps?

[dbpag]

I think it would be good to have a blueprint bar like in proposal 3, but the integrate it with the blueprint library, so that the library is a sort of inventory of blueprints. Then, when you go to the blueprint library, it works like the main inventory, except used for blueprints (and books).


My thoughts in a list form:

• The blueprint library should stay
• There should be no blueprints in the inventory
• There should be a blueprint bar instead(which can also contain books)
• The blueprint library should work like the main inventory
• All blueprints in the bar would be synced to the library

[RodrigoCns]

I use 1 book for each category (science, oil, smelting area) but i've seen videos of people with more than 30 books. Concerning proposal 4, i think that depending of the amount of mods that add content, 30 books could be a low number...

And about proposal 3: YEAHH keep it simple!!!
There would be a GUI element constantly reminding and promoting the new players to use blueprints, AND about the default 1-10 keys... just use Alt+number or Ctrl+number or a combination of them. Holding said key (Ctrl or Alt) and scrolling will scroll through the pages created.

[Reika]

How would Proposal #4's concept of a persistent action bar work across different saves? If I have one save where I'm megabasing with blue belts, and another where I'm still using yellow belts, do I need to reset my shortcuts every time I change maps? What about multiplayer servers? Different sets of mods in different maps?

This was my main issue as well.

[shadetheartist]

Proposal 4 for sure. I feel the that this solution solves the most problems, simplifies the system, and does the least amount of harm to the existing player strategies. (sorry whoever is storing blueprints in chests).

The one thing i think needs to be considered is a mechanism in which to quickly share blueprints *as if* the blueprint were an item of sorts. Perhaps being able to drag & drop the blueprint from the action bar onto a player, which then goes into a free slot on their action bar. If their action bar is full you could notify each player that the transaction could not be completed.