Better Compression (Stacking/Boxing/Pallets) Support

[mrvn]

yes, i understand what you were going for, but you're ignoring all of the subtle aspects in which this is indeed, a change in throughput.

it's a change in bandwidth. it doesn't matter what it is, really, because it changes downstream distribution, hence, it will be a bad idea, and annoying.

See, nothing to do with throughput. It's bandwidth.

But it doesn't matter what it is, you simply don't like the idea. Why didn't you just say so? There will always be haters. Lots of others like it. And if it remains, like loaders, in the domain of mods then you can simply not install mods that use it.

[NotRexButCaesar]

yes, i understand what you were going for, but you're ignoring all of the subtle aspects in which this is indeed, a change in throughput.

it's a change in bandwidth. it doesn't matter what it is, really, because it changes downstream distribution, hence, it will be a bad idea, and annoying.

See, nothing to do with throughput. It's bandwidth.

But it doesn't matter what it is, you simply don't like the idea. Why didn't you just say so? There will always be haters. Lots of others like it. And if it remains, like loaders, in the domain of mods then you can simply not install mods that use it.

They aren’t “haters”. That phrase is used intentionally to try and turn people against those who you don’t like. People who disagree with you have legitimate, reasonable, and valid concerns. Just because you hold the opinion that compression is good or you personally want compression doesn’t mean that adding compression is 100% good. You may think that compression is obviously good because you want it, but those who aren’t so invested see the negatives too, because there are negatives despite what you might think. Every situation is two sided.

[mrvn]

yes, i understand what you were going for, but you're ignoring all of the subtle aspects in which this is indeed, a change in throughput.

it's a change in bandwidth. it doesn't matter what it is, really, because it changes downstream distribution, hence, it will be a bad idea, and annoying.

See, nothing to do with throughput. It's bandwidth.

But it doesn't matter what it is, you simply don't like the idea. Why didn't you just say so? There will always be haters. Lots of others like it. And if it remains, like loaders, in the domain of mods then you can simply not install mods that use it.

They aren’t “haters”. That phrase is used intentionally to try and turn people against those who you don’t like. People who disagree with you have legitimate, reasonable, and valid concerns. Just because you hold the opinion that compression is good or you personally want compression doesn’t mean that adding compression is 100% good. You may think that compression is obviously good because you want it, but those who aren’t so invested see the negatives too, because there are negatives despite what you might think. Every situation is two sided.

You forgot a might in there. People who disagree with me might have legitimate, reasonable, and valid concerns. There can (and are) also people that disagree with me that have none of those.

As for weather compression is good or bad that is indeed an opinion. But compression is already there. This suggestion isn’t even about adding compression but about improving the games support for compression. I want compression, I have compression. Now lets make compression even better.

If anyone has concerns about the suggested improvements feel free to voice them. But simply saying compression is bad falls flat for me. Compression is already there and weather you love it or hate it is not a valid concern but an opinion. So lets please let us get back on topic on how the game could support it better.

[ptx0]

yes, i understand what you were going for, but you're ignoring all of the subtle aspects in which this is indeed, a change in throughput.

it's a change in bandwidth. it doesn't matter what it is, really, because it changes downstream distribution, hence, it will be a bad idea, and annoying.

See, nothing to do with throughput. It's bandwidth.

But it doesn't matter what it is, you simply don't like the idea. Why didn't you just say so? There will always be haters. Lots of others like it. And if it remains, like loaders, in the domain of mods then you can simply not install mods that use it.

i mean, you can already implement that in a mod using omnilib or one of the other mod libraries that assists in updating recipes that are in-use around the map.

it's not that i don't like the idea, infinite research is fine. it's that it won't work well, so i don't think there's much point in wube putting effort into it, when mods can already do the same.

most of the ideas presented here are basically a no-go from me simply because of their complexity. for instance, changing icon size in the inventory to be physically larger, or consume 2x2 spaces on belt. this is beyond a typical mod interface request.

[mrvn]

yes, i understand what you were going for, but you're ignoring all of the subtle aspects in which this is indeed, a change in throughput.

it's a change in bandwidth. it doesn't matter what it is, really, because it changes downstream distribution, hence, it will be a bad idea, and annoying.

See, nothing to do with throughput. It's bandwidth.

But it doesn't matter what it is, you simply don't like the idea. Why didn't you just say so? There will always be haters. Lots of others like it. And if it remains, like loaders, in the domain of mods then you can simply not install mods that use it.

i mean, you can already implement that in a mod using omnilib or one of the other mod libraries that assists in updating recipes that are in-use around the map.

it's not that i don't like the idea, infinite research is fine. it's that it won't work well, so i don't think there's much point in wube putting effort into it, when mods can already do the same.

most of the ideas presented here are basically a no-go from me simply because of their complexity. for instance, changing icon size in the inventory to be physically larger, or consume 2x2 spaces on belt. this is beyond a typical mod interface request.

Icon size in inventory is already existing in the equipment grid. That is probably the most trivial feature and why I suggested it as a way to visually separate compressed and normal icons (and to offset the inventory increase an e.g. 20x compression would give).

As for being able to do the same. No, that's the whole point of the suggestion. To add to the game the things mod can NOT do. The biggest point I believe was to NOT add a million of duplicate recipes.

As for the complexity of having 2x2 spaces on the belt I have to agree with you. Visually it would probably be great but to implement that is probably a nightmare. I'm not holding my breath on that one. But hopefully the assembler / recipe part wouldn't be too hard.

[ptx0]

furnaces already sorta solve the recipe problem, stacked item goes in, stacked item comes out. assemblers could do the same.. but i don't see lots of recipes as a problem.

[mrvn]

furnaces already sorta solve the recipe problem, stacked item goes in, stacked item comes out. assemblers could do the same.. but i don't see lots of recipes as a problem.

Assemblers can't pick. The user has to choose. And you are talking about adding every variation of compressed and uncompressed input and compressed and uncompressed output. That's 4 recipes for 1 ingreedient. 8 for 2, 16 for 3, 32 for 4. And there are modded games that already have 11000+ recipes causing a big performance problems for furnaces (improvement pending for after 1.0 release). The game and more importantly the user would not love having half a million recipes. Multiply that by how many compression levels can be researched if we would go that way.

[NotRexButCaesar]

edit by ssilk: I’m really sorry, but I obviously hit “edit” instead of “quote”. Never happened before. And removed AmericanPatriots post nearly completely. This is, what remained:

Compression is already there and weather you love it or hate it is not a valid concern but an opinion. So lets please let us get back on topic on how the game could support it better.

I’m pretty sure most people (or at least the op)here were asking for it in the base game

[Koub]

I’m pretty sure most people (or at least the op)here were asking for it in the base game

I'm amongst those who think it would alter the balance of vanilla experience, thus would rather not see it in vanilla, but wouldn't care the game engine supporting it natively for modding, because once one start modding, the balance will necessarily be altered way more by most mods, even helper mods. A bit like the loaders.

However, if the dev team investing significant time and effort to integrate support for stacking in the game means them having less time to add what I feel would benefit more to the game, then I'd rather they used their time better. The most precious resource one can't afford to spoil is time, because it's the least recoverable.

[NotRexButCaesar]

I’m pretty sure most people (or at least the op)here were asking for it in the base game

I'm amongst those who think it would alter the balance of vanilla experience, thus would rather not see it in vanilla, but wouldn't care the game engine supporting it natively for modding, because once one start modding, the balance will necessarily be altered way more by most mods, even helper mods. A bit like the loaders.

However, if the dev team investing significant time and effort to integrate support for stacking in the game means them having less time to add what I feel would benefit more to the game, then I'd rather they used their time better. The most precious resource one can't afford to spoil is time, because it's the least recoverable.

+1

[ptx0]

However, if the dev team investing significant time and effort to integrate support for stacking in the game means them having less time to add what I feel would benefit more to the game, then I'd rather they used their time better. The most precious resource one can't afford to spoil is time, because it's the least recoverable.

translation: "if it's important to me it's not a waste of time"

[Koub]

However, if the dev team investing significant time and effort to integrate support for stacking in the game means them having less time to add what I feel would benefit more to the game, then I'd rather they used their time better. The most precious resource one can't afford to spoil is time, because it's the least recoverable.

translation: "if it's important to me it's not a waste of time"

Of course I'd rather see the devs spend time on subjects I deem more important to the game .

Thanks captain.gif (1.68 MiB) Viewed 4019 times

[ssilk]

Compression is already there and weather you love it or hate it is not a valid concern but an opinion. So lets please let us get back on topic on how the game could support it better.

I’m pretty sure most people (or at least the op)here were asking for it in the base game

Ah. Hm. Good point. I think that is the most critical part of this suggestion.

My first thought when writing this was, to just add better support for compression. But when I thought through it I saw (while writing), that adding this but not having a real implementation anywhere is bad in many ways: a) why should wube put manpower in some new feature, that is only available by third party mod? b) it can be made so, that it doesn’t change the “normal” game. c) how will you test it, without really playing?

So, yes, it’s meant as support (as the subject says), but no, it makes (economically) no sense to add only support and then not use it.

Now when I think again over it, and after this big discussion, it is eventually so that the time for such a vanilla game change is not ready yet. And that it is better, that modders do first implementations, with this better support.

What could be done into vanilla to test it, is a basic support for barreling - so that barreling won’t break your fluid statistics (nothing else). I think that making this work is already hard enough. What this misses is, that barreling is this type of compression that I described as “compression with container and expansion reveals container “. Which doesn’t include, that the game can automatically support it, as in this suggestion (You need a kind of recipe to do that). But I hope the devs will implement the remaining stuff either.

With that we will have both: wube has a working support for compression in game and modders can use that to do make a balanced mod, that use that.

[ptx0]

What could be done into vanilla to test it, is a basic support for barreling - so that barreling won’t break your fluid statistics (nothing else). I think that making this work is already hard enough. What this misses is, that barreling is this type of compression that I described as “compression with container and expansion reveals container “. Which doesn’t include, that the game can automatically support it, as in this suggestion (You need a kind of recipe to do that). But I hope the devs will implement the remaining stuff either.

With that we will have both: wube has a working support for compression in game and modders can use that to do make a balanced mod, that use that.

this not a problem as it is already, barrelling really is consuming lubricant and the unbarrelling machines are producing it.. what would you prefer they show as? invisible? it is not merely another transport line.

i like having my compressed stuff separate from regular. because then i can see production stats and where things are getting choked out.

[ssilk]

this not a problem as it is already, barrelling really is consuming lubricant and the unbarrelling machines are producing it.. what would you prefer they show as? invisible? it is not merely another transport line.

You see a doubled production/consumption. I want to see only the production/consumption without the barreling process. And when counting the barrels in a chest I see xxx fluids + yyy barrels and not zzz barreled fluids.

i like having my compressed stuff separate from regular. because then i can see production stats and where things are getting choked out.

But that’s the point of this suggestion: it should make no difference if I have compressed or normal items (and fluids), they are counted in equivalents.

[Sopel]

Generally I don't like this idea for vanilla game, and most of the points were presented by others in this threads. I would like it however if compression became better in mods, so incidentally I would like it for the base game to give more tools for that to happen.

Nevertheless, I have some thoughts regarding the proposal itself.

I like the original idea of compressed items taking both belt lanes, but I'm almost certain it's impossible to implement without severily harming performance given how belts work currently. However, how about disallowing compressed items to go on the normal belts and introducing "reinforced" belts that have only one transport line and allow compressed items to go on it? This, I think, would be the least problematic way of implementing this while keeping it clean.

IMO fluid compression DOES have similar impact to compressed items. Pipes also have limited throughput, trains have limited fluid capacity that's proportional to item capacity. Increasing item counts will inevitably increase the fluid counts.

I think the compression ratio should be 10 both for items and for fluids.

The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

[ptx0]

The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

here we go, finally, a suggestion here that makes sense.

i have to often do belt -> loader -> beltbox -> loader -> loader -> buffer box. it's awful.

[mrvn]

The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

here we go, finally, a suggestion here that makes sense.

i have to often do belt -> loader -> beltbox -> loader -> loader -> buffer box. it's awful.

Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

I think the usage of loader -> compressor -> loader should remain, where compressor can be an assembler set to "(un)compress only". In this mode you would select the item to compress or uncompress or <any>. This setup should only be used rarely as there would be no need for it. If you want compressed items on the belt the normal way would be to select compressed output at the miner / furnace / assembler that produces said items.

Note: compressing mixed items (with loaders) rarely works out as you have to count perfect or it deadlocks. Compressing <any> really only make sense with a lot of circuit logic. Doubtfull anyone would cry if that doesn't even exist.

Only reason I can think of for the dedicated processor would be to convert existing stock (because you want to more than need to) or to uncompress a small quantity if bots aren't allowed to carry compressed items. Otherwise the goal of the proposal was to make compression transparent so you don't have to compress/uncompress manually.

[Sopel]

If compression gets at least *some* help from the base game then an entity that automatically compresses stuff on the transport line is gonna be at least a magnitude faster than a loader -> compressor -> loader

[foamy]

The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

here we go, finally, a suggestion here that makes sense.

i have to often do belt -> loader -> beltbox -> loader -> loader -> buffer box. it's awful.

Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

Is for me. You can get outright stupid amounts of throughput by doing direct insertion from beltboxes to assemblers -- blue chip layouts, for example, can benefit enormously from it, since green chip throughput is the limiting factor there.