So this is definitely broken. I keep having to deal with it. For some reason the wifi stops working, even though it shows connected in F4. Had to disconnect and reconnect, then pick up the large item. Also when I look at the fridge, and the wifi switches, and I start mining ore into it. /foreheadslap Edit... deal with it meaning I forget how it works, and spending time relearning.
Don't worry; the Logistics interface still needs work to feel like a natural extension of the player, as I've been emphasizing a lot. @Hummel-o-War - Random additional UI consistency improvement suggestion related to the above- Make the Connected Inventory background orange as a visual language for "remote inventory" just like in the toolbar when switched! I'm not sure whether it should be orange all the time or only when active (toolbar & inventory selected)... That would depend on how it flows with any other UI changes like the connected inventory replacing the player's backpack on the left when the toolbar is switched and interacting with another window.
Throwback to previous discussion in this thread, there is now a parallel thread about power consumption you all may be interested in specifically: https://empyriononline.com/threads/cargo-units-and-their-powerconsumption.47018/ Edit: This should've gone in the Modular Cargo / Logistics thread, but I'm leaving it here as testament to just how easily we're all confusing these interlinked discussions.
Don't know if this has been suggested before, but I will throw in anyway. If it has, then just think of this as a +1 to any similar posts on the subject... I think that volume should be dropped as far as storage restrictions and instead just use mass (and I am happy that storage restrictions will be a gameplay option, regardless). Suggestion for storage limitations: For our futuristic storage containers and backpack, mass would be the only limitation on storage capacity. Let's say that in the future we can fold objects into a fixed amount of space (via future Wifi ray). That storage might even exist in another dimension where the weight of the full container is not a factor - just the weight of the container itself. But I digress. Anyway, in a given container, you might be able to store (for example): Example below (not accurate): 1000 large wood blocks or 100 large steel blocks or 500 small steel blocks or 4 CV/BA small generators The amount of objects you can store in that container only depend on the individual object's mass, *not* its volume. That way, you simplify the object properties because you only need to keep track of each object's mass. Volume is only needed for the object to give the number of small or large blocks when the object is placed (e.g. a small generator is 1 x 1 x 2 blocks). This is already in the game. Mass is also (already) used to calculate the object's dynamics when used on a vehicle: For an HV it is relevant for balancing in an environment with gravity + acceleration. In space, it is relevant for acceleration and placement of thrust vectors. In either case, you can calculate center of gravity using mass (not volume) and with the position of thrust/acceleration vectors. Again, volume is not really needed for limiting storage capacity. I believe the above would present a clean, simple way of limiting storage.
@CitizenK3N - Yeah, I've already raised the consideration of volume being largely proportional (and thus redundant) with mass. It's unlikely to be removed at this point, but volume was not necessary for implementing logistics or cargo mass (and player carry limitation -> stamina cost from overburdening). Stack sizes and mass are both viable proxies for volume in terms of gameplay and inventory limitations, and the UI is still carrying stack/slot design principles which muddy the waters. Volume is working but the gameplay effects could have been added more simply--by putting more emphasis on mass and balancing stack sizes as they were. Still, maybe the simulation (realism) detail will pay off. We'll see.
I like volume better than stack sizes. Volume can be more consistent and intuitive than stack sizes. For example, if you have 10 of each ore, in a stack size system it takes up 1 slot for each ore, whereas in a volume system it only takes up the volume of the actual ores.
Easier to program to as stack size no longer matters only the per unit volume where as with stacks and cells you have to set the stack size for each item in the game to try and come up with something that comes close to making since
That's a fair point, and one I hadn't considered. Thank you. It's still harder to tell *at a glance* how much each item (or stack of items) is using without significant changes to the UI (everything still looks like a stack in a slot, rather than something reflecting its individual volume use when active) which we have not yet seen, but you've given me something to think about. As long as volume can be disabled, supporting both game modes will actually cause more headache than sticking with one or the other...but they'll definitely need to do so if they intend to keep it as an option. The UI still needs work before volume limitations are reasonable. Even just seeing slots free while having all your volume used up causes mental whiplash on a gut level...and I'm generally willing to see past things like that.
And the opposite is true too, seeing available volume but not having any free slots. That's why I'm planning on putting stack size of ore and components to 10k once I start playing.
I'm not saying they should use stack size as a limitation. I think they should use object mass instead of volume to limit container capacity. TL;DR: They may be doing that already in a roundabout way. Volume is given in Storage Units (SU). The way I think of it is that an object's SU volume is not it's volume when it is placed, but rather it's volume when shrunk/folded into a futuristic container. Containers currently have a limitation on the number of SU they can store. But what is an SU? Density is mass divided by Volume (the actual volume of a placed object). Let's say our futuristic shrink ray can shrink all objects into a fixed (known), but extremely large density. So if we know the object's mass, we don't need to know the (placed) volume. Instead of using SU to limit storage capacity, all we need is the object's mass (which doesn't change when shrunk into storage). All objects already have a mass attribute, so we don't need it's stored volume. All containers (including the backpack) could just have a mass limit. Different sized containers could have different mass limitations (example: 500 kg capacity small container, 1000 Kg capacity large container, etc).
I think volume + mass is good. It allows for greater flexibility when balancing things in the future. For example, one type of ore might have a large volume but weight less, while another might not take up much space but be really heavy. Having mass but no volume would feel like something is missing I think.
Weight causes problems to of that's the limit, Take my knap sack. it holds 29 letters, I could fill that 29 letters with iron bars, I would not be able to lift it but I could do it. but or we yes what most people can conferrable lift and move, 30 to 40 lbs then with 30-40 pounds of Iron there is room to spare likely a lot of it. now I would not be able to fit 30 pounds of feathers in 29 letters. and if I take that 29 letter bag and pack it as a bug out bag I am more likely to run out of physical space to put stuff before I get even close to my conferrable weight limit . Granted most solders in the field carry much more weight, about 60-70 pounds, but its not all in there nap sacks it takes the form of body armor weapons ammo coms gear, hell even a solders boots adds to the weight. And as we keep trying to make a solders or even a backpackers gear lighter and lighter. and if we can go to another galaxy we should also be able to Augment our strength, Ether genetically or bionicly or with an exo selection, Then Weight become less of an issue..... intel you get to Vehicles when then you have to deal with the thrust to waight ratio, Which admitadly will shift depending on where you are,
I would say that if volume is a limiting factor for cargo containers, that when (or if) volume becomes a thing, that there is no longer a slot restriction on cargo containers, just a dynamic "add more slots" to a container once you fill all slots (not sure if it'd be likely you'd do this before filling a container anyway). Also, should have some way to specify for a container extension which container controller it belongs to (blocking me from putting two container controllers seems a lazy way to fix it).
I am missing a easy, intuitive, and simple cargo system. What i am not missing right now is "degree of realism", that the game already has to much already (current and planned). I would prefer weight without slots. Only spreadsheet style lists for contents. And a "kind of volume" based system as a graphical, less realistic alternative which is based on slot sizes and stack sizes. That way you can have more than two sides have their cake and eat it too. ;-)
This is the maximum allowed use of Cargo extensions (32k @hovers) for a single cargo Controller. This is NOT enough, to get the ores of a single T3 miner (zascosium). I dont like volume as it is. But hey, I found a flying balistic: Please let go of too much realistic realism, and head for a more game-coherent approach of a consistent ingame-realism. EDIT: For the minimal approach... I also find it very annoying that only 62 Copper ores fit into a regular 125l container.
I have volume/weight disabled. I have an SV that is suppose to have 17m/s^2 upward acceleration. On an 0.8G (about 8m/s^2 gravity) planet the ship now barely accelerates upward. Is the Statistics screen broken or is there a physics problem?
Also, what is the plan for the limited number of slots in containers? As long as slots in containers are limited then you effectively have TWO volume limits at one time: a limit on volume of m3, and a limit on number of "stacks". This also means you can create a massive container that isn't volume filled even with the maximum number of stacks of 999 ingots.
Another issue with container extenders: Even for bases, they consume 10PU for some reason. Why? Lets say I want to store a container full of max slots max stacks of T1 ore. It appears that this requires one controller and 15 extenders for a total of 160PU. That is enough power usage that I'm now going to want to build this as a separate base with solar panels. I don't see what the point is of making empty space consume so much power. For vehicles, there's also no need to make them consume so much power. The vehicle is going to need to use more power and burn more fuel to deal with the mass filling the containers so why add this power usage on top of that?
