SE2 - Possible removal of "volume" from cargo/inventory system.

You're close; mass is constant, weight is not. In zero-G, this means that a cargo container with high mass weighs nothing but changing its velocity/direction requires more force than would a cargo container with low mass.

> hmm this is disappointing, I've been so hyped for the survival update that I had not noticed this

Yea, I had my reservations about reworked (arcady) jetpack; (arcady) damage immunity to the grids under certain speed.

But this one don't make sense at all!

> I certainly hope this is a early access thing not a final game thing.

I hope so too, but unfortunately from code (item definition) + "why make mass first then?" it don't look like this.

> Although is it a consequence of or related to the coming water physics?

Don't make sense? I belive "stored" will behave just like gases in SE1, and even so - "ammount" of liquids is generaly calculated in volume.

But any way - it is best to get to 50 votes and get respose form devs.

i only ever wanted an improved SE1, new engine, no bugs, and no excuses. Any fantasy and unrealistic features they add are unwanted from my side.

SE2 and SE1 teams should limit their artistic freedom, and focus more on logic and reason. Professionalism, precision, discipline and order over emotions and hallucinations.

And since you are making a product to sell, not for yourself, you should listen to what customers want. Such as this post.

... because your wish is the one true vision among all the different ideas of what SE2 should be.😅✌

Ain't that the truth! Lots of people like to think their desires for SE2 define what the devs should do solely.

The devs are creating their vision with our input. Our input only makes sense to add when it meshes with their overall vision. It's not our role to define the vision.

If the result of their vision is a game people love, awesome. If the result is a game that flops, bummer. Guess I wasted 30 bucks. However I truly want them to make their vision, to let them cook and bring their artistic and concept chops to bear. If I wanted just what I see I'd make my own game but I know my limitations.

None of that is to say our feedback shouldn't be needed, thats the purpose of EA. However, only if it works in their vision or expands it. Let creators create!

They do get to make exactly the game they want to make, they're doing the work, they're paying the bills, they have a legit need to find a market and they get to choose whom they serve. Anybody demanding personal service is wayyyy out of line.

But I don't see anything wrong with people who've signed on to provide explicitly solicited feedback saying what they want the game to be. I want the game to continue SE1's tradition of legit engineering/design tradeoffs and puzzles with unobvious solutions, that can be largely bypassed by tweaking rates and capacities or just disabling aspects.

Solving those puzzles seems to be a maturity thing, vaguely kin to untangling knots in shoelaces, doing that for my kid provoked long-forgotten memories of my dad doing it for me.

So, yeah, they have to provide entertainment for the far larger majority who aren't ready to or just don't care to solve those puzzles, the defaults can't be set to force the issue.

But if they don't have that kind of rite-of-passage puzzles at all, they don't have a forever game.

Never said anything was wrong with feedback. Feedback is great and very helpful in understanding customer desires (even those ones you choose not to meet).

My comment is more towards some of the very demanding and angry posts here and on Steam forums from community members.

Agree with you 100% in sum.

In real spaceflight, mass is crucial because it determines how much fuel and thrust you need to move something. However, cargo capacity is always measured in volume (liters), not weight.

The same principle should apply in Space Engineers: You could completely fill a cargo container with tungsten, while this would make it extremely heavy and require many engines to move, the cargo container itself isn't responsible for movement - that's the ship's job.

This makes even more sense for stationary cargo containers. Imagine a large container with a 10kg capacity filled with feathers - lets say it would be completely full. But if you put 10kg of bricks in that same container, theyd only take up about 5% of the space, leaving it mostly empty. The container doesn't care about weight; it only cares about the physical space available.

And my a bit harsh comment: having cargo in kilograms because there might be someone who does not understand difference between volume and mass (literally elementary school thing) shouldnt be in a sequel to space ->engineers<-

So i hope this is just work in progress thing and they will sort it out because marek told that they dont want SE2 to be dumbed down

In real life, this is only true up to a certain point; if you made a cargo container out of cardboard then it would probably hold feathers just fine but break and deform if you tried filling it up with tungsten and then moving it.

Unless, of course, that cardboard box was supported on each side by more cardboard boxes also filled with tungsten and they were all packed densely into a massive steel structure. All of this means that in a game, it would make sense for a cargo container to have some limit on the mass as well as the volume, but the mass limit should probably be a lot more generous and really just stop the player from taking things to the extreme.

Fun fact, filling a standard 40-foot freight container completely up with tungsten would make its gross weight a bit over 1306 metric tons (or roughly 50 times the weight limit). Even if you had a crane powerful enough to handle it, I imagine the top corner castings would just come off if you tried lifting it the normal way.

Volume in no way makes physics harder.

Every container will have same mass property in the end.

Volume it's just HARD INVENTORY system limit.

Removal of volume is NOT technically driven change but ideologically and part of general "dumbing down" of SE with SE2.

You are right, it's not related to physics at all. Thus, it's irrelevant to testing and tuning the physics model. Developer teams have only so many resources and can only work on so many things at once. Priorities are chosen, and higher priorities are worked on first. Physics, given the intent of the gameplay, must be one of their highest priorities, so gets work first. A secondary system, like volume, that does not interact with physics directly but is just another set of values calculated for inventory management is likely not a big priority overall and can be tweaked at a later date.

I'm not saying that I have inside knowledge of their design intent but do think that the above is reasonable. No one knows their design intent behind volume not being in the game at this time. I just don't understand the assertions that the way it is now (in early EA) is indicative of the final product. If that was true, what is the point of EA and continued development iteration?

I support volume being a feature; it adds real challenge and variation to ship and rover design. I don't know if it will be added, though I suspect it will. I also don't think that its absence now means as much as it is being interpreted to mean. Hell, I can see a world where volume is a toggleable feature (I like more options).

Upvoted the topic as I hope to see Volume in game

What are you even trying to say?

What "Priorities"?

Foundation of volume-based system is literally two lines of code in base item class.

[atributes and stuff]
public double(or something else) Volume {get; set;} = -1;

I'm not even talking about the fact that if it was planed then start propery would be volume, it's not much work, AT ALL.

Or about the fact that this ticket has alredy 78 votes and it is ignored, if answer where to be "we are planing to implement this in the future" then it would be posted here long ago.

Wanna keep this thread alive as I do agree, volume makes much more sense and provides many more reasons to craft different machines compared to pure weight. I wanted to make a mining machine that has a smelter and an assembler attached to it so that I could mine the ore, refined it, and craft them into pieces immediately, that idea sounds really cool to me, kind of like a flying mining forge.

However, when I made a few of the advanced pieces, their weight was equivalent to the total weight of the ores. That completely eliminated the reason for why I wanted to make that machine. Hell, this goes slightly beyond the thread's point, but having the final components be exactly the same weight as the raw ores is such a disappointing decision.

"Hell, this goes slightly beyond the thread's point"

No, it is not.

It's perfect example of gameplay already being harmed, then you for your feedback!

Volume, density and mass are linked by a simple formula: Mass = volume x density

If you know two of these, the third one is trivial to calculate. Pick the two values you are most comfortable with, add a function to the code that calculates the third one as needed. For the content of a container, total mass and volume are equally easy to calculate. Which of those values is the hard limit for the capacity is arbitrary. Without even knowing the code, I'm pretty sure switching from mass as the limit to volume as the limit could be done in a day. Most of the work being changes to the UI.

>Volume, density and mass are linked by a simple formula: Mass = volume x density

>If you know two of these, the third one is trivial to calculate. Pick the two values you are most comfortable with, add a function to the code that calculates the third one as needed. For the content of a container, total mass and volume are equally easy to calculate. Which of those values is the hard limit for the capacity is arbitrary. Without even knowing the code, I'm pretty sure switching from mass as the limit to volume as the limit could be done in a day. Most of the work being changes to the UI.

Yea, it's funny how many people using absolutely idiotic argument of "performance".

Like, my brother in {insert-religious-figure}, multiplying two `doubles`/`floats` is NOT hard.

Especially if they took a minute to think that this operation is performed ONLY on update of container's content.

Especially if they took a minute to think that this operation is performed ONLY on update of container's content.

That part is important, the compute time for those conversions will be negligible. I expect the performance bottlenecks for the game will be collision simulation and rendering the graphics. The collision simulation because you will have grids with thousands of blocks crashing into each other.

It is even easier because there is no need to compute anything in runtime as all three properties (mass, volume and density) never change for in-game items. If items are processed by production blocks they are replaced by other item types.

In this model each item has just two properties saved in its definition: mass and volume. For inventory there is only one property needed which is maximum volume. And it also never changes so it is just saved in inventory's definition.

Simulation needs to run multiple checks but only when items are moved between inventories: if there is enough free space available in container, if the inventory's block is not damaged, if the conveyor network connection exist and is not damaged, if the item type matches inventory filter, if the permissions set for container allow for transfer etc.

The switch from existing SE2 check for "maximum mass allowed in container" to "maximum volume allowed in container" does not cost any more computations just use different number value.

All else failing, we could say "all ores/components have a density of 4 g/cm³" and mod the weight limits to match the apparent volume of the containers. For the 1.5x1.5x1.5 m container that would be 3,375 liters (sound familiar?) and give us a mass limit of 13.5 tons.

Which would be more of an emergency solution, but at least the numbers would seem a bit more plausible.

oh that's interesting about the density being in the files for items, so it's at least a little roughed in, maybe (hopefully) they're experimenting with using mass only, and intend to at least add an option to choose in the future. I can see why they would at least experiment with mass defined cargo, as it makes the calculation of "how much weight do I need to be able to lift on this ship" very easy, which is neat, but to me doesn't come close to making the system worth it.

And yea you summed up my thoughts on the difficulty of adding it as a mod fairly well, however there's also the rather important point that mod compatibility will be rare if it was only modded in, since most people would make their mods to function with the base game, and it's significant enough of a change that very few small mods will integrate it directly into their mod. Either way, complicates modding, both from the creation aspect and the compatibility aspect.

Honestly same, my dream (which will never happen, and is completely unrelated to the original topic of the thread) is if you needed power cables to bring power individually (with different sizes bringing more or less power to places), along with not only separate pipes for gases/liquids, but also separate pipes for each gas and liquid, so you have to pipe oxygen individually, and hydrogen individually. And of course I'd like more fuels (xenon for ion or jet fuel for atmo for example), really give me complications to try to engineer around, instead of taking them away like they're doing with volume, or ores, or backpack building, etc.

Re the pipes and cables and gases, you're looking for Stationeers. that level of design-puzzle focus on the details is a whole game unto itself. Its primary materials have actual (simplified but still) phase diagrams,. its plants have actual (simplified but still) genomes. you care, a lot, about gas mixtures and temperatures and pressures, and how to design the equipment you'll need to achieve them. Without, you know, blowing yourself up..

To get that level of detail without utterly overwhelming players they leave vehicle dynamics to people who want to focus on those.

I don't know, I did not look into files earlier. My (weak) hope is that values we can see in JSON are not leftovers of something which was removed, but rather preparations for adding them to C# classes in future.