Friday Facts #249 - Dead end exploration

[Grand]

For me option of no blueprint items sounds best but instead of having 2 different kinds of blueprints all blueprints should go to library with ability to change scope/shared status between this game only and all games

[Melerion]

There are mostly two distinct types of usage for blueprints:

1) the copy a small section to make something larger

2) the stamp down a previously engineered solution for use in a new map or different section of a map


Personally I see the blueprint library more as sort of a subversion/git repository for components, however big or small they may be.

Also, any blueprint is more or less just a representation of what is (or was) on the map.

As such I think it might make sense to link a blueprint to the coordinates of the map it was taken from, that would allow for an "update" button, that takes another snapshot of a previously taken area. This would solve the duplicating issue for me: say I have this awesome belt creation facility that I want printed: I make a blueprint. Later I improve on it - I can update the same area without having to delete the existing one and create a new one. (maybe highlight the area on mouse hover over it).

The map is basically the trunk of the repository, a blueprint for me is a check-in of something specific.
If that idea has merit, it would make sense to be able to duplicate a blueprint to make a fork/branch of it. That way if something is upgraded to - say red belt or further - I can snapshot the same area again.

But it would be beneficial if any blueprint in the library were global: at present I checkout a book for use in the game, update what's in it, and then rename it to increment a version number I always add - so I know which one in the library needs to be removed after the updates have been checked in.

So I guess this post isn't a clear cut answer to any of the options presented, just my take on things.

[Recon777]

For me, one of the biggest headaches is managing modded blueprints.

I play modded (Bob's) most of the time. But I also play vanilla on occasion. If I do a vanilla game, my modded blueprints all have a big "?" on them and are invalid. They clutter up my space, which makes the creation of a tidy "vanilla blueprint pack" impossible.

What's worse is that when I save, the next time I load back up, those invalid blueprints have had their missing items removed. Then, if I switch back to modded play, the blueprints are screwed up. The only way to resolve this seems to be to go into the root folder and manually make a backup of blueprint-storage.dat for modded play. Then keep a separate vanilla blueprint-storage.dat and paste that into the folder when I want to play vanilla. This manual juggling of files is something I am sure the game devs do not intend to be a required aspect of the game. It would be good to have a way to manage multiple modded configurations, as each mod combination is going to have its own unique set of blueprints.

[SuperSandro2000]

Don't you dare to change my hotbar.

[MostlyNumbers]

Copy/Paste sounds great.

Another thing I'd recommend, regardless of how it proceeds: there should be no empty BP items, only a button or infinite stack for a blank sheet. i.e. if you clear a BP then clear the cursor (press q) there's no reason to have empty BPs cluttering up inventory, library, hotbar, whatever.

All this talk of syncing all my BPs between saves sounds like a recipe for massive clutter. I just don't need every BP I've ever saved in every game. Perhaps it'd be okay if loose BPs are lightly buried in book for that save, but even then I have tons of saves.

As to the proposals, Prop 3 sounds closest to what I'd love to see. I think BPs shouldn't take main inventory space, and should be easily accessible from some sort of hotbar. But, limiting storage to 10 slots would be a disaster. Instead, I'd love to see a more intuitive library GUI

[shaman]

I prefer Proposal 4.
The simplicity of sharing both the action bar and the blueprints in one UI unit between games is just genius.

[QuirkyCat]

3 or 4 seem ok to me but please make the action bars movable.

[Dixi]

I vote Proposal 3. And it will be better if will be an option to move blueprint toolbar to the side of main toolbar (on the left / on the right).

I play MMORPGs a lot. They all have many different toolbars, and ways to switch them. Me, and, as I know, many other players never use an ability to switch toolbar pages. Several or many toolbars - yes, but switching - no. So I'm against proposal-4.

In whole I don't like that a blueprint is an item. It might be useful for multiplayer, to share them between players, but in solo play I keep destroying them by putting in the chest and shooting, since blueprints cluttering my inventory.

[canisin]

Hello, here are my couple of cents:

1) Get rid of blueprints as items.
2) The last proposal seems to be the best.
3) Allow us to store blueprint books within each other like folders in a filesystem.

[Gergely]

My only hope is that whatever solution they use, I don't necessarily have to share all of my blueprints with the server when I play in multiplayer.

Remember the times when server operators could delete blueprints from any player at any time and cause THAT to carry over to each player's private saves?
It sucked. I believe it was only ever done in an experimental release though.

[Engimage]

Omg you hit the hornet nest with this FFF again But this one in a positive way.

I will try sum up my thoughts on this.

Starting from the action bar.
So the action bar (toolbar) as a whole is a set of LINKS or SHORTCUTS to different objects. Quite the same is actually relevant to hypertext links in chat with hover hints/click implementation. So I think they should be discussed together.

So here you should decide what should be happening in the case of you hovering mouse on top of it, clicking and rightclicking respectful items.
While the point of toolbars tells you that there should only be links to items (in discussed topic blueprints in a library) we come to a dilemma how can we link it in chat if players in MP have different blueprint libraries. Same goes with the ability to import/export toolbar presets which will make pure link items irrelevant in the case of BP library differences. So it seems like storing blueprint data in a form of an embedded string looks like a good idea to me.

The only issue in this case is syncing its contents with the blueprint library itself in case you change the BP from within a library so your toolbar gets updated. Here I do not see the need having 2 different types of links. There just might be an optional link to BP library item UID. So the toolbar or hypertext link might be like

Code: Select all

<Link type="blueprint" ref="player\8645754" icon="electric_furnace.ico" textdata="udhgfbxoq2ygbxcoqo8wyegfbc">Blueprint Name</Link>

And on event bp_library_item_changed() you update toolbar items with the same id that was modified in the library.
If ref field is empty then BP is standalone and will not update with the library. This might happen in case you clicked a player linked blueprint and drag-n-dropped it on a toolbar. Or used a BP selection tool (one you plan to use for Ctrl-C) and moved created blueprint to your toolbar instead of BP library. You might add a notice in the hint for the BP that it is contained in the library (+path). So this part is similar with proposal (2) except relates to links and not BP items. You might also add some small overlay icon reflecting this is a linked item (like windows has that arrow in bottom right corner).

I am looking forward to a toolbar implementation and personally I expect it to be as multiporpose as possible containing whole different sets of objects like items, player actions (oh yes all those aim items replaced), modded custom actions, blueprints and whatever else you can think of. That is why I would not like BP toolbar being something different like you propose in (3)
As a good game you can consider implementing several sets of toolbars which you might move across your screen all with configurable orientation - horizontal or vertical, with a set number or rows.

I do not support the idea of making a toolbar being exclusive storage for items themselves like you are proposing in (4). Toolbars are limited in number and serve a purpose of making a limited number of actions to be accessed in a quicker fashion compared to normal means. Making it a huge storage might not be a positive concept overall. In this case you also lose the ability to form your shortcuts risking losing items on your toolbar while moving them between storage/active links or being forced to switch toolbars when you need to access blueprints. This also prevents you from having multiple links to the same item on different toolbar slots in the case you want this.

To sum up I support your (1) proposal with slight improvement to remove unnecessary complication of having 2 different types of links.

As for the library itself I would prefer a generic tree structure to save the data. You might provide the link to a tree node (folder) instead of a "blueprint book" as a tool for grouping blueprints together. Same with export - you could export any tree node no matter how many subfolders or items it has. Hell you could even make it a real folder in filesystems with subfolders and blueprints as files This would make creating BP links even easier! Just an idea

[madeof_tin]

Idea for an Easy way to differentiate blueprints that exist on the bar and blueprints that exist in the library but are references would be to borrow from desktop shortcuts.

Blueprints with the an arrow like this being a blueprint that is referenced in the blueprint library.


Blueprints without an arrow would be ones where the data is stored in the tool belt.

Would be really nice for me to tell which is which right from the UI.

[Lubricus]

I often use Blueprints when i "need" to move a section of the factory 1 tile to the left or similar situations.
It's now quite cumbersome you first have to
1. create a new empty blueprint. ctrl+B.
2. blueprint the section you want
3. find the deconstruction planner
4. deconstruct the part of the factory
5. find the blueprint again (wherever it is hiding...)
6. put down the blueprint.
7. stove away the blueprint Q.
8. find the blueprint again
9. delete the blueprint

I don't know how to fix it but think about these situation when making the new system.

I have never purposefully put any blueprints in boxes or belts so I think it's OK if blueprints as items get's removed. I like the idea of everything as "physical" items you have in your hands, tool-belt and inventory(quantum backpack?) but it get's cumbersome when building....

A mayor hassle of the game is finding stuff in my inventory. When I think about it it's strange there is no help for that like search and/or tabs as in the crafting menu and everywhere else. With mods like bob's/angels it gets even worse with so many different items just in a big heap. And that the items move around in the inventory don't make them easier to find.

[Engimage]

Really neat idea to implement a selection tool and further actions on selected area.

• Hold shift to activate selection tool and drag the rectangle to select. You can implement filters on selection tool.
• Press Ctrl-C to copy, Ctrl-B to create a blueprint, Del to mark for deconstruction.
• Have an orgasm

You can pass selection to mod API for any custom actions on it.
Also provide mod API to change selection filters.

[AcolyteOfRocket]

Time for my message in a bottle to be thrown into the sea

1. I would like to see blueprints-as-items retained in some small way in vanilla (I have some high hopes for mods in this area). If Q is pressed just delete the blueprint in hand. If you are worried about folks being annoyed about doing this by mistake, add a trashcan with an undelete function.

2. Linking blueprints seems to me to be a terrible idea - accidentally causing a blueprint in a library to be changed is going to make someones head explode, and probably much later into the future to boot.

3. It would be nice for each blueprint to have a visible hash based on the contained items and their position and orientation. This way it would be easy to see if two blueprints were identical instead of having to strain my sanity checking each component of two similar looking blueprints before deleting one.

3a. It might be even nicer if the blueprint hash was numbers only - now it can fit into the number dialog of a combinator entry and who knows what clever stuff might follow on from this.

4. There is no master library - there is an "In Player Profile" collection, there is an "In Save Game" collection and there is confusion.

5. If you managed the blueprint using a little file interface you could have an intuitive management system based on the OS of your choice - making it graphical for the sake of it seems like more work for both devs and players. I would like to be able to open two (or more) blueprint books and simply move blueprints between them. Listing is good enough for this imho and I suspect would be ok by others if the list ordering system was reliable and logical.

[Triaxx2]

Alternative. Add a new bar up by the minimap, which expands to the left and has 6 slots. This is the only inventory place Blueprints/Books are allowed. They can still be placed as items, but if you pick them up and the slots are full they go back into your library instead of continuing to exist as an item. Make it a collapsible bar, so if you're not using them, it's not taking up screen real-estate. Maybe also add a deconstruction planner as a permanent item up there.

[Demongornot]

Nice FFF !

Sync the object blueprint with the library is nice, but what if I want to modify it to make some experiment while keeping the original intact ?

So here is my proposal :

_Keep blueprint as an object.
_Allow for right click to open a contextual menu with several options : Link/unlink, separate, refresh, reset, modify, copy, delete.
_When putting from library to toolbar or inventory, the blueprint is linked, but we can unlink it with the contextual menu, so we can now freely do what we want without worrying about the original.
Of course we can link it back, if another blueprint is already linked, we have a message to choose if we want to take over the link, it must also allow us to compare the two and the library one.
_Separate mean that the blueprint is now definitely unlinked and is just a regular object blueprint, and the option Link/unlink become "Upload to Library".
Upload to library will warn if the blueprint already exist and allow for renaming or erasing. It should automatically separate when leaving player inventory/toolbar.
_To know if the blueprint is linked, unlinked or separated, it can for example have colour code around the edge, for example :
Blue mean standalone, red mean unlinked and different from library, green mean unlinked and identical to library and white mean linked.
_Refresh allow for unliked blueprint to manually change the original, this way we can still easily make changes without having to worry to corrupt the original in case of errors while still having easy way to update it.
_Reset is a shortcut to : "Delete our modified blueprint and take a new one from the library". It will simply erase the inventory version and take back the library version.
_Separate option don't appear when already separated, Refresh and Reset only appear when unlinked.
_Modify simply open the tool to modify it.
_Copy mean creating a new blueprint object identical to this one, but nt linked to the library.
_Delete should only delete the object obviously.

Also blueprint should be a early semi automated construction, I always find the beginning of the game too slow because of the lack of early automation.
Having robot earlier is of course not a good idea, but we should have the ability to hand build ghosts, including connections and parameters/recipes/modules.
There is many ways to do it from clicking on the ghost automatically put the item down when we have it on our inventory, automatically construct nearby ghost from our inventory with a key, having a zone tool 'like grenade for example) which construct ghost from our inventory etc...
This way, not only they would be part of the whole game, not just the late game, but also since new player will simply learn blueprint from start as an alternative way to construct.
Blueprint, library, book and deconstruction planner will feel like a part of the game that allow easier construction which make repetitive schema (like a smelter and it's inserter & belts & power pole) less frustrating to do.
The blueprint will by seen as a tool rather than a simple in-game object, and transitioning to robot will now feel like an upgrade and will be quite easy to understand, also this way don't change at all the game balance.

[Kueller]

I would love either option 3 of 4. The constant hassle of BP's as an item is not fun for me. Sharing BP's could just be done via export > chat

[Killerhuehnchen]

I'd prefer proposal #2, since in a normal game I have several blueprint books depending on stage of the map. Even if I build a new layout I still use a lot of blueprints or to correct small things (off-by-one errors, found more efficient layout,...).
So in my library I have a lot of blueprints I rarly use but keep around, and these would clutter any inventory or limit their use. Good design tries to work without hard caps.
To minimize the problems, you could have a player library with ingame bluebrint books beeing linked to them, while when dropping/storing them in chests, etc., they'll get transfered to a server library and linked against that. This way there wouldn't be different types of blueprints, just different owners/library links.
When an other player takes a blueprint out off a chest it'll still be linked to the server library, but they'll have the option to move it to their own.
Creating a new blueprint would link it against the server library until move to player one's. Creating a copy could work the same way, with unlinking it, if moved out off one's inventory.
And while you're reworking them, please don't let them rearrange themselfes depending on which blueprint is currently selected, but by name/id of book. I hate having to search my inventory for the blueprint book I need.
Regarding #1: The quickbar hasn't enough slots as it is, having to waste it's space with blueprints would be horrible (I only have the decontruction planner in there)
Regarding #3: Only 10 blueprints? In a normal game I often have up to ten blueprint books and a random assortment of blueprints I'm currently working with. And I often build in seperate saves and copy them over, so I use the library often.
Regarding #4: I never toggle through the quickbars and having to switch through ten just for one item I need at the moment would be annoying, and having them open (stacked) is a waste screen space, there's engough space to its sides

[MisterSpock]

I just want to add that deleting a BP Book by accident is also annyoing. You can easiely missclick on delete.

Hope this will better with the GUI update.