Inventory Sizes

It sounds like you need to submit a feature request to enhance the modapi to simplify dealing with variable inventory sizes and not hamper others play choices. Quoted from a reddit comment of mine:

No. The scripting thing I can live with. It's the rest that is problematic, the fact that vanilla constructs are not universal. That's stupid to me. Besides - storage space for grids is easy. You need more storage space? Just make more cargo boxes. And the technical impact of having to do extra calculations for every inventory.

Or - since you are the one that want a differing play style from their design - add a mod that increases the storage space. That's quite doable and there will be such mods when this hits release because it's a simple mod to make... and modded builds are incompatible with vanilla anyway. So no, your playstyle isn't really changing. They're just streamlining the vanilla gameplay.

Also, keep in mind that reducing the number of vanilla options reduces the testing overhead for Keen's QA team because they don't need to test everything 3 times, once for every multiplier, so they're able to test more things better.

So as you see, I'm not voting no for selfish reasons, but for what I perceive to be the better choice overall.

I hear what you're saying and, in and of itself, it sounds quite reasonable - I'm not adverse to mods (on the contrary). However, I would argue that I don't want a different play style - I want the one I've been provided with by Keen for the last 33 months (with respect to what we're discussing here; inventory settings - clearly a lot of things I would not want rolled back!). Enhancements and expansions to existing features is fine but not restrictions - and I feel that this is that,

Anyway, I was under the impression that cargo mass was divided by the inv multiplier so as not to cause the issues you say (eg. with thrust). If that's no longer the case then perhaps that needs fixing.

Regardless, I appreciate your thoughts on the matter.

I have to say I agree with Malware on all points.

I understand that you and probably a lot of other people have gotten used to the way it was but for me that has been a broken system the whole time.

Unfortunately there is no Dislike option here... :(

If a restriction is well-reasoned, it's valid. And this is still an early access game, changes are inevitable - even changes to design, if they deem it necessary. That is their prerogative as it's their game. And no, that's not what I meant. What I meant is that having an inventory multiplier adds to the calculations needed to handle mass and inventory transfer and all that, which impacts performance. Without the multiplier they can cut out a bunch of code, making the systems run faster. And, as I said, any option adds to Keen's workload and they're not a big company, so removing it will add manhours to the QA team.

Heck, I'm even just giving you reasoning based on my own experience as a developer. They might have even more specific reasons to do this for all I know. Or, they just want it for the sake of gameplay design. Either way, votes is the way to go. Get the votes you need, and - if there isn't a very good reason to leave the multiplier out, you may get what you want. I can easily live with your suggestion since I can still run the game with 1x grid inventories and 3x player inventory, even though I find grid multipliers - as I always did - a bad idea.

My two cents : inventory multiplier on ships had lead on ridiculously small ship to carry ridiculously large amount of stuff.

Logistics should be a large part of engineering, and not "I'll stove a small cargo on that little corner and it will carry tons of ore, no problem".

Cassin, that's not a reason to not have the option. Malware has provided some good counters to my proposal from a development point of view.

The purpose of my proposal is to ensure as many people are catered to as possible from a gameplay perspective and I accept that the intricacies & logistics need to be weighed and valued against the developmental impact.

I like the reduction and separation but I think we should have gone for x3 size. Realistic is just tediously punishing but hey I can always mod it later I'm guessing so not that big a deal.

Best of Both Worlds? Allow for Overloaded containers from earlier saves, BPs, and Visual Scripting. Contents can't be added past the 1x space in cargo. Overloaded inventory must be moved before Inventory is usable again. any Overloaded Inventory that is not a power producer will not function until it has it's overloaded state corrected. (refineries, assemblers, connectors, ejectors etc.)

Yes allow for overloaded containers to let players transfer contents with out breaking a world. Now if they were set to 3x they would not be over loaded, higher setting they would be.

I fail to see how that's the best of both worlds - that's purely to ease transition to the new system.

Further thoughts on previous comments regarding overhead and QA time:

1. I don't imagine having up to 10x more cargo containers in game is more efficient on the game engine than a 3x or 10x multiplication/division. More nodes, therefore more conveyor ports, on a conveyor network = more load. We see this effect on sim speed with excessive use of conveyor junctions, If Keen were to optimise the network by internally disabling unconnected ports, therefore removing them from the network calculation (for example on a network change, usable ports are stored in an array and only that array is used in determining network routes), might go some way to bridging that gap.

2. QA man hours. For one, this is a public test - so we are the QA team right now. That's a lot of free man hours. Additionally, being able to flip a simple switch to test different inventory multipliers rather than having to test a scenario with different sized conveyor networks seems like an easier job.

We can all hypothesise until the cows come home but only Keen are aware of the implications for keeping the old system or forcing the gameplay changes with the new system. The ball is in their proverbial court.

1. No. But there are oh so many more inventory items (or stacks) than there ever will be cargo containers. Thus, just a few extra computations per item (or stack) during inventory operations has a much higher impact than a few extra cargo containers.

2. Having the public tests has no effect at all on QA man hours, they still have to do the same work regardless. Public tests are just a bonus to them; and the main goal is to get public feedback more than bug testing. And these kinds of QA tests go on continually, not just when the change applies. Every time a change is made in an application a set of tests are run to see if that change has affected an older feature. This workload is multiplied by the number of options potentially affecting those features.

@Cassin "inventory multiplier on ships had lead on ridiculously small ship to carry ridiculously large amount of stuff."

Why would you have an inventory multiplier in the first place then? I mean, it should be realistic right? So you SHOULD run 20 thousand times from your cargo container to the thruster or medbay or whatever you build. I mean, why is it wrong to carry "ridiculously large amount of stuff" in your small ship, but it is right to do it in your suit? I mean, the suit doesnt even have a cargo attachment, so why should you be able to carry stuff at all? Lets make it realistic as it can get, and let people just carry what they can hold in one hand.

/sarcasm

It was good the way it was. Please make cargo inventory sizes configurable again.

it wasnt good the way it was, its probably just the fact that you got used to it, silly over the top multipliers, it should never have gone up to 10x to start with!

Actually there never should have been block inv multiplier at all, players would have just gotten used to it, player inv however is a different story, 1x is too low, you do more walking than actual playing/engineering/ etc

There are no real reasons not to make it configurable, as it was before. Why do some people want to force their playstyle on everyone else? The configuration slider did not hurt anyone and perfectly satisfied all different playstyles.

This is supposed to be a sandbox game, not a logistics simulator.

It's supposed to be an engineering game (hint : it's in the title :D ) ^^

It's not much as imposing a playstyle that have a minimum of logic ;) When you download a cool ship on the workshop and cannot use it because it was created with x10 inventory in mind and you play x1, that's just useless.

Having everyone on the same basis is good, I think. At least for ships. You're right, everyone should play its own playstyle and therefore keep the inventory modifier for character is good, but not for ships ;)

In my personnal view I never understanded where was the point of building a welding ship when the character could carry enough in is backpack to build half a base, or build a mining ship when he can load enough rocks in his pockets to kept a refinery busy for hours. But that's not everyone opinion. Therefore, a ship is a ship :p

Sorry, but that is exactly what you are doing Cassin You're forcing your preferred playstyle on everyone else.

If you download a cool ship that does not work with 1x settings, then either reengineer it or accept that this coolness is just not possible with 1x settings, because ten times the amount of cargo containers would not fit.

I am not forcing anything, I am not part of the developping team :D

It's just my point of you like everyone has his ;)

No real reason, Alex? I've stipulated several real reasons.

It really is a shame that there's no downvote, because we'll never know how many people is against this in comparison to how many is for - making this voting system not really show what the majority wants in relation to any one issue.

Sorry Malware, I'm a software developer myself and I can't follow your arguments.

The notion that a few ALU operations have a significant impact on performance is ridiculous. Also there is not much of a difference between parsing the content of one big container vs n small containers. If these operations really have a significant impact on performance in Space Engineers, then please explain it in detail. Please explain where these simple operations sum up to a level where they have a measurable impact on performance.

The QA argument is also quite funny, considering Keen's track record when it comes to bugs. They never invested many hours into QA in the first place. There is nothing to lose here.

At the end it really comes down to a few guys wanting to force their playstyle on everyone else. Hey, why not go with 10x inventory size as a default. I could live with that. You don't like it? Well, bad luck, guess you have to mod your game, as you are so much against a configuration slider.

Every vanilla build does NOT work in every world, even with this. I have ships running around with no armor or guns because I play with meteor storms off. Should those be forced on to make everything work everywhere? How about pirate attacks?

Having to adapt a ship to the environment isn't going away, and is in fact part of the game.

As I've said earlier, I can live with having an extra option, but I'm trying to explain why they might not want to do that - in addition to why I would prefer vanilla to be without such an option.

Alex, about the impact - again, it's all about the numbers. There are very very many inventory items. Ergo, even small operations add to the final impact. Some hundreds of thousands of extra multiplications takes time, and this is all in conjunction with everything else that's going on in the game. As a software developer you probably know this without me having to tell you, you just don't want it to be true right now. I know that feeling well enough. As you know there's a grand total of 16.6667 milliseconds to do everything to uphold a simspeed of 1. That isn't much to go on, so every little thing hits it.

And no, this isn't about "a few guys wanting to force their playstyle on everyone else". This wasn't done on request from the community, at least not from what I know. This was done by Keen's game designers. They don't break stuff without a very good reason, not deliberately at least, thus there must be such reasons. Ergo; you are the ones going outside the game design so you should be the ones who needs to use a mod.

Just because there's a lot of bugs doesn't mean there isn't QA. It's a very complex game to test, with a lot of options where all variants must be tested, a lot of edge cases an oh, so many ways it can go wrong. Thus, since they have limited resources (they're not a big company), they don't have time to go through everything with all potential variants. The more options, the worse it gets. This is perfectly logical to me and your statement about how it seems like Keen doesn't have much QA is adding force to my argument.

Yes, Keiya, every vanilla build works in every world with this. Your ship will still fly fine, will still operate within its designated parameters quite nicely. Will it be safe? No, but that's different. That's you choosing to use a bad design in an unsuitable environment, which is not designed for that environment. But it will still operate the same way regardless - and as such you have the choice to use it if you want to. A ship designed to function for 10X inventory won't work at all as it won't have the space required for its operation. That's equivalent to changing the laws of physics. With the way this is now in this test, I can design a ship once and know that I can use it on every server or host anywhere. There's a huge difference between adapting a ship to an environment and having to adapt it to different laws of physics.

Heck; you could probably even adapt that ship of yours to deal with the meteor storms, by adding turrets to it. But you can't necessarily adapt a 10x designed ship by adding more cargo containers, because it won't be strong enough to move that extra cargo.

Sorry, Malware your performance argument just does not add up. Modern Intel CPUs can do about 250 billion floating point operations per second so the few times an inventory stack has to be multiplied with its scaling factor just does not contribute to any significant performance loss. You would have to do 250 million inventory scale multiplications to even waste one millisecond of CPU time.

Also the number of items does not matter at all. It makes zero difference if all the items are in one container or n. On the contrary it probably takes more resources to scan 10 containers instead of one. But that performance difference is also negligible.

So please, quit your bullshit or put the hard facts on the table. You are trying to justify a bad decision from Keen with FUD arguments.

If Keen think of modifying that point, it's for a reason. They don't wake up one morning and said "hey, if we remove the ability to change inventory size, just to piss off a part of our community ?" ^^

It's OK, Alex, you're entitled to your opinion. You're also entitled to believe what you want. I've been in the business for more than long enough that I don't need you to confirm my assessments.

Besides, you're the one who's getting hung up on the performance side of things, but that's just a part of it. It's not unimportant, but the other aspect is more important. I'm not gonna repeat myself again here though, because you won't change your mind - and you won't change mine either.

From my point of view it's not a bad decision, and I don't feel a need need to justify it. As it is now is what we asked for when they added the multipliers in the first place. And once again, for the 3rd time, I can live with the second setting, I just think that would be the bad decision. But again, just get enough votes, and unless Keen does have a deep reason for keeping it this way, you'll get it your way. That's how this work. But don't expect me to not defend what I think was an excellent decision. Get votes. We'll see how it goes.

You know what, Alex, no. I take that back. You're at least partially right. The performance impact is probably not all that significant, although I maintain that it's there and probably somewhere between what I'm implying and what you're implying, the entire picture considered. Sometimes I get stuck in a mindset and have to kick myself out of it. I apologize. I also get overly defensive at times when I feel attacked... again, sorry. But, as I said earlier, this was never about providing accurate statements as to why they did this, but providing examples of reasons. Keen have their own reasons to do this. If these are merely gameplay reasons, votes might win through. If it's more akin to the QA/workload reasons, no amount of votes will change it.

Well, that's a pity. In my eyes, inventory management never improved any game play. Best case it is at a level where it is unnoticeable, worst case it is just annoying. But for me, it has never been a replacement for good game mechanics.

The fact that people had the option before, but a large part of your user base did not bother to enable it, should tell you something. Also look at the votes/comments on this thread and on Reddit, maybe you want at least keep the option even if the default will be 1x.

slightly incorrect, there was no option to enable 1x block inventories without reducing player inventory also

the problem is that the default setting when starting a new game was 10x, it threw the entire game's mass/weight balance off, now with block inventories at 1x, everything makes more sense and has some semblance of realism,

I don't mind 1x being the new default - all I ask for is the option. For me, personally, my 1x game constitutes about 1/3rd of my time in SE due to RL time constraints. I can't speak for the other voters but I'm sure their own reasons are equally valid. Nothing anyone has said to the contrary in this discussion has provided solid reasoning not to have the option. I look forward to Keen's response on this - at least then, this can all be put to bed one way or another!

> yes, this might actually delete a lot of items in player worlds but you have time to prepare

No, you really don't. Keen hasn't announced when the update will be, and thanks to the conveyor system, if you go into your world, things like refineries and O2/H2 generators will suck up a bunch of stuff. I could go move everything around, but I'd have to leave everything turned off until the update comes out at an unknown time. At the very least, there needs to be an interim update for like a month where things won't go above 1x automatically, better would be if containers can hold arbitrarily large amounts of stuff and you just can't put in things that would push it over the limit, so they'd just be over-full for a while.

players usually played on x 10 because x10 was the default and most did not even notice until they got far more invested in the game. like I said before, when we forced players x1 during test, they were frustrated at first for the sudden increase in difficulty, but eventually ended up feeling accomplished when finding solutions to these problems. this is what we want to encourage.

Inventory multipliers can be enabled again trough mods.

@Joachim Koolhof

You say 'we' quite a lot - are you representing Keen in this conversation?

Ah yes, I am Aragath on discord.

@Joachim Koolhof

Thank you - just checking. Good job on the scenarios (if I remember correctly!).

To quote an earlier comment of mine, my current games use 1x and 10x:

"As it stands, I play 3 different game styles - 1x for my long running survival, 10x survival for a more action oriented playthrough when spare time is limited and survival with creative tools (or 3d interactive CAD mode, as I prefer to call it) for fast idea testing."

As an overall multiplier or individually? IMO, cargo inventory was ok, Assembler Ingot and Refinery Ore Inputs were a bit low.

I think x3 is too big, please bring back x1.

In early game you put down a large grid base for basic refinery and basic assembler, and of course a small cargo container. This single container is enough (46million currently on x3 iirc) is enough to fit the complete mid-game base inside it, even with all the ores/and or excess gravel and so forth. So you only need to put down 5 blocks down and ure good to go. U even dont need to look for cobalt, because the lander has the components to build this large grid small cargo. This way you dont need to move in the early game at all, you can just stay in one spot, mine stone excessiveley and have everything you need to go to mid game.

And this alone enables you to go to mid game which for me is largegrid mobile base capable of mining and processing which is built only out of a small cargo container? thats really strange for me. Even on this mobile base i dont need to build a large container, because they are so huge, its way more efficient to fill in the gaps or replace conveyor junctions with small cargo containers.

The point is, with x3 and up u kinda make the largegrid large cargo kinda useless, way to big (3x3x3) blocks for little benefit, especially in early to mid game. Of course later when u can mine millions of ore in a few seconds u still need lots of them.

If you encourage players to build more storage they have to move, to look for cobalt. Its emphazizing exploration and or mining operations/engineering.

I would suggest put the multiplier back to x1 but up the small grid cargo base values a little bit, and the input/output ports of the refineries/assemblers. I think this is where fiddling with numbers is needed.

Yes, please bring back 1x. I love needing to engineer my way around even the most basic limitations we start out with.

Personally i liked the x3 as a good compromise, i understand how x10 is far too big to even be bothered with much more than a large cargo but im not a fan of scrolling through lots of inventories especially when it has all been conveyor sorted up.