Logistics, Virtual Toolbar, Modular Containers

I know this is a big order, but think that we need to simplify and rework the container system some. First off I would remove the differences between Ammo, Harvest, and basic. Realistically we don't really use them any differently anymore. Both Harvest and Ammo boxes are being used as generic storage much of the time.

Next, a rework of CC and CEs. They are confusing. Make it so you just have Large and Small containers, conforming to the size and shapes of large and small blocks, with matching space. Each container is it's own storage space and doesn't use energy, but also does not show up in the logistics menu. Container Controllers create virtual storage groups in the logistics menu and gives the ability to sort items. Any container touching a CC is grouped into a logistics container group. And CC and Containers can touch without any problems, since CC's just create virtual storage groups, that is it is just a way to see and access a bunch of containers at once.

So that if I have this setup all in a line:

Container(1)-CC(a)-Container(2)-CC(b)-Container(3)-Container(4)

With:
Container(1) has 4000 volume and contains 1 Doodad
Container(2) has 4000 volume and contains 1 Gizmo
Container(3) has 4000 volume and contains 1 Whatchamacallit
Container(4) has 4000 volume and contains 1 Thingamabob

I get in my logistics menu:
CC(a) - has 8000 volume and contains 1 Doodad and 1 Gizmo
CC(b) - has 12000 volume and contains 1 Gizmo, 1 Whatchamacallit, and 1 Thingamabob

Then you can select a CC from the Control Panel you get sorting options. I could then go and add a CC(c) on top of CC(b) touching the same containers as CC(b) and it would have the same items in it, but I could assign it a different sorting method. It would be nice if the sorting methods could allow for some complexity, or even allow some type of RegEx expressions for complex sorts so I could have a CC that showed me just Ammo, blocks, or Food. Maybe instead of RegEx just add metadata to every item to use in sorting? Like a hashtag type system? It seems that items already have some sort of classification, just expand on that? Then it could use tick boxes or have like 3 dropdowns that we can use to limit what is shown. So that if I leave everything to (none) it shows me everything, but if I put Dropdown1 to (Ammo) I only see ammo in that virtual storage group, and if I have Dropdown1 on (Ammo) and dropdown2 on (weapons) I see all items that are ammo and all items that are weapons in that group.

What to get even more fancy you could change the refrigerator to a decorative Controller with a built in sort and add instead Storage-Large (Refrigerated) and Storage-Small (Refrigerated) that can be used like any other storage unit, only food doesn't spoil in it, and it has a energy cost.

 

Agreed, particularly for ammo boxes. Getting rid of harvest boxes is a little trickier, as you'd need some way to designate a storage container as a harvest box. On the other hand, one could simply make all boxes harvest boxes (which is actually what I usually do in my designs now).

I'm not sure right now if allowing containers to be shared between multiple groups is a good idea or not; something to think more about . . .

 

How realistic would it be to be able to make 'folders' within the a storage box the same way it's done in ARK? I like the scope of the modular boxes, but I HATE having to either have one massive lump storage, or having to physically space the container clusters apart to get different storage sections for different purposes. I'd rather have one big cargo hold, but there needs to be some way to organize it, and something like a folder structure would be excellent.

 

Haven't played in a few months, and wanted to try out all the new stuff! Wow! Logistics is terrible. I'm confused by it and I've been playing since the game was released. I can't imagine a new player trying to figure this out. After finally figuring out I needed to place a container to set up an input and output for the small base constructor, I almost died from overheating because I couldn't figure out how to get back to my normal toolbar to place an AC unit.

Also, why can't I build elevator blocks with that small base constructor? Makes no sense, or they've been moved somewhere and I can't find them. Sigh...

EDIT: This is a first impression. I will leave more feedback after learning how to use it.

 

Given the repeated changes after patch 9 with the actual cargo boxes and locations in the device list, I no longer understand what boxes are valid for the volume/logistics system.
Today I want to learn about the CC and the CE but this thread is not so forthcoming on usage of the devices.

First I would like to say, if a new player gets empyrion today, even if volume was activated, they would not have a single clue how to use container controllers or extensions.
If that new player was me, I would be pretty annoyed to find myself here for the first time and still after reading this thread I do not understand how the CC and the CE works, there needs to be some simplification of this system.
Perhaps a faq thread where we can add a detailed description of new devices as they are released, with full info on where and when they should be used etc etc

Anyway I have some questions that need answering, when i have this knowledge I can spread it far and wide especially on HWS.

1.
SV devices "Cargo Box" which gives 4 choices of box, what is the purpose of the standard container that only takes 25 su ?
Are all these containers valid with logistics ?
Or do I need to replace containers on existing builds.

2.
Cargo controller, after reading the op I still dont know what its for how it works how it activates, what benefits, nothing on this forum about what a cargo controller does.
To me its a block without a purpose so please explain that to me, what scenario would require me to add a cargo controller.

3.
cargo extension ?
Obviously the extension is to give more su into a cargo box, I attached one to a box but it did not increase su.
Do I need to activate volume in the games config beforehand for those containers to actually show the su figures change within the boxes after adding extensions?
Or am I missing something else ?

4.
do I need volume active if i want to build an entity in creative, setup for the new logistics system ?

I want to start building some stuff that is properly setup for the logistics and volume system.
I guess I cant hide from it forever haha, time to learn, and they say the only stupid questions are unasked ones so here I am ^-^

 

The cargo extenders work with the cargo controllers. Which let you build a cargo box as big as you need

 

The old cargo boxes seem to mostly be in the game for legacy support. You can not 'extend' them. They do seem to work with logistics but they will be limited since they can not be extended. I have no idea if they plan on removing them in the future or not, but overall I would not use them in new builds.

The Cargo Controller is the actual box that you put stuff in. Placing it creates a storage space with a set amount of space (a 8x8 grid), there is only one shape of Cargo Controller. The Cargo Extender adds to the max volume that space can hold, but does not increase the maximum number of slots to put stuff in. Cargo Extenders come in multiple shapes and the amount of volume added is based on the shape (but the weight and HP of it is not). If you have volume limits off then the Cargo Extender does nothing but make a number bigger.

They only work with Cargo Controllers, not the old style Cargo Boxes. It does not increase the number of slots, just the volume it can hold, which is shown at the bottom right corner of the box's storage user interface.

I would not bother yet, even though they have pushed this to the stable build it is still too experimental to know what the final version is going to look like. The odds are anything you build now will have to be reworked each time they made changes to the system, which is happening regularly.

 

Updated Impression:

After fumbling around to figure out how stuff works I really like having the constructor be able to use separate boxes for inputting and outputting items. I can now separate my resources box and crafted items box.

The place this function is most useful is the food processor. Having my food output to the fridge is awesome. I hate putting away left overs in real life, so not having to do it in a game is great.

Accessing the logistics menu with F4 is cool, but it would be much more immersive to access via consoles/control panels.

Still not sure what the virtual toolbar is for. I never used it once, but maybe when I figure it out I will like it.

Haven't gotten around to using the container controller and custom containers. Still not sure how this is better than just using the normal storage containers?

It would be very helpful for beginning players to slowly be introduced to this new system. Perhaps the new logistics menus don't actually appear until you place a console to access. So when you first start the game the old input output system is used. Place a console in front of a constructor and you can now access the new/current logistics system.

 

Placing blocks directly from storage (bar doesn't count toward your inventory volume).

Also, while it's active, picking things up (including plants) puts them directly into the connected inventory.

 

Fun fact: if you're in a ship and you attach yourself to a storage container on your ship, you can then place blocks from the comfort and safety of your cockpit. I've been meaning to design an SCV with this mechanic in mind.

 

First of all, you either have a typo there or you misread. The standard "Cargo Box" for the HV or SV has an SU of 125, which is quite a bit more than the 25 SU you stated. Indeed, this is every bit as much volume as the new Container Controller Units (CCU's) and Container Expansion Units (CEU's) as these also have/add 125 SU.

As for the purpose of using a Cargo Box in post Alpha 9 SV/HV blueprints, I can see a couple good reasons. For one thing: It is impossible to put connected CCU or CEU directly adjacent to each other without them interfering. That is, CEU's placed adjacent become connected. And the game prevents us from placing more than one CCU adjacent to a connected network of CEU's, so we always have to either leave space between them or insert unrelated devices. However, there's nothing to prevent us from inserting a standard Cargo Box in between separate CCU/CEU networks. Granted, the volume of Cargo Boxes can not be expanded like CCU's. However, for holding a bunch of individual small items or really small stacks of some POI loot items, a single Cargo Box might be adequate. It's when we try to carry around large devices and stacks of blocks, or tons of ores or ingots that a large volume becomes essential. (Sadly, a CCU has a fixed 64 item slots, regardless of how many CEU's are connected, meaning we can potentially run out of item slots before we run out of volume capacity.)

There is another advantage to using a Cargo Box over a CCU/CEU network: (1) Cargo Boxes 1, 2 and 3 have a volume capacity of 250 SU, or twice that of the small one or of a single CCU or CEU. That is, to hold 250 SU would require 2 regular "Cargo Box" or a combination of 1 CCU and 1 CEU. But while Cargo Boxes 1, 2 and 3 only consume 1 PU of energy and hold 250 SU, the equivalent CCU/CEU for 250 SU would consume 2 PU of energy or twice as much.

Granted, CCU's and CEU's (for the SV/HV) only weighs 50 kg, while the old Cargo Boxes typically weigh about 3 times as much for the same volume. (Cargo Box 0, 2 and 4 weight 150 kg and Cargo Box 1 and 3 weigh 300 kg. However, Cargo Box 2 holds 250 SU, despite only weighing as much as the much smaller Cargo Box 0 or 4, meaning it weighs only 50% more than CCU's/CEU's for the volume.) If weight is a big issue for your blueprint, CCU's/CEU's may be the best bet. However, a lot of CCU's/CEU's will consume a large amount of energy - likely much more than most players realize.

I used to also think that the Cargo Box was left in the game purely for legacy purposes or to help with the transition. But I now doubt this, especially since we can still obtain Cargo Boxes through the Creative Mode's ItemMenu and since we can still create new Cargo Boxes through a Constructor.

There are other "obsolete" containers in old blueprints that, while we can still build the blueprint that uses them in Alpha 9, we are unable to build the container in a Constructor in Alpha 9 or even find them in the ItemMenu in Creative Mode. For example, it is now impossible to create a "Harvest Box" in a Constructor and they are no longer available in the ItemMenu. Similarly, the old "Ammo Box" for the HV/SV is unavailable from both Constructors and the ItemMenu.

As such, I now doubt that they currently have plans to remove the old Cargo Box down the line. Though, I'm pretty sure that the Harvest Box and the HV/SV Ammo Box are gone for good.

Yes, having food output go directly to the fridge is very handy. However, unlike in previous versions, the Food Processor (as well as Constructors and the Furnace) do not have any storage volume at all. Worse, quite a few templates at the Food Processor call for both ingredients that spoil and those that do not spoil. And since we can only have one INPUT, this often means storing large stacks of Stone Dust, Plant Fibers, Water Containers, Purified Water, Elemental Pentaxid, Nitrocellulose, Alien Thorns, Alien Tooth, Alien Parts, Alien Plasma T6, Alien Plasma ZR1 and Nutrient Solution in our Fridge. With all of this stuff that does not need to be refrigerated in our Fridge, there's not a lot of room left for the perishables.

This could be alleviated if we could only designate more than one INPUT. But, alas, this is not (yet?) possible.

 

I would expect these discrepancies to be corrected in the near future. I'd be very surprised if the devs intend there to be any substantive differences between normal cargo boxes and storage arrays.

 

I originally posted this in weight/volume but given that it's totally about the cargo containers, I'm moving it here:

For starters: I love the volume and weight system.

However, on the balance end of things we need to discuss the power consumption and potential CPU issues I see coming with regards to containers.

First, the current power use needs to be re-examined in two ways. As one person said to me: I've never had to plug in a cardboard box. And while that's taking things a bit far, the point is valid. I do concede that with, basically, what amounts to a mobile cargo teleportation system, having power and cpu being tied into it makes sense. You've got computerized scanners and inventory tracking automated into the containers with the ability to 'beam up' whatever you want from where it is to where you are in a fairly large area. However, that 'beaming' ability is being paid for in terms of cpu and power with the wireless node, not the box.

Second, the power being charged to the system is too high. Previous cargo boxes are set at 1PU per box. That means a 16,000 SU box (double cargo old style) runs 1 PU, whereas a new style container and extension is 20PU for the same storage. That level of disparity is unacceptable. If you plan for people to adopt your new system, which you are already getting push back on, you must not penalize them in terms of power use for doing so. Reducing the power consumption back to 1, or maybe 2 PU per unit is more favorable to encouraging adoption of the new system. It could be argued that 1PU per block is still double what we were, on average, spending per cargo unit before with double boxes only running 0.5 PU per 8,000 storage. A x20 penalty for adoption of the new system is unacceptable.

CPU usage is also too high. A 7500 limit on the core is fine, but everything must be balanced to that limit. Given numbers I have already run, a cargo transfer base should be expected to run 345 cargo containers minimum to hold max volume-stacks of all 16 base materials. This is 17,250 CPU worth of storage. Not to put too fine a point on it, but you can store and operate a real time inventory of the entire planets supply of crude oil on an Apple watch. Trying to tell me that a 2m x 2m x 2m cube can't keep track of ore sitting in boxes is patently ridiculous. Inventory management simply doesn't require that much CPU. 50 CPU per box extension is at least an order of magnitude too many, but reducing it to 5 from 50 would be a good start. If you wanted to return to the argument that this is a system with effectively teleporters and matter transmission systems, that's fine, leave the base container unit at 50, but reduce the extensions to 5 each, then. I'll buy that argument.

These are my thoughts for now on the CPU and power use issues with the volume/weight changes. Other than these problems, I am quite excited by the new challenges that this system has introduced into the game and it's something I've waited for since pre 2.3 or so when I started

 

The reason behind all these controllers and extensions escapes me. We already have (had in 8 and 7 and before) a natural center for a general cargo on a base or a vehicle - a constructor; for refrigerated goods there is a food processor. Why do these appliances see their respected storage as separate entities? The constructor should see all cargo boxes as a single entity with multiple pages or a scrolling list of cells. You need more volume? Add several boxes. Any box gives the access to all of them. Any fridge is an interface to refrigerated storage. No need for controllers and their range of connecting extensions. Constructors are connected to cargo inventory, food processors connected to refrigerated inventory, no need to waste the limited real time for tuning things that need no tuning at all. Why my guns want an ammo box when they are able to see all the items available on the site? (ok, it would be strange for a turret to look for ammo in the fridge Then my harvester just puts the wood in the storage, not a particular box.

And on the POI containers can be inaccessible completely until the core is destroyed, so the loot isn't something that comes cheap. At the moment anyway, after the core is destroyed, we immediately have the access to all equipment from the control panel of the structure except alien containers (the only thing to look for in POI's after all).

If this new logistics thing is a quest for realism in a game (realism? in a game?) then remove hand-held minigun from the game in the first place. A 15 mm round is unable to kill a dino in one shot? Then be honest, rename it .22 LR, as it behaves like one.

 

As much as people want to call this whole Volume and Weight thing a quest for realism, it has nothing to do with that. It does, however, have to do with an attempt to deal with something we call absurdity. There is something inherent absurd about two containers being able to hold exactly the same amount when one is, literally, 64 times the size of the other. There is something absurd about the ability for a tiny SV to hold more, by almost two orders of magnitude, than the incredibly huge CV that it is docked to. There is something absurd about the ability for that same SV to hold enough materials to literally build a fleet of CVs.

But, now people are upset. They are upset because their exploitation of absurdity has come to an end. They are upset because now they are being challenged. And they don't want to be challenged. They want easy mode back. They want to find words to denigrate the change, to make people feel bad for liking it. They are trying to ridicule the new to make it feel as if it is something that shouldn't be enjoyed, because they're running from the challenge of the new.

I'm going to posit here, as I have elsewhere, that the largest segment of users who are barking the loudest about V/W changes are those that came in between A6 and mid A8. The late A8 players and new A9 players don't know the differences enough to be upset, And those from A4 and earlier welcome the change due to the fact that we finally have a new challenge for our design metrics. I'm guessing the A5 people are split roughly 50/50. There will be exceptions to this, of course, but I feel that overall you'll see that trend. I'm also betting that you'll see a higher percentage of the PvP crowd and POI-raider-only people being upset about it and the builders/designers just buckling down and updating their ships, because design and building challenges are what we live for.

For all that a lot of players call PvP the endgame and the POIs the 'content' the game is still at it's systematic core a survival game and in that genre, the concept of weight and volume is almost a universal challenge. Up until now, EGS was one of the few games that glossed over it. Stack limits were about as close to that as we got (and can we mention the absurdity of being able to put 999 of an ore into a stack but we're limited to 100 fiber? If you're going to make it a fundamental building material, you need to stack it to 999) and even that was only vague and as I mentioned above, still lost in the absurdity of SV and CV having the same carrying capacity of boxes, regarless of the 64x difference in physical size. Weight and Volume are a new system, and Alpha is always about ironing out systems. Sometimes that takes longer than you like, and sometimes it goes through phases you don't like. Eventually we'll get there. Stay the course.

When the de-facto standard for bulk materials shipping is to build a small constellation of SVs outfit solely with cargo containers to dock to a CV because you can store 64x the materials in the same space, you have reached a point of absurdity that must be addressed.

 

No, it does have to do with realism. Go back and reread some old forum topics from Alpha 7 and earlier and you will find some players (a small, vocal minority) complaining about being able to carrying around stuff without having to deal with mass or volume. The word "realism" was definitely tossed around.

What is the definition of absurdity? Is it not the antithesis or exact opposite of "realism"?

I would remind that this is a game. It's something people engage in during their free time in order to entertain themselves and, possibly, to relieve stress and/or socialize with or over. It's also a work of fiction. As such, it is not - strictly speaking - based on facts, actual events, or even reality.

Certainly, realism plays a role in science fiction. But, most sci-fi takes certain liberties with science facts for the sake of entertainment. Moreover, as a game, certain liberties are taken for the sake of gameplay and game balance. Normally, I'm a huge advocate for realism in science fiction. However, as a game, gameplay should take a certain amount of precedence over realism. The only exception should be if the game in question is, first and foremost, a simulator.

If you want a computer simulation of space exploration, there is an entire genre of games devoted to this. Check out Wikipedia's article on Space flight simulation game. Of particular note, there's a subgenre called "Realistic simulation":

I can't speak for other players, but that sounds far too boring and tedious to me. I have no interest in that level of realism. If you feel the same, then is it safe to say that there is a certain tradeoff point between realism and gameplay for the sake of the entertainment value? And doesn't this tradeoff point vary from person to person?

This notion of players being upset about recent changes due to the increase in difficulty is often expressed by those who like these changes as a way of defending them. To be fair, there is a certain amount of truth to this. However, if we are being completely honest with ourselves, I think we can all agree that this is an oversimplification.

There has been a lot of radical changes to the game in the last two versions, particularly with Alpha 9 and particularly with the logistics system and mass and volume. Change is not necessarily a bad thing. Indeed, for an Early Access game in development, change is a very good sign. However, the fact that we want to see change does not mean that all changes are necessarily good things.

The problems, as I see it, are that this (a) makes the game radically different from the one we bought, (b) makes the game slower and tedious, (c) it makes nearly all old blueprints obsolete, and (d) adds a tremendous amount of game complexity.

Problem (a) would not be a big deal, except that this mass and volume thing was pushed by a vocal minority. The majority did not ask for this.

Problem (b) is a pretty big deal because most gamers have a short attention span. Being able to quickly build or do things is par for the course in modern games. What most of today's gamers want is to be able to delve right into the fun parts, bypassing the tedious parts. "Delayed gratification" is not very popular these days, least of all in games. Check this article out (excerpt):

Problem (d) is an issue because it (1) requires veterans to relearn and retrain themselves on how to do even basic things, (2) requires far more effort by newbies to learn the game, and (3) the system is not as intuitive as it could be. Part of this is because a game that requires the player to actually deal with mass and volume is almost unheard of. They're extremely rare. Can you name even one other game that does this?

The vast majority of games limit what the player can carry around by item slots and by how many of a particular item (if any) can be stacked together. That is far, far less tedious and complicated than a volume and mass system where a player has to keep track of both and, possibly, having to do math in their head.

I'm not necessarily saying that I reject the mass and volume thing outright, because I don't. (I am grateful that it is optional and able to be turned off in the Difficulty window, though!) But I think there are certain things that could be changed to make it more palatable. Whatever the devs do, I think the logistics system should be made easier for newbies to learn. There should be an in-game tutorial or something to teach it.

Heck, I could even see myself embracing the mass and volume system if there were only a few late-game advanced technologies that we could use to bend the rules by allowing a base or vehicle to pack more volume and/or mass into the same space. (I'm not talking infinite storage, but increased beyond what is normal.)

 

While I do agree with a lot of these point, in my argument, the concept of absurdity was being used in the manner of not just a lack of realism, but a lack of realism to the point of ridiculousness. A phrase usable here would be 'beyond the pale' or "that's just not right". It's just gone too far. Every other survival game I've played has not only used stack limits and inventory slot limits, but also weight limits, and in some cases volume. EGS was the only one I've played that did not take weight into consideration in some form. In our case, volume comes into play, not necessarily because of a desire to limit volume itself, but rather as a means to balance CV vs HV/SV and the appropriate carrying capacities of the two.

In your response, you completely failed to defend the concept of an SV or HV being able to carry 64 times the quantity of inventory in the same space. I can only assume that it's because there is no rational defense of that.

Because there isn't.

Maybe this isn't a great solution. I personally love the new logistics window. I also agree that there needs to be a much better tutorial for new and returning players to use it. I did helpdesk in a previous life and figuring stuff out like this is second nature to me now but I appreciate that not everyone has that skill set. We need a better learning system for that, agreed absolutely.

I also like your idea for late game advanced technologies allow for 'quantum stablized storage' or some such solultion that allows for greater storage in the current space. Perhaps doubling the standard volume.

To me, EGS is still very much a game, not a simulator. But in games, especially survival and building type games, part of the challenge is often the necessity of inventory management. The ability to only carry so much provides a much harsher survival mode game. It requires greater planning and a more cunning gameplay, especially in the early stages. A lot of people want a harder game, and this gives it to them, but really, what they mean is that they want better scaling MMO style combat options, and this just isn't that sort of game.

If I wanted a simulator I'd go back to kerbal or SE. Neither one fits my style and they are far 'too' simulator oriented for my taste. The W/V system to me is a sorely lacking piece to basic survival gameplay however. Also, I think we need armor mods that adjust both carrying weight capacity and volume capacity. EGS isn't a sim, if it were, we'd get 438 hydrogen bottles and 78 oxygen bottles out of 5 water containers, not 10 of one or the other.

All old blueprints are not obsolete. Not by a long shot. To wit, the standard CV that I use, I have used since no later than 2.5. I have seen this CV through the big change from separate types of blocks to unified blocks with selection criteria. Grav gens going from cubes to spheres. The introduction of combat steel. The introduction of pressurized hulls and O2. The introduction of weapon count restrictions.

These were all things that people said would 'destroy all the old blueprints' and while it may have required some effort, in the end, the changes destroyed nothing. What it does, is obsolete BPs that were utilizing the mechanic that the change was designed to fix. My SV cargo carrier pods for my cargo bay? yeah, those are dead. Why? cause they were, essentially, an exploit and the W/V changes close that loophole. My old Fighter SVs that packed 18 plasma cannons? yeah, I had to redo those at one time as well. Same deal.

If you play it smart, this change will have very little practical affect on making this game slower or more tedious. You just have to rise to the challenge and find the way to solve the problem. There are many of them, and they're not at all hard.

Now, the long term effect may be something slightly more troublesome, but it's nothing we don't already see. There may be fewer 'paths' through the early game. In other words, due to W/V being introduced there may be fewer super efficient paths through the early parts of the game. However, everyone who's played for a while, especially those of us in the 3 year club, have already developed our 'standard methods' for getting through the early game to the point that a lot of us are cranky if it takes more then 8 hours to get our main CV started. And really, I gotta say that's far too fast.

I've always said that the progression in the game is too quick. What some people find as "tedious and time consuming" is really just the game slowing down to the point where it should be for actual play instead of the highly accelerated rate we've been playing at for testing purposes. The progression rate has been roughly the same since pre-alpha, when it was explicitly stated that things were set to go much faster than they anticipated them being later so that we could properly test things and now that we're to 'later' no one wants the game slowed down cause they're used to it being so fast.

But, of course, it's not all wine and roses. I've listed out in great detail my complaints regarding power use for the current container system and the fact that we are, essentially, getting penalized for using it. I've listed out the necessity to reduce potential CPU load and why (though that's without knowing how cpu is going to play out, minds may change). I agree that a lot of balancing needs to be done, but I also believe that it's a fundamental need for the game, and something that will ultimately improve the game and bring more challenge to the design phase.

 

So my thing with extensible storage is this:
1. removing the ability to place containers next to each other was a lazy way out of a coding problem. To address this is quite simple from a coding perspective. The container extension (a child of container controllers) can be assigned a container controller. Yes this could introduce problems with extensions being children of container controllers that aren't connected but currently I can do that by shooting off a connecting extension anyway. When I place a container extension which could be connected to two container extensions, I get a prompt from the game:
Which container controller to add to?
Radio option 1: CC A
Radio option 2: CC B

Simple, easy, and if I don't answer it, the block gets put back in the inventory.

2. Why the heck did you think it a wise idea for container extensions to use power, and why the heck is it the same amount as a large constructor(in idle)? This issue alone is a non-starter for most people. I spend more time trying to figure out how to keep my 300 psu consuming base powered than I do playing the game. I had to cut my containers in half in order to keep power consumption reasonable, even then I still only have a day's worth of power with 2 T1 fuel tanks in a BA. Cargo extensions should have extremely low power usages (what power do they actually use in terms of game lore?), something like 2 PSU or 1 PSU. They certainly shouldn't consume the same as a container controller, which does a lot more than an extension does. The container system as a whole I wouldn't think consumes more than a repair bay or something.

3. You need to figure out how cargo would get lost due to damage/deconstruction of the cargo system. Right now I could remove and replace a cargo container, and end up with my stuff right back where I left it; even if I don't have enough extensions. As a cargo extension gets destroyed, a calculation should happen to determine what gets lost. It shouldn't care what item it is, so long as removing it will bring it's volume to a normal state (i.e. not greater than 100% capacity). Continue to do that until container is a normal capacity. If a cargo container dies.... Idk, do I lose the inventory? Can I recover it's contents by multitool? Can I get back into it using a container controller?


Other idea based on 3: A neat feature would be a way to "hack" storage. Like a hacking block which given enough time and power will let you access a container system and siphon stuff out of it. Would make piracy be less pew pew and be more stealthy.

 

This was a fun, arcade-y style space building and combat game with light survival elements, and it was awesome. It just needed more content....but now it's ruined.

Devs went down a crappy path, and probably aren't going to reverse it out of sheer stubbornness.

This whole weight volume nonsense with virtual toolbars accessed through the Friggin f4 key, of all the keys to choose, you choose a function key? It's a stupid system, accessed through a stupid key, and terrible basic design decisions that make me wonder just how in the hell you managed to make such an awesome game in the first place that admittedly needed a lot of polish and content, and proceed to just wreck it.

Makes me sad.