Better Compression (Stacking/Boxing/Pallets) Support

[ptx0]

also, it helps bots too.

This is frankly an argument against it in my books. :v

The thing about compression is that there's significant jumps in the complexity of belt handling as you go beyond one or two belts of material to, say, eight and up, but once you're at that point going even further starts turning into 'more of the same'. Compression significantly delays the point where you need to start doing more complex things with belts, hence keeping the player from being presented with a problem and a puzzle, and that's a bad thing in a game that is, ultimately, about problem- and puzzle-solving.

On the other hand, once you hit megabase territory, mass throughput starts becoming less of a challenge and more of a chore, e.g.:

well, if those 'puzzles' didn't destroy the performance of the game, sure. but it's not performant to do those things you've pictured, so... i.. won't do them. i just never will - and trains are doable within about 45 minutes of starting a map, and they also completely negate the 'need' to do puzzles like that.

no one is stopping you from doing your belt puzzles.

[mmmPI]

https://www.factorio.com/blog/post/fff-224 Friday Facts #224 Bots versus belts
https://www.factorio.com/blog/post/fff-225 Friday Facts #225 - Bots versus belts (part 2)

It seemed at the time that bots were considered too powerfull, they used to be a blue-chemical science technology. They were pushed back to purple-logistic science for this reason and nerfed on charging time i think.

Later belt were further optimized making them more viable perfomance wise in the late game. It seemed that a compromise making them both viable was researched ( and found ).

it's a matter of preference, but you can also finish the game in 2 or 3 hours and don't use trains at all.
you can also not use belts at all, or not use bots at all.

a modification in the vanilla game that would shift the optimal solution toward one or another end would be "controversial" according to the words used in those FFF.
There was also lots of complains when bots where locked behind purple science.

No-one is preventing others to do things, it's just that making one or another playstyle WAY easier/convenient/ups efficient would change how one has to play in order to reach the maxium SPM at decent ups on a given specs, which would then gives incentives to one or another playstyle. And ultimatly may reduce the diversity of solution that are considered viable late-game. no-one wants that right ? balancing is a tough matter.

[NotRexButCaesar]

https://www.factorio.com/blog/post/fff-224 Friday Facts #224 Bots versus belts
https://www.factorio.com/blog/post/fff-225 Friday Facts #225 - Bots versus belts (part 2)

It seemed at the time that bots were considered too powerfull, they used to be a blue-chemical science technology. They were pushed back to purple-logistic science for this reason and nerfed on charging time i think.

Later belt were further optimized making them more viable perfomance wise in the late game. It seemed that a compromise making them both viable was researched ( and found ).

it's a matter of preference, but you can also finish the game in 2 or 3 hours and don't use trains at all.
you can also not use belts at all, or not use bots at all.

a modification in the vanilla game that would shift the optimal solution toward one or another end would be "controversial" according to the words used in those FFF.
There was also lots of complains when bots where locked behind purple science.

No-one is preventing others to do things, it's just that making one or another playstyle WAY easier/convenient/ups efficient would change how one has to play in order to reach the maxium SPM at decent ups on a given specs, which would then gives incentives to one or another playstyle. And ultimatly may reduce the diversity of solution that are considered viable late-game. no-one wants that right ? balancing is a tough matter.

This last paragraph really stated clearly what I was trying to say earlier.

[mrvn]

also, it helps bots too.

This is frankly an argument against it in my books. :v

The thing about compression is that there's significant jumps in the complexity of belt handling as you go beyond one or two belts of material to, say, eight and up, but once you're at that point going even further starts turning into 'more of the same'. Compression significantly delays the point where you need to start doing more complex things with belts, hence keeping the player from being presented with a problem and a puzzle, and that's a bad thing in a game that is, ultimately, about problem- and puzzle-solving.

On the other hand, once you hit megabase territory, mass throughput starts becoming less of a challenge and more of a chore, e.g.:

Which simply points to wards compressing having a high tech requirement. Maybe even space science. Post rocket launch is where you get into mega base territory.

And hey, here is a fun idea. Compression could be an infinite tech. First research gets you 2x compression, next one 3x, then 4x. Given how fast infinite tech costs rise this shouldn't give insane compressions. The universe will die the heat death before you hit 64x compression.

[ptx0]

And hey, here is a fun idea. Compression could be an infinite tech. First research gets you 2x compression, next one 3x, then 4x. Given how fast infinite tech costs rise this shouldn't give insane compressions. The universe will die the heat death before you hit 64x compression.

that would actually make it less useful eventually.. similar to high stack sizes for inserters. it will slow down throughput while your stacking machines wait for input (the belt speeds are finite).

[foamy]

well, if those 'puzzles' didn't destroy the performance of the game, sure. but it's not performant to do those things you've pictured, so... i.. won't do them. i just never will - and trains are doable within about 45 minutes of starting a map, and they also completely negate the 'need' to do puzzles like that.

no one is stopping you from doing your belt puzzles.

Base uses trains extensively, look at the minimap. Even with trains you've got the issues of gathering up & getting material to and from the train stop; ultimately it can actually take more stuff to do that than simply direct connections between major users (e.g., gear farm -> belt factory, smelter-> chip farm). The increases in complexity that come with N-to-N systems for the trains and the like if you spam stops are also challenges, of course -- and are also issues a compression system renders much less notable. Especially when it comes to getting mass throughput out of them, since effectively a train station now has X times the throughput in the same space.

[ptx0]

well, if those 'puzzles' didn't destroy the performance of the game, sure. but it's not performant to do those things you've pictured, so... i.. won't do them. i just never will - and trains are doable within about 45 minutes of starting a map, and they also completely negate the 'need' to do puzzles like that.

no one is stopping you from doing your belt puzzles.

Base uses trains extensively, look at the minimap. Even with trains you've got the issues of gathering up & getting material to and from the train stop; ultimately it can actually take more stuff to do that than simply direct connections between major users (e.g., gear farm -> belt factory, smelter-> chip farm). The increases in complexity that come with N-to-N systems for the trains and the like if you spam stops are also challenges, of course -- and are also issues a compression system renders much less notable. Especially when it comes to getting mass throughput out of them, since effectively a train station now has X times the throughput in the same space.

if you want issues or puzzles to solve, you'll find them anywhere. OR, you can do like me and just use one belt off each wagon from the train. each wagon goes to a group of assemblers, they all get the same number of beacons, modules - so the train always unloads evenly. no need for circuits, "belt balancers" or other nonsense "puzzles". each group of assemblers loads into its own wagon car on the other side.

[ptx0]

Base uses trains extensively, look at the minimap.

fwiw, those diagonal stackers are really bad for performance and probably responsible for your UPS problems there.

[foamy]

if you want issues or puzzles to solve, you'll find them anywhere. OR, you can do like me and just use one belt off each wagon from the train. each wagon goes to a group of assemblers, they all get the same number of beacons, modules - so the train always unloads evenly. no need for circuits, "belt balancers" or other nonsense "puzzles". each group of assemblers loads into its own wagon car on the other side.

This is literally a solution to a problem that you're presenting as evidence you don't need to solve a problem. Plus you're pushing the complexity downstream to your train network in any case.

fwiw, those diagonal stackers are really bad for performance and probably responsible for your UPS problems there.

Unlikely. The detailed UPS breakdown shows the entirety of the train stuff using less time than the electrical network and far less than, e.g., the entity breakdown.

The big UPS hit is the belts and the assemblers/inserters/etc. It's a MP base that is my first crack at something you could reasonably call a megabase (albiet a small one) so there's not been a lot of optimization done for that over, in priority order, 1. works, 2. to output spec, 3. looks cool :v

The box it runs on is nevertheless capable of running it at 60 UPS. I have things throttled because of FPS issues on my own local end.

[ptx0]

Unlikely. The detailed UPS breakdown shows the entirety of the train stuff using less time than the electrical network and far less than, e.g., the entity breakdown.

wrong: https://mulark.github.io/test-index.html

[foamy]

Unlikely. The detailed UPS breakdown shows the entirety of the train stuff using less time than the electrical network and far less than, e.g., the entity breakdown.

wrong: https://mulark.github.io/test-index.html

The actual ingame time breakdown shows the trains at consistently < 1 ms. In the context of the 6+ ms chewed by entities and belts each, the advantages of switching stackers from diagonal -- which are inherently short, compared to the mainline train distances -- is not worth pursuing.

That diagonal trains might be less UPS efficient I don't argue (though I note that that test is a year and a half old now, and the game's undergone fairly major revision) but that it's the cause of <60 UPS? Nah.

[ptx0]

The actual ingame time breakdown shows the trains at consistently < 1 ms. In the context of the 6+ ms chewed by entities and belts each, the advantages of switching stackers from diagonal -- which are inherently short, compared to the mainline train distances -- is not worth pursuing.

That diagonal trains might be less UPS efficient I don't argue (though I note that that test is a year and a half old now, and the game's undergone fairly major revision) but that it's the cause of <60 UPS? Nah.

it's the collision checks that are screwing things up, those haven't changed. you are thinking of train pathfinder changes. in any case, you've sorta massively derailed the whole conversation to discuss puzzles and now, UPS.

[ptx0]

No-one is preventing others to do things, it's just that making one or another playstyle WAY easier/convenient/ups efficient would change how one has to play in order to reach the maxium SPM at decent ups on a given specs, which would then gives incentives to one or another playstyle. And ultimatly may reduce the diversity of solution that are considered viable late-game. no-one wants that right ? balancing is a tough matter.

okay, but beacons, speed, and productivity modules already do this. you can see this in every vanilla megabase.

remember, compressed items help trains, bots, AND belts. barrelling is amazing for UPS, but hardly utilised.

[NotRexButCaesar]

The actual ingame time breakdown shows the trains at consistently < 1 ms. In the context of the 6+ ms chewed by entities and belts each, the advantages of switching stackers from diagonal -- which are inherently short, compared to the mainline train distances -- is not worth pursuing.

That diagonal trains might be less UPS efficient I don't argue (though I note that that test is a year and a half old now, and the game's undergone fairly major revision) but that it's the cause of <60 UPS? Nah.

it's the collision checks that are screwing things up, those haven't changed. you are thinking of train pathfinder changes. in any case, you've sorta massively derailed the whole conversation to discuss puzzles and now, UPS.

Do trains do collision checks when stopped?

[mmmPI]

okay, but beacons, speed, and productivity modules already do this. you can see this in every vanilla megabase.

remember, compressed items help trains, bots, AND belts. barrelling is amazing for UPS, but hardly utilised.

you are missing the point, beacons speed and prod modules are part of what is used to produce/transform item, it is unrelated to the logistic which consist into moving items around.

If the idea is changing belts so that it creates an optimal way that would incentive using only 1 lane of belt everywhere it's just removing one very defining aspect of factorio which is the management of several parralel belts/ balancers and things you called non-sense puzzle. and i think it makes the game boring.

i'm gonna quote kovarex in the FFF225

"The question is, how to approach this problem? As Twinsen said, making belts stronger would not only be a compromise in some way and it would also reduce the amount of moving things, which is the proper metric in my eyes. When you see a huge factory, it is cool, because there are 16 blue iron belts being filled, not because the output is X per minute.".

Now if the compression/stacking/boxing is ever implemented, and it happens to render the previously mentionned "non-sense puzzle" useless in the game compared to just using trains and bots ( because why use 1 lane of belts ? if bots are better for short distance ) then it would be seen as a change that drastically shift paradigm of the game.

It's ok for you to have your own preference about how you want your factory. it's not ok saying it's the only way/ best way and disregarding other players objections because you think they shouldn't be doing what they do. because that would mean the diversity of transport means aka LOGISTIC, would reduce to the only one and optimum way to do. This downgrade the game and makes it boring.

Sure speed and prod modules alongside with beacons are present in every megabase, but making the game so that what most players are doing is rendered obsolete due to implementing a vastly superior way of doing LOGISTIC is not going to happen i hope. Compression could be a nice addition, but it has to be carefully balance in order to preserve the equilibrium that exists between the different means of transporting goods.

And advocating that compressions is thought to only push further one way of doing things (because others are inefficient so shouldn't be taken in consideration) is counter-productive.

And i'm saying all that even if i personnaly do not use parralel belts and bus style factory often. It's still what is the most frequently used amongst players. Not because it's the "best" (ups-efficient) but i suppose because it's the most straightforward, easy to understand, expand, build cooperatively ,and looks cool. I don't think compression should be advocated because it renders the later "useless" because in this case it's never going to happen.

[mrvn]

And hey, here is a fun idea. Compression could be an infinite tech. First research gets you 2x compression, next one 3x, then 4x. Given how fast infinite tech costs rise this shouldn't give insane compressions. The universe will die the heat death before you hit 64x compression.

that would actually make it less useful eventually.. similar to high stack sizes for inserters. it will slow down throughput while your stacking machines wait for input (the belt speeds are finite).

It will not change throughput at all. If your machine has 10 items / s throughput then it will have 10 items/s throughput with compression 2, 3, 4, 5, ... If compression is turned on it just means you get a compressed item less often.

Note: for the compression factor to be a research item each compressed item would have to remember it's compression factor. Otherwise going from compression 2 to 3 you would suddenly gain 50% items. And if items have a compression factor then the machines could also have an "Override compression factor = N" for the output.

Could be fun. You could produce compressed items for different materials where the compression factors reflect the ratios in the recipe. So instead of taking 3 copper wire and 2 iron plate you would use copper wire (3x compressed) and iron plate (2x compressed). Mixing and matching compression factors would be another puzzle you can play.

[ptx0]

It will not change throughput at all.[...] it just means you get a compressed item less often.

wut? that's ... a.. change in throughput... along with all of the distribution changes that come from having a split-off bus now moving more dense packages along. upstream will get more dense shipments, downstream will... ye know, i'm not even going to try and continue arguing any of this.

i think it's going way over all of the haters' heads that this is meant for mods to enable. the OP is asking for better support in the base game engine for mod features to take advantage of.

people will come along and complain about balance or cheating or whatever, with any change that is suggested to the game. you can't please everyone.

good luck with all your dumb arguing.

[NotRexButCaesar]

It will not change throughput at all.[...] it just means you get a compressed item less often.

wut? that's ... a.. change in throughput... along with all of the distribution changes that come from having a split-off bus now moving more dense packages along. upstream will get more dense shipments, downstream will... ye know, i'm not even going to try and continue arguing any of this.

i think it's going way over all of the haters' heads that this is meant for mods to enable. the OP is asking for better support in the base game engine for mod features to take advantage of.

people will come along and complain about balance or cheating or whatever, with any change that is suggested to the game. you can't please everyone.

good luck with all your dumb arguing.

I don’t think the OP is asking for a modding stem, I think they are asking for it to be implemented in the base game. I would be fine, even happy, if a modding only hidden item, like the loader were added.

[mrvn]

It will not change throughput at all.[...] it just means you get a compressed item less often.

wut? that's ... a.. change in throughput... along with all of the distribution changes that come from having a split-off bus now moving more dense packages along. upstream will get more dense shipments, downstream will... ye know, i'm not even going to try and continue arguing any of this.

I think we are talking about different things.

A miner will produce 1 ore/s. Now you research compression and turn it on for the miner and the miner will still produce 1 ore/s. Except now it outputs a 2x ore every 2 seconds. The same goes for the furnace. It gets 1 ore/s and will produce 1 plate/s. With compression it gets a 2x ore every 2 seconds (still 1 ore/s) and produce a 2x plate every 2 seconds (still 1 plate/s). No matter what compression factor the throughput remains the same. The proposed solution is that the recipe time scales with the compression so that the throughput remains constant.

You seem to be talking about belt throughput, which is in actual game items/s. There the throughput increases with the compression factor. Going from uncompressed to 2x compressed is like going from yellow to red belts. Except for the idea that compressed items take 2x2 space on the belt. That actually would mean 2x compressed items have half the throughput on belts. Still double the throughput on inserters. With the 2x2 size idea compression should start at 4 (break even) - 8 (twice the belt throughput).

[ptx0]

It will not change throughput at all.[...] it just means you get a compressed item less often.

wut? that's ... a.. change in throughput... along with all of the distribution changes that come from having a split-off bus now moving more dense packages along. upstream will get more dense shipments, downstream will... ye know, i'm not even going to try and continue arguing any of this.

I think we are talking about different things.

A miner will produce 1 ore/s. Now you research compression and turn it on for the miner and the miner will still produce 1 ore/s. Except now it outputs a 2x ore every 2 seconds. The same goes for the furnace. It gets 1 ore/s and will produce 1 plate/s. With compression it gets a 2x ore every 2 seconds (still 1 ore/s) and produce a 2x plate every 2 seconds (still 1 plate/s). No matter what compression factor the throughput remains the same. The proposed solution is that the recipe time scales with the compression so that the throughput remains constant.

You seem to be talking about belt throughput, which is in actual game items/s. There the throughput increases with the compression factor. Going from uncompressed to 2x compressed is like going from yellow to red belts. Except for the idea that compressed items take 2x2 space on the belt. That actually would mean 2x compressed items have half the throughput on belts. Still double the throughput on inserters. With the 2x2 size idea compression should start at 4 (break even) - 8 (twice the belt throughput).

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.