Friday Facts #249 - Dead end exploration

[shadetheartist]

I don't particularly like any of the options, mostly because they still treat blueprints as items to some extent.

5. For blueprints you need access often - you can move blueprint to quickbar.

Your idea really muddles up the concept of the blueprints not being items, since they act like items.

[Teprifer]

Reading posts on sharing blueprints, specifically one blueprint in particular to someone, a shared 'drop box' style area.

Other players could then use it, and import to library it if they wish to keep it outside the MP game.

[gravityStar]

*deleted*

[QGamer]

Proposal #4 is pretty cool, but:

The second problem that might be the fact, that you can't make a blueprint "just for this game" without putting it into the library. I personally don't see it as a problem, as the whole point of the blueprint library rework is to avoid the problems of merging two kind of storages of blueprints. This would force the player to have only one.

There are times when I want to use certain blueprints only once (i.e. just for this game, maybe I'm trying to shift something a few tiles over). I don't want the blueprint in my library because I'll never use it again. Whichever option you choose, I'd like to have a way to use blueprints temporarily, just in this one game, without having to worry about the library.

A second thought: what are you going to do about deconstruction planners?

[Philip017]

i personally would like to keep blueprints as items, but yeah they really shouldn't clutter up the player inventory, the blueprint only tool bar seems like a neat idea, but being able to use the existing toolbar seems like the most straight forward approach.

perhaps instead of when pressing Q (clear hand) it dumps it in your inventory, it should instead be placed in the blueprint only tool bar, or in the library section. if i want to share/store the blueprint i can quick transfer it from my hand into a chest and someone else/myself later, can then pick it up and use it. it becomes an item in the chest but not an item in your inventory.

having all the blueprints in one place for all vanilla games is all fine and dandy, but what happens when you switch between modded and vanilla games, i have to keep the blueprint books in my inventory for that modded game because otherwise my modded items in that book get deleted when i switch to a vanilla game. this is utterly frustrating and even more so if they are only stored in one place. so this problem needs a solution before i can trust all my blueprints to one location.

a possible solution to the modded items blueprints is if a blueprint requires a modded item, it becomes unavailable if the mod is not active, or it has a special warning about missing modded items, yet stores all the modded item data for when you reload the mod. it could be possible to make a copy of the blueprint with the modded items and have the ability to replace them with vanilla counterparts. example upgrade planner will allow you to change belt, inserter, assembly machine types. it would be very handy to have this tool added as part of the blueprint management. also some form of mirroring the blueprints as well. i know it will be a lot of work but worth it for me. upgrade planner has certainly been a staple mod in any modded game i play.

[Epic_Wink]

What about putting all blueprints in the blueprint library. Each blueprint has a location (current save, current user and current server), which can be filtered, and copied to any other location. In the library view, you have a user specified (directory-like) tree structure, with blueprints, folders and subfolders.

You can drag these blueprints to the action bar (as virtual items), and use them as normal. When updated, the game will ask if you want to update the library version, or create a current-game copy.

I still think you should have many spare action bars to access

[mcdjfp]

Can I vote for leaving things alone. While there does seem to be something "clumsy?" about blueprints, most of these ideas run into two problems.

1. Linking blueprints to their library entry is a very bad idea, at least from my point of view. I will frequently make a slight alteration to a blueprint before placing it. I do not want these 1 use changes transferred back to the original. While there may be workarounds, I am concerned that they may be worse than the present situation.
Example: I have a uranium station for outposts with a uranium train, a sulfuric acid train, and a passenger train stop. In one game, there was a uranium deposit next to an already developed oil field. As a result, I grabbed my uranium station blueprint, removed the unneeded passenger station and stamped it down. Then I deleted that copy as it was not needed anymore. Under the linked blueprint system, the original would no longer exist as it would have been updated as I made changes.

2. A persistent hotbar is useless to me. I want a different hotbar for each save. First, my early game hotbar is different than my late game hotbar. If it is persistent, then every time I switch saves (say between a late game mega-factory, and a newer save I am working on) I will have to reset my hotbars. I will go from setting it up once per game (required anyways as a hotbar carried over from my last game will be designed for unresearched items) with gradual updates as research is completed, to having to set it up every time I switch saves. That is definately not an improvement. Then there are mods, and each mod combination will need its own persistent hotbar because of modded items (What happens when an item/blueprint doesn't exist in a particular set of mods?) Of course if a persistent hotbar is forced, every time I load a set of mods I will have to rebuild my hotbars by hand due to the invalid items. Either way, the hotbar isn't really persistent, and I have likely gained an annoyance.

I do like many of the other changes/ideas from recent Fridays. It is only this one, and the previous hotbar related Friday fact that worry me.

Edit:
Personally I like the idea mentioned a couple of times earlier where there would be two types of blueprints. The blueprint in the library. And a second temporary blueprint that would only exist in that specific game and would ask me before updating the original. Perhaps when deleted it could ask it I wanted to sync the changes or not (defaulting to no).

[host65]

Vote for proposal 3.
I usually change mods between games so almost no blueprints are reuseable and i make new ones each game. The only one i copy is the rail blueprint. Therefore 10 is enough

[zebediah49]

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.

As a note: I (and probably a few other people here) play on a laptop. With a touchpad. While the touchpad scroll emulation works fine for scrolling through pages, it is extremely difficult to scroll exactly one "click" to change around a blueprint book. Either you don't scroll at all, or you accidentally go 3-5 entries forrwards. If I want to scroll-select a blueprint, it's easier to open the book (so I can see where the green highlight is) then use that info to know how to scroll to get there. At that point it's usually easier to just pull a copy out and destroy it afterwards.

---------------------

I have a few -- as far as I know not thusfar posted -- concerns as well:

1. Revision control. Currently, it is extremely easy to irrevocably destroy your blueprint library. I personally keep filesystem-level backups of my blueprint-storage.dat, just in case. This can be due to switching game versions, switching mod sets (in earlier versions), or even just... mistakes.
2. I really like the ability to see other user's blueprints. I could see maybe wanting a "public" section or something, but that is nice and I don't see how that works with the "get rid of the library" thing.
3. Varying sets of mods can have completely different blueprint requirements. Forcing a single "blueprint namespace" onto players is very awkward for that, as you are forcing the player to keep completely useless content cluttering their workspace. Placing the "big pile of blueprints" behind a second access layer makes the first time access somewhat more cumbersome (one extra context switch), but has the benefit of making every other access more efficient since your first layer is not cluttered with things that shouldn't be there.


I would like to see a mechanism to better manage blueprints, including
- blueprint editing (this would reduce some of the requirements for replacing)
- complete blueprint version history
- search (perhaps even tagging?)
- Online share? Not sure if you want to go there.
- display of blueprint status (can make, can't make because research is not done, can't make because mod is missing)
- ability to select a blueprint as your "Ctl-C" copy target, so that it pops up upon ctl-v. It's only one more "quickbar slot" type thing -- but I think it would be useful.

In other words, I like a somewhat hybrid "blueprints area not items; all blueprints that you use are a link to an entry somewhere in the master library" approach.

-------------

EDIT:

Proposal #4 is pretty cool, but:

A second thought: what are you going to do about deconstruction planners?

I'm in favor of a VIM type solution: you delete things by using ctl-X to "cut" the section.
- press Ctl-X; get deconstruction planner activated
- deconstruct target
- this results in what you just deconstructed going to a temporary blueprint location. Maybe like the past 5-6 deconstructions are stored as temp-blueprints in your library "trash".

[KNOWFEAR1337]

After reading it all i like option 2 the best, and you could disallow two blueprints that are linked to each-other in the library but i LOVE the idea of the library and books being a grid that you get to arrange yourself to find then more easily.
but even if there was no linking just being able to overwrite a blueprint book in the library with the one you have in-game would be nice

I personally dont use them, but mods that allow people to automatically place blueprints might be a little sad if they cant anymore

[5thHorseman]

tl;dr none of the above or an amalgamation of the above. Blueprints should not be objects. Ever. But the interface should allow you to use them in an object-y way.

Here's my ideal blueprint interface:

• Hit B. A blueprint gui opens. It can be much like today's without anything alluding to blueprints being items. And you shouldn't need to have "this game's blueprints" unless you want them. In muliplayer, there can be a shared folder that everybody can see.
• Grab a blueprint or book. Blueprints can be populated, empty, or destruction. Books can contain populated or destruction prints, and there is an empty book option as well but only if you're holding a populated or destruction blueprint.
• Within this gui is a hotbar of X items. You can put blueprints and books in there so they're very easy to get to by hitting that number while in the blueprint gui. B-4 will open the gui and then grab the 4th blueprint on the hotbar, and return you to the real world. This gives the ease of hotbar blueprints without taking up your real world hotbar.
• If you're holding a populated or destruction blueprint in the gui, clicking a book (populated or empty) will open that book so you can put the blueprint you're holding into it, and edit the book (name, image, order of prints inside)
• If you're not holding a blueprint, you can still right-click a book to edit it like above, just without putting anything inside.
• Right-clicking a blueprint allows you to edit it in an endless flat plane, with options to rename, change icons, maybe even test, whatever.
• Hitting B in this interface will return you to the regular world.
• If you're holding an populated blueprint, a book, or a destruction blueprint you'll have the same interface as you have now.
• If you're holding an empty blueprint when you exit the interface, you'll be able to use that blueprint, and once you highlight some of the world you go right into the blueprint editor, and once out of there you're back in the interface to put it in a book or whatnot.
• Hitting B in the "real world" with a blueprint in your hand drops that blueprint (though it still remains wherever you took it from in the blueprint gui) and replaces it with whatever you were holding before.

In short, everything is done with B and there are never blueprints in your inventory. They are all very easily accessible at any time, though, in the blueprint gui.

I'm sure I missed a dozen things but I truly think this idea is the single best one. As everybody else thinks of their own ideas

[kovarex]

A lot of people asked how blueprint would be transferred between players if it wasn't an item. Simply by the chat as described in more detail here (https://www.factorio.com/blog/post/fff-237).
You would just open chat and drag (click) the blueprint there (note that you can either write to general chat or whisper). Anyone clicking the icon in the chat gets the blueprint to the cursor. From this point, it is the same as creating the blueprint yourself, you press q to remove it, or move it to the library etc.

[BenSeidel]

Hi,

tl;dr - the issue isn't with the current system, just the way you interact with it.

Great post. It really highlights some of the complexities of design decisions that go into creating a good UI.

I find that the current system is "close enough" in that the issues that I have with it are usually associated with other issues, not the system itself. For example, having my inventory full of "temporary blueprints" is solved by having a copy-paste system.

The main issue with the blueprint library is the ability for someone to find what they are after. The current view is probably the worst you could think of. The MOST important part of any blueprint stored in a library is it's name, not it's icon. How many times do you have to see a rail icon to realise that it's not important? If the view was changed from a thumbnail view to a list view (like MS Windows explorer's list/detailed view) you would find the usability would shoot right up. Couple that with a search box and you suddenly have a much more usable interface. It would also make it more clear that the UI does actually sort it by name and that it's name is important. It would also allow for much longer names. The current "limit" of 10-15 characters is just too small. By the time you put some type of "category prefix" on your blueprints, you can't see what the blueprint actually is! eg "rail outpost - Copper" shows ups as "rail outp..."

As for some of the changes outlined in the various options put forward:
I think that blueprints as-an-item are essential. If you have a big blueprint library then it's easier for you to find what you're after than for someone else to find what you are trying to describe in chat. (Kovarex solved this issue with his item-in-chat solution) I also use blueprints as-an-item to archive. In many of my long maps I have chests around all with the previous versions of builds. This way if I ever realise that a previous version could be used again, I have them.

As for a maximum slot limit: I would HATE it. I already have 6 "installations" to deal with multiple mod setups and I will be very unhappy if you guys go to all that trouble of implementing mod synchronisation to at the same time effectively limit me to only 5 books per setup.

If you just look at the list of issues you are dealing with and deal with each one individually, you will see that the issues aren't inherent to the current system but are just superficial issues with the way the user interacts with the current system.

1) Clicking the blueprint in the blueprint library means creating a blueprint:
Then don't create the blueprint? You could do one of two things. If you can now do drag & drop (It wasn't an option due to the libraries your using but with the rewrite it may be possible?), then make a blueprint by dragging and dropping it into your inventory and put it into the copy-paste buffer when clicked on (in the "active paste buffer" as if ctrl-v had been pressed and a selection made).
OR (my personal opinion)
the copy mechanism is the only way to make a blueprint. If you copy (either by clicking on a blueprint in your library OR by ctrl-copy->make selection) it makes a "temporary blueprint". This blueprint, when cleared gets destroyed. If instead of clearing it, you click on your inventory/quickbar THEN the in-game item is created. It also has the added benefit of having ctrl-v recall the last blueprint either copied from the map or copied from your blueprint library.

2) Blueprints getting out of date in the blueprint library.
This isn't the issue. This is actually 2 issues, so deal with them individually.

2a) Not being able to get access to blueprints in other games
Is this really an issue? I'm of the opinion of: I don't know. It doesn't bother me that much that I have to swap maps to get access to a blueprint that I "forgot" (or didn't realise that I would have to) put into my blueprint library.

2b) not knowing what blueprint is the most up-to-date.
Again I have to ask: Is this an issue? Are you making a dumbed-down game where every mechanic is easily understandable to its full extent? or are you trying to make the basic functionality more user-friendly? How about putting a created date timestamp then? Then new players could see if one blueprint is older than another. I personally have solved this by adding "version numbers" to my blueprints: I append v.xx to the end of my blueprints.

3) The standard way of putting new blueprint into the blueprint library just puts it at the end of the blueprint library
Umm, no it doesn't. It's sorted alphabetically. The issue is: If the developers don't understand this then it's an issue with the way that information is displayed/conveyed to the user!

4) Once new players open the possibility of making blueprints, it opens many things at the same time for them
Again, not quite right. You have blueprints & deconstruction planners right from the get-go. The issue is that it's a little button right up in the top of the screen, next to other (seemly informative only) buttons. Move the button NEXT TO THE QUICK BAR!!! (better option to follow).

5) Other UI annoyances such as exporting and importing blueprints through the obscure "Drop here to move blueprint" box.
Then do the same type of UI as the transfer between chests & user inventory? Or as you were/are looking at a "tab" system https://www.factorio.com/blog/post/fff-191 put the blueprint library as an extra tab (so accessed by F4).

p.s.
Sorry, this ended up being much longer than anticipated.

[OmegaStorm720]

I recon this change would be fine if we were able to make folders and sub folders not being limited to only book. (Maybe add chapters to the books or something or even better just introduce folders

[ultra695]

I'm very torn personally on this and other blueprint issues.

My biggest problem with blueprints are:
- Inventory clutter from single/little use blueprints
- Unwieldiness in the blueprint library, especially when working with books in the library.

The proposed solutions have some good and some bad. The updating of blueprints in the book is not a problem for me, but I can understand why it'd be a problem for others. I feel it should absolutely not be solved by directly linking blueprints to the library objects, here's why. When I make blueprints, they are generally annotated with additional information such as belt inputs, power poles, movement directions, speeds/throughputs, and similar. At any given time when using the blueprints, I'd remove some/all of the annotations before I used them to build because I don't actually want them built. Or I would just cut segments off because a wall/rail blueprint would be too long for example.

If blueprints were direct links to the library I wouldn't be able to do any of that. I highly support blueprints as items, or at least item-like as opposed to library links. To prevent clutter I think blueprints not already in the inventory (e.g. made from world or library) would be deleted on Q press, while blueprints in the inventory would be returned there. I have no attachment to having blueprints usable by inserters/belts/bots/chests so that's why I say item-like, but they should be editable separately from their library versions.

There are many posts here about separate blueprint-only inventories, I think many of these ideas have merit and fit well with blueprints as item-like entities.

PS BenSiedel's response (made while I wrote mine), is excellent.

[TheVeteraNoob]

I feel like easily overwriting to the library isn't the way we should go.

My proposed idea for the pile.

-keep blueprint items: It is the most intuitive way to give blueprints to other players. Especially when you have a lot published.
When it is given to another player or chest I think that the auto update idea should turn off. I can just see some very annoying trolls coming from that.
Blueprints picked up by other players should automatically be stored in their own library. But like.... In their own category.
-Force unique names on blueprint books. New books could be called book01 book02 etc. More in next part.
-Add tags to the blueprint creation tool. Tags will automatically add to blueprint books with said name. When you don't pick one, it goes to an unsorted book. That being said though. The tags agent actually stored in the blueprints. So that way if you give somebody a Bluetooth book it doesn't make 30 books because of all the tags.
-Add revision control. When you overwrite a blueprint. (I'm thinking drag one blueprint into the corner of another one.) It still saves the old one kinda making a pseudo Blueprint book.

While there will be introduced clutter in the unsorted sections using this method any idea of auto saving Bluetooth world need extra clutter to prevent losing everything by mistake

[ekimekim]

Just wanted to say that in my current MP server we use the server-side library heavily.

Transferring blueprints as physical items, or using chat, is horrible by comparison. It relies me and the other player to be online at the same time, and to explicitly sync.

Compare putting a blueprint in the server library, where another player can come along at any time and grab the blueprint they need.

Needing to sync via chat would probably just lead to things like "We need to lay down more green circuit factories, but only OtherGuy has that blueprint, can you tell him to do that next time he's online?"
Oh, actually what we'd probably end up doing is laying out every blueprint as physical items in an unused area so they can be copy-pasted as needed. This feels really dumb compared to the current solution, which works great.

Personally, I'd like to see linked blueprints that are read-only, with the option to "unlink" to make editable. I agree editable linked blueprints would be too confusing.

[StahnAileron]

While you're at this with the blueprints, could we get something similar for Deconstruction Planners? (Or just integrate them into the Blueprint system?)

Since Decon-Planners can have filters, I find I would want to have several of them with preset filters... But I won't because it would clutter the player inventory. Granted, the filters are more or less very situational, but there are a few I would like to keep handy (Just trees, just belts, just power, just inserters, etc.) A "Decon Book" or equivalent would be kinda useful, IMHO.

Otherwise, I find myself wasting time setting filters and resetting them afterwards all the time.

[zebediah49]

A lot of people asked how blueprint would be transferred between players if it wasn't an item. Simply by the chat as described in more detail here (https://www.factorio.com/blog/post/fff-237).
You would just open chat and drag (click) the blueprint there (note that you can either write to general chat or whisper). Anyone clicking the icon in the chat gets the blueprint to the cursor. From this point, it is the same as creating the blueprint yourself, you press q to remove it, or move it to the library etc.

Does that not incidentally remove any kind of asynchronous collaboration option though?

With the current system I can drop a blueprint in the game storage, and it's still there when I log off and someone else logs on. It's still there an hour (or ten) later when someone decides they want to use it.

If, say, you have five or ten "how this world is arranged" blueprints (say, preferred trainstation designs, etc.), that would have to be manually synced to each player by someone sending them all. That player would then need to accept those blueprints (into their permanent storage!?), whether or not they are relevant at the moment, just in case they might need them in future.

That seems rather unnecessarily cumbersome.

[kamiza]

I'm hoping that since fff-191 was mentioned TWICE, that these action bar ideas are still being thought about.
I really like the idea of not having 2 separate inventories and being able to see the full amount of the items.

Also, I'd vote for blueprints to NOT be items. We can already transfer them so easily.
It is getting annoying that half my inventory is filled with blueprints and they get out of hand quickly.
The quick copy-paste clipboard would be a welcome change too, since that is what tends to happen most often.
And it does take too many clicks to delete a mistakenly-made blueprint (which could/has resulted in deletion of the wrong blueprint and loosing a bunch of time)
I agree with the linked, it should only have a library and always saved immediately. Less remembering to save a new one or an edit and forgetting to re-save it.