Better Compression (Stacking/Boxing/Pallets) Support

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by mrvn »

ptx0 wrote:
Fri Aug 07, 2020 8:17 pm
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.

User avatar
NotRexButCaesar
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Sun Feb 16, 2020 12:47 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by NotRexButCaesar »

mrvn wrote:
Fri Aug 07, 2020 9:00 pm
ptx0 wrote:
Fri Aug 07, 2020 8:17 pm
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.
—Crevez, chiens, si vous n'étes pas contents!

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by mrvn »

AmericanPatriot wrote:
Sat Aug 08, 2020 1:14 am
mrvn wrote:
Fri Aug 07, 2020 9:00 pm
ptx0 wrote:
Fri Aug 07, 2020 8:17 pm
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.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1507
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ptx0 »

mrvn wrote:
Fri Aug 07, 2020 9:00 pm
ptx0 wrote:
Fri Aug 07, 2020 8:17 pm
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
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by mrvn »

ptx0 wrote:
Sat Aug 08, 2020 4:23 am
mrvn wrote:
Fri Aug 07, 2020 9:00 pm
ptx0 wrote:
Fri Aug 07, 2020 8:17 pm
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.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1507
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by 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
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by mrvn »

ptx0 wrote:
Sat Aug 08, 2020 5:07 am
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.

User avatar
NotRexButCaesar
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Sun Feb 16, 2020 12:47 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by NotRexButCaesar »

edit by ssilk: I’m really sorry, but I obviously hit “edit” instead of “quote”. :oops: Never happened before. :oops: And removed AmericanPatriots post nearly completely. This is, what remained:
mrvn wrote:
Sat Aug 08, 2020 4:19 am
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
—Crevez, chiens, si vous n'étes pas contents!

Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by Koub »

AmericanPatriot wrote:
Sat Aug 08, 2020 2:05 pm
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.
Koub - Please consider English is not my native language.

User avatar
NotRexButCaesar
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Sun Feb 16, 2020 12:47 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by NotRexButCaesar »

Koub wrote:
Sat Aug 08, 2020 2:56 pm
AmericanPatriot wrote:
Sat Aug 08, 2020 2:05 pm
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
—Crevez, chiens, si vous n'étes pas contents!

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1507
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ptx0 »

Koub wrote:
Sat Aug 08, 2020 2:56 pm
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
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by Koub »

ptx0 wrote:
Sat Aug 08, 2020 9:40 pm
Koub wrote:
Sat Aug 08, 2020 2:56 pm
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 :lol: .
Thanks captain.gif
Thanks captain.gif (1.68 MiB) Viewed 3184 times
Koub - Please consider English is not my native language.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ssilk »

mrvn wrote:
Sat Aug 08, 2020 4:19 am
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.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1507
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ptx0 »

ssilk wrote:
Sun Aug 09, 2020 7:18 am
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.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ssilk »

ptx0 wrote:
Sun Aug 09, 2020 9:26 pm
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.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Sopel
Long Handed Inserter
Long Handed Inserter
Posts: 61
Joined: Mon Sep 24, 2018 8:30 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by 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.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1507
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by ptx0 »

Sopel wrote:
Mon Aug 10, 2020 10:35 am
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
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by mrvn »

ptx0 wrote:
Mon Aug 10, 2020 2:57 pm
Sopel wrote:
Mon Aug 10, 2020 10:35 am
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
Long Handed Inserter
Long Handed Inserter
Posts: 61
Joined: Mon Sep 24, 2018 8:30 pm
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by 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
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: Better Compression (Stacking/Boxing/Pallets) Support

Post by foamy »

mrvn wrote:
Mon Aug 10, 2020 4:42 pm
ptx0 wrote:
Mon Aug 10, 2020 2:57 pm
Sopel wrote:
Mon Aug 10, 2020 10:35 am
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.

Post Reply

Return to “Ideas and Suggestions”