Logistics, Virtual Toolbar, Modular Containers

"Well, I'd point out that logistics and mass and volume aren't just feature creep; they're essential to future systems (like automation) and to proper balance."

#480
geostar1024, Saturday at 2:28 PM

I am just pointing out that it needs to be a lot simpler and just work without making the player work.

 

I agree. The logistics system would be much easier to use if the portable constructor linked into it, if we had terrain-placeable containers, if placed constructors selected a container by default, and if we were automatically connected to all structures within range and could place blocks from any of those inventories. More specifically:

 

So far, I have enjoyed the new logistics system; there are just a few things I would like to contribute to the conversation.

1. Item slots in containers: as far as I can tell, no matter how many container extensions you have chained together, the container controller is currently limited to the 8x8 grid that you see on screen (no scroll bar when it gets close to full). Even though I have 30,000 additional volume available, I can't add anything more to the container array because I already have 64 items/stacks.

2. Maybe I missed where it was explained in the patch notes, but the methods of switching from the player toolbar to the logistic toolbar confused me at first. I didn't realize you could use T to change, and then later figured out that if you have a number selected and then press that number again, it switches (e.g., #2 selected on player toolbar, press the 2 key and it switches to the logistic toolbar). While I like having a couple of different ways to switch, I'm also concerned that it could be too easy to panic in combat and spam a button twice and inadvertently switch to the logistic toolbar instead of the desired weapon.

3. While it appears that volume isn't incorporated yet, I found that when I had an array of modular containers (same controller) that was overloaded, every time I changed the number of container expansions, all the excess cargo was dumped into a drop container which had to be looted and returned.

4. I found it odd that while I had my drill in my HV container and was using it via the logistic toolbar, I had to have the fuel/charge item in my player inventory in order to reload.

5. There seems to be an issue where the fabricator's progress lags, and I have experienced this as well. Not a problem per se, just a quality of life issue.

6. Renaming containers: for hours I didn't think that I could, only to eventually discover that I could do so in the Control Panel -> Devices menu, but then only if the containers were added to a group. Being able to rename containers while they are "Ungrouped" would be nice, if for no other reason than allowing them to keep their name if they are removed from a group (currently goes back to default name when ungrouped).

7. Finally, a friendly suggestion to consider. While the drop-down menu system works well enough, it could be greatly enhanced by adding a tab-page system to it. That way players could choose to either use the drop-down menu or navigate through tabs of containers on either side of the logistics screen. Either a 2-tier tab system (e.g., [Player - Hover Vessel - Base] on an upper level and [Container Controller - Container Controller (Ammo) - Fridge 1] on a lower level under Base) or a combined system with prefix-suffix (e.g., [Player - Base(Container Controller) - Base(Fridge 1) - Hover Vessel(Container Controller] etc.) could work.

 

The logistics system isn't too bad, it's actually quite time saving in certain cases, but there are some issues with how it defaults to the wrong things. I think there are some cases that weren't tested much, especially the ones were you walk up to something and hit f rather tan F4.

It seems to be more of an early game issue with walking up to cargo containers on your HV etc and hitting f.

For a while the selections were not "sticking" (remembered) like they should have been but for some reason that seems to be working now. For some reason I kept getting the fuel tank showing up on the right side every single time no matter what I had selected last time.

It's really not very clear at first especially where recovered blocks and such are going. An explicit menu for "send recovered blocks to:" might be helpful here especially since you may want that setting remembered separately from whatever container is selected on the right.

There's a lot of wasted space on the constructor UI screen and I keep feeling like you really ought to be able to move items in and out of the input/output containers from there without switching screens. I know there are locking issues but that should be solvable. Other games manage to handle this in multiplayer or with multiple things competing for the same objects.

Player inventory or a selected container could go on the left, input could go on the top middle, output could go on the bottom middle.

I think the separate menu for oxygen and fuel is a little awkward. I keep expecting to see those in the container list.

 

Suggestion!

Currently we have 2 player base devices that work automatically:

1. the Furnace
2. The Deconstructor

(as long as they are powered on and fuelled or course)

What is missing is the ability of some form of auto construct setting for Advanced Constructors. I suggest that it should be possible to set an advanced constructor to auto build mode for a single selected device/ammo/item/etc. When the auto build mode is selected, it will keep chugging out the same build recipe over and over at infinitum This would only be limited by fuel and raw materials and cargo space to out put finished product into.

This extra mode, together with the logistics , would allow the creation of complex builds. For example you could build a ammunition factory that would link furnaces output, to a bank of advanced constructors input, which then in turn each auto build the specific individual components (using the proposed auto mode), that output into the input boxes of a final single advanced constructor, which assembles the specified ammunition type.

there you have an automated hi speed factory!

… A simpler version of course would be to just put all the ore into a cargo input box of a single advanced constructor, set to auto build and it would slowly spit out the selected product, built from the ore up.

One approach is far quicker, but takes more space and consumes more fuel.
The another is slow, but fuel efficient and covers a small footprint.

It provides a player choice and creative possibility


I imagine that such an auto build mode can open up some interesting build projects. Though I would not suggest that this feature would be available on the lower tech tree constructors.


I feel this would plug the gap that many players are requesting in terms of greater automation, without requiring (from the non coders view!) a too significant change (I am assuming that as this is basically utilising the functionality of the furnaces, the code should be reusable).
Picture to illustrate one basic process flow, that would utilise an Auto Build Mode:

 

This would be ok, but far better would be signal logic integration: specifically, the ability to set a recipe in a constructor and the ability to detect how many of a particular item was in a cargo container. Then not only could you have a constructor auto-build a particular item forever, but you could have it keep building until a certain number of items were in a particular container, and then switch to another recipe. With the right setup, this could let you build all the components of a ship as well as fuel and ammo for it; all you'd have to do is assemble either by hand or with the factory (and eventually, when the factory is integrated into the logistics system, the ship could be built and spawned in automatically as well).

 

@SacredGlade @geostar1024 Automation discussion should probably go in its own thread, especially as it hasn't been implemented yet. This is Logistics.

 

My 2 cents... and that's all it's worth... I am done with this game over this logistics insanity.

I worked for a company once who thought it would be a good idea to turn the engineering dept into the accounting division as well. Instead of designing machines with modeling software we spent half our day or more in spreadsheets, databases, onenote and other garbage better suited for the low paid data entry people in the office whose talents and potential topped out at repetitive, tedious tasks an average chimpanzee could be trained to do.

They didn't get many machines out the door and although they are still in business, it's much smaller than when I left and they are struggling to keep the lights on. Maybe they should have let their engineers be engineers instead of trying to turn them into accountants.

The analogy is that you took a fun game of building and exploration and turned it into a cross between a poorly designed tax preparation program and a sim game.

The entire concept is tedious, clumsy and annoying. It takes far more clicks and menus and endless drop downs to get the most simple tasks accomplished. I hate the way it looks, I hate the way it works, it is ascetically unappealing and ruined the look and feel of thousands of bases in the workshop including mine.

I hate it, I hate everything about it. The implementation of weights and volume will only make an already untenable situation worse. It is a complicated, tedious mess as it is and I can't even tolerate another session of it without the volume implementation. I have no intention of sticking around for even more frustration, I play a game to have fun and this one is no longer fun.

 

@Ranger_Ric With proper use of the logistics, you should be cutting your inventory transfer clicks...by almost half. Could you describe an interaction that takes longer, so that it can be looked at and streamlined?

I think the biggest thing is if you want to move something bigger than your inventory between two boxes there's no way to do it without going through the menus (or repetition). Maybe there should be a way to "Left Open" and "Right Open" with modifiers on the F key for interacting with a device... Then you could use physical proximity to bypass the menu system and quickly get both inventories on-screen.

Edit: Okay, this is a good point-

Takeaway: We need concurrent access so that the cargo box views for constructor I/O can create the same level of convenience (lose the LOCK ICON, become real inventory slot views) in simple setups.

Yes, there's a button to access the boxes. That's clearly not enough to avoid headaches and frustration.

Nevermind... I forgot that even if you could interact with (basically just rearrange) those views, you would still need to have another inventory open for I/O. There's no way around it: Full Logistics view is required for I/O...and that creates an extra step.

 

Viewing the contents of a cargo box locks the constructor out of it, just like how one player cannot access a box at the same time as another player. We need concurrent access implemented across the board. Control panel and everything therein while they're at it. Each interaction can be a delta transaction rather than a copy-modify-overwrite-state-lock...but it requires coding to handle the latency state and prevent duping. Inventory should be tracked server-side anyway...would've prevented many of these dupe bugs over the course of development.

 

This is a huge point, both for introductory tutorials and ongoing status visibility. Players need to feel that they are working with a larger inventory, an extension of themselves...and it should be liberating!

Right now many people feel like the logistic UI is getting in the way, despite the fact that it makes things more convenient than ever before.

-------------
​

The question we must ask is: How can cargo containers be made to feel like a natural extension of the player? A source of strength and flexibility rather than a source of confusion and pain?

We're halfway there, now that player inventory is properly kept in the same location, and there is better memory of previous interaction... The logistics UI no longer actively fights you in adjusting, but it needs to be even more natural.

-------------
​

Edit, to echo @NimrodX's point again: The connection to the box, and the feeling of items going to/from the connection, needs to be clearly displayed--perhaps as an extension of the Character screen which guides the player to the full Logistics screen? Could get messy, or it might work well...depends on the details of how it's done...

Also... Using a hand-held device/tool from within a logistic connection is cool once you get used to it, but...dangerously immersion-breaking and a serious mental hurdle.

 

I have reconfigured my keys a long time ago... what action is "T"? in the options control selection?

 

If I go into a constructor to make make stuff but first have to go into a container to put resources in it and then go into another (or the same container again) to get the finished components out of it, that is three interactions instead of one. Don't tell me it's quicker to do those interactions through drop down menus and switching, it isn't. I can click in and out of containers subconsiously and when I do, the stuff I need is right there in front of me, I don't have to dick around with pulldown menus. Every time you use a pulldown, that is two clicks, not one and it takes a greater amount of time to use it than the general mouse pointing you did under the old system.

When I open something, be it a container or device, I expect to see my inventory on one side (the correct side would be the logical place btw). I don't want to have to operate a freaking pulldown just to see my inventory every single time when it should be there already when I clicked my use key. That's two extra clicks right there just to get your inventory on screen along with the container you opened... three clicks instead of one.

That is just the tipity tip of the iceberg of hate I have for this new method and interface. It is way, way overly complicated, tedious, confusing and time consuming to use.

The old containers being large and small in CVs and bases were logical, the bigger ones took more space and held more. Secondly, there are places in CVs and bases that the large cargo boxes fit better than little ones or visa versa. Sometimes it was for the look and feel, sometimes it was a building requirement but either way, you pretty much wrecked that for thousands of bases already in the workshop. Harvest boxes, cargo boxes (of various sizes and types) and ammo boxes added aesthetics to builds that can't be duplicated with the generic, ugly new boxes. Want to change some large boxes around in an old build or lose one through attack or accident... too bad, can't replace it. I didn't spend hours and hours designing a base to live with it looking like crap because the cargo boxes don't match. And no, it's not just a matter of issuing a few replaceblocks command... there was often a reason large cargo boxes were used instead of small ones and that reason frequently had nothing to do with the storage capacity.

A properly designed base is now going to need at least one and ideally two cargo boxes sitting beside, above or below each constructor (and food processor, and deconstructor, and furnace). Do you have any idea how many bases already exist have the space to do that (in a practical and visually appealing manner)? About zero if they were an efficient design to begin with. No, it's not ok to just pick a couple boxes out of the ones already there, that's not ok at all.

 

Makes sense. Constructors probably won't regain inventories since there's no guarantee that the volume requirement (I preferred stack sizes, for the record, but the same problem could occur with a reduced number of slots) will be met.

However: The second half of my comment, quoting @paxxo1985, was about exactly what you're talking about with extra steps (especially if you're adding material at the same time as crafting)...and I fully agree (as mentioned there).

To reiterate: The cargo box views on the constructor screen should allow direct, non-blocking access. The boxes will still be required, but at least people won't have to switch screens constantly.

asdf...Nevermind. This won't solve it, as mentioned in another edit above:

 

I feel like you could probably get away with 4 distinct containers: input for all constructors, output for everything except food processor, fridge, and input for deconstructor. Now, that does depend on inventories losing their 64-item-type limit and becoming scrollable and sortable, but that needs to happen anyway.

In any case, I agree that modular cargo containers (both CCs and CEs) need a range of designs/textures available so that they look good when integrated into structures. Honestly, I'd get rid of the distinction between the old-style containers and CCs, and just let CCs take on any of those models.

 

Don't forget the need to have crushed stone products separated so that you don't accidentally burn absurd amounts of it in a horribly inefficient attempt to create scraps of ore if when you run out of various metals.

 

I really hate it when that happens. I think those should be have to be manually activated!

 

Sorry, i missed that. But i still don't know what action i need to keybind ("T" but I've bound "T" to something else...) to toggle from what i'm networked to, to my normal toolbar. I did see someone post about selecting something you already have selected and it switches over, but that fills clunky and prone to error.
EDIT:
I went to turn on my lights... and instead of turning on my lights the toolbar toggled.... guess i found it?