Factorio Forums

This will be a longer post, so I first will do an introduction about stacking or better compression. Then the pros and cons and then go over to what is missing as suggestions about what to change and how.

BTW: In this post I use only the term "compression", because "stack" is in Factorio already used, it means one stack of items in an inventory. A compressed item can also be stacked in this way of course. "Compression" in Factorio means also belt-compression, when a belt is fully compressed with items, but I think this two kinds of compression can be distingushed easily.

First of all I love compressed items. I wrote an article long time ago
viewtopic.php?f=80&t=19343 Boxing / Packaging / Container / Cargobox : Pre-Filling
but I think this is quite out of date and not longer actual.

So I played with those mods around more than four years. Alone with https://mods.factorio.com/mod/deadlock- ... es-loaders (The most famous and most supported) since it’s release. And I think I really know what’s good or bad with this kind of playing.

What is Compression?

Compression, (often also called stacking, boxing) is a way to use the compression techniques we already know from the chests and so on to create new items out of some (of the same type) and vice versa.


For example you can create a compressed iron plate from 20 iron plates. But there are also mods that can create a mixed box of items. E.g. from 100 iron plates and 300 copper wires. That box contains all, that is needed to create 100 electronic circuits. Or one box of electronic circuits. That
is out of scope here.

Other mods need a container. E.g. a wooden box plus 20 iron plates -> 1 wooden box with iron. Expanding those boxes has two variants: a) the box/container is not destroyed and ready for reuse b) the box/container is destroyed. Variant a) gives a quite interesting new game play, because you need not only to transport items in one direction, but also the boxes/containers back.

To sum this up to all possible kinds of gameplay for “compression”:
1. without container
1.1. one item-type
1.2. different item-types
2. With container
2.1. container is destroyed on expansion
2.2. Container is part of expansion-recipe (not destroyed but eventually in parts)



And there are many combinations and other variants of this. For example when the container is destroyed, but the ingredients of it come out and you need to reassemble it.

For the further post I refer only to 1.1. compression without container and especially not with mixed items types - I think you can achieve the advantages of that with compressed recipes. But generally there is not much difference in gameplay between 1.1 and 2.1.

Compressed recipes

This all doesn’t make much sense, if you don’t have receipts that can handle compressed items. Because otherwise you can compress the transport from your mines to the smelters, but before you can smelt it, you need to expand it. What you really want is to put the compressed iron into the smelter and out comes compressed Iron plates.

Pros and Cons of Compression

Pros
- compression introduces kind of new gameplay, especially for the type 2.2. It needs/allows a completely different gameplay. But that kind of material flow is also used in other combinations in some big mods.
- it increases the transport capacity of everything to astonishing amounts ( depends on how it is balanced)
- markable reduction of CPU load, especially with compressed recipes and big compression factors.
- no need to make multiple rows of belts to transport the items (I currently play a game where I feed over 200 smelters by one belt)
- a bit simpler train stations
- no need for big chests-mod/warehouse.
- enables long games without much fear, that youp only repair bottlenecks.
- EDIT: it enables to "overpower" entities (entities which craft faster than 1 tick), or entities which need so much resources, that you cannot feed it in fast enough with normal stack inserters.
- EDIT: You can use "mixed belts", where you can produce items like in a factory street (belts goes round, things get produced and you can add or remove items from belt as needed). This is not possible with normal items, because you very soon get throughput problems.

And some subjective aspects: feels like next generation Factorio - I mean it allows to transport so much more items, that the aspects of Factorio shifts from small little things much more to the overall functionality of you Factory. I think this is a useful turn.

Cons
- it introduces a lot more items, the expanded (normal) and the compressed versions. This is much harder if you play with mods. Plus: when playing with compressed recipes also a lot more recipes. Which makes it difficult if you mix them.
- you have two versions of the same item. But the game cannot handle them as the same. This feels clunky.
- it introduces new icons for the compressed items, which are sometimes hard to distinguish.
- if you produce 20 iron ore and create one item of compressed iron ore out of it, then you see in the statistics a production 20 iron ore, a consumption of 20 iron ore and a production of 1 compressed iron ore. This feels totally wrong. Stats don’t work anymore with compression.
- it isn’t worth the effort, if you just want to make a fast game. I mean: if you plan to continue after rocket launch, this is quite useful.
- a recipe can consume either compressed or normal items. A mix isn’t possible. Or let’s say better: it would be possible to generate a recipe of every combination between compressed and normal items. But Factorio is not able to hide that all for the player in a clean and nice way.
- the belts and inserters are not moving so much anymore. Depends on compression factor.
- similar issue: you cannot see immediately how the state of the factory is. This is because the belts and inserters move much more seldom. This is also nothing which someone gets used to. You need to measure much more (which someone might see as an advantage ).
- the player can pickup compressed items like other items. It feels a bit strange. - some mods will automagically expand picked up items in the player inventory , but this makes a lot of problems with limited inventory size.
- if you don’t have the above feature and need just 1 item of red circuits but you only have compressed ones you need to built something to unbox it and don’t know what to do with the remaining. See mixing of the recipes above.
- inserting the items with inserter to compress them feels quite clunky. Using a loader (as in deadlocks mod, see link above), is a very useful solution.
- playing with compression if you have only low amounts of items (left) is a no no. Even with medium amounts of items this is not a good idea. It's only useful, if it doesn't matter if there is a buffer of 300 items before a new compressed item is produced. Even equal distribution is a problem, if you have low amounts of compressed items.

So much cons? Well, they don’t feel so bad, when you play with it. And obviously many people like to play with it, if you look at the download numbers of deadlocks mod.

Solving the Issues

So here we come to the suggestion part.

A new research “compression techniques“
This research enables

a) Compressors. Can be used to compress/expand items. It takes a lot of energy to do that, but that is balancing.

b) a new button in the assemblies / smelters: output either normal (default) or compressed item(s) (+ the number of items needed for one compressed item) (*)

c) the ability to assemble/craft from compressed items. Besides the useful compressors there should be a second way to get expanded items. In that case a compressed item is expanded automagically, the needed items are taken and the remains go back into the inventory (of player, assembly or whatever). It prefers to pick up normal items first before expanding a new compressed item.

Eventually we can reduce the default player inventory size, because of this. I also can think of another research that automatically compresses unused items if picked up.

(*) I thought also that it could be a good idea to have a third switch position: "output compression from input compression", which means, if the input item is compressed the output will be also compressed. In doubt (one item compressed the other normal) the normal wins.

New reasearch “loader”
As in deadlocks mod, the loader makes the difference! I think it's very important to have it, otherwise all the inserters that are needed don't make fun.
The compact loader makes in my eyes really fun to use and you wonder how much other things you can do with it. I think this is a really simple increase of gameplay with not so much effort.

No difference between item and compressed item

I think this a difficult change to Factorio. There should be no difference in counting items. A compressed item with 20 iron ore should count as 20 iron ore and not as 1 compressed iron ore. This would solve all issues with the brocken statistics/inventory containsr.

To make it clear: the compression (or expansion) of items doesn’t count as consumption. As the expansion doesn’t count as production.

What is with the logistics?
The requester has a new switch: prefer normal items/prefer compressed items.

In the selector the number of compressed items should be calculated.
If 1 item is requested and it prefers compressed items it requests one .

What’s with signals?
A compressed items emits two signal: the number of expanded items and itself (the compressed item). There should be a way to check in a decider combinator if the signal contains compressed signals and emit/filter only those.

Inserters/Splitters
Inserters can either have a new switch "prefer compressed item" as the logistics, or there is a filter item which matches for compressed items. Similar with splitters.

Factorio can generate compressed-items-icon itself
It should be so, that the icons for the compressed version of items can be generated by Factorio internally during startup (for the case that the icon doesn’t bring it’s own compressed icon of course).

For example https://mods.factorio.com/mod/deadlock_stacked_recipes does something like that, the icons are pre-generated in half-automatic and the result is a palette as base and three stapled items on that palette.

I wish Factorio can automate this kind of generating the icons to a new one. The modder should be allowed to fine-tune any aspect of this (fine-position any of the icons, change color/tint, use any icon he wants). I think this would also be quite useful for other use cases.

Compressed liquids

They should work similar to compressed items. But that is in my eyes a completly new suggestion and in my eyes the gameplay value is not so high.

Balancing
I need to mention here that balancing is difficult. It makes not much sense to let the user choose the compression. However I can say that I played with compress-sizes between 10 items and full stacks (normaly 50, 100, 200), and the right value is surely something in between 10 and 50. Currently I play with compression factors of 25 items and that feels a bit too big and I would reduce it to something between 15 and 20. But see below.

Compressed items on belts take more space

This is the suggestion which I’m most unsure if it would be useful, because it would be really a big change and a lot of work. So this one at last.

To see the progress on belts (and inserters) better, and distinguish better between compressed and normal items, a compressed item is much bigger and takes both lanes from the belt. There could be compressed and normal items on one belt. But a compressed item blocks takes two lanes, even if one lane is free.
So a compressed item has the size of four items (just doubling the length and width). In that case I also think that the balancing needs to be a little bit higher.

This should solve parts of the problem, that you don’t see so well, how your Factory is going, when there are only compressed items on the belts. Bigger icons, need much more space on the belts and the belt needs to scroll more.

As said: quite experimental.


So hope this gets discussed; I think compressed items this is a way, Factorio should go.

ssilk wrote: ↑Sat Aug 01, 2020 2:57 pm
Compressed liquids

They should work similar to compressed items. But that is in my eyes a completly new suggestion and in my eyes the gameplay value is not so high.

These? https://mods.factorio.com/mod/CompressedFluids

We use those + the stacked recipes on our servers and literally stack/compress everything. The only thing we can't do stacked is: Space Science, and mining stacked ore directly (but I think there's a mod for that that too)

ssilk wrote: ↑Sat Aug 01, 2020 2:57 pm I think this a difficult change to Factorio. There should be no difference in counting items. A compressed item with 20 iron ore should count as 20 iron ore and not as 1 compressed iron ore. This would solve all issues with the brocken statistics/inventory containsr.

Recipes have fixed ingredients, you would need a change to the game engine to allow a recipe to pick from multiple different ingredients.

I create deadlock_stacked_recipes while playing a mod pack that had speed-25 modules. We found it impossible to feed the amount of resources needed to feed an assembley machine surounded with 12 beacon. You also quickly hit the 1x craft per tick limit.

As such someone suggested that we could use the stacked copper coils and iron plates to make stacked green circuits, the recipe was slowed down to to match the stack size. So there was no NETT loss. However as the recipes are now slower the ingredients could be feed with regular inserters and still propduce the same amount of resources in the end without hitting the crafting limit.

A couple of months back during a play-through of JD_Plays there were some comments that stacked fluid recipes were needed for a similar reason. I went back to the whiteboard and added support for Lovely_Stantas mod 'CompressedFluids' it if was installed into my recipes.

Compression would be so over powered as to be game breaking, or would add one extra step after mining and thereafter not change the game.

Going that path, i would want to compress the compressed-iron-ore, once my belt of compressed-iron-ore reach its thoughput limit.
With 5 iron ore making an "compressed-iron-ore". 5 of those would make a "box-of-compressed-iron-ore", which if you have 5 of them you could make a "container-of-boxed-compressed-iron-ore". And if you have 5 container you can make a "large-container-of-boxed-compressed-iron-ore". no ?

Sounds fun but given the popularity of the (simpler) fluid-wagon vs (more complicated) barreling system, i doubt this would sounds appealing to other people than already experienced players if "the container is not destroyed and you have to ship it back".


From personnal experience : Playing with angel's mod you can use molten copper to make copper wire, or you can make copper coil, which can be cut in several copper wire, same applies with molten iron that you can transform in iron plate, or in an intermediate product, iron sheet coil, that you can transport more efficiently before cutting it into several plate.

which is somewhat similar and enjoyable to play with.

when thinking about mixed item in container, you need tin and copper to make "tinned-copper-wire", which you can make using molten copper and molten tin at the same machine that can output either the desired "tinned-copper-wire", or you can make "tinned-copper-wire-coil" that you can cut later into individual wire piece, but you can also use "copper-wire-coil" that you cut into "copper-wire" and "tin-plate" (in a different machine) or even "copper-sheet-coil"=>"copper-plate"=>"copper-wire"+"tin-plate"=> "tinned-copper-wire".

It differs by making the compression process not fully revertible which is also fun

Some times ago i used a mod that seems to have disappeared at this moment, it was called "stack-furnace" allowing you to smelt 100 ore in one receipe, i did that to avoid building dozens of copy of the same smelting array, it was a good time/tedious saver, but felt this way only because others mods were making the game more complicated aside from this aspect, in a pure vanilla game, that might feel "overpowered" in the sense of smelting is where you are supposed to deal with mass raw items, and when they are transformed they become more "dense". One could avoid the logistical challenge of mass low-density-item, which i think is a defining aspect of the unmodded factorio experience. i fear it could be a bit boring if the natural solution would be to compress at all time and only use 1 single belt per material.

the only other "con" that sticked to my mind is the fact that statistic production can be misleading in some cases if you can't tell wether it's compressed or consumed. but if you can track the "production" of the "compressed-item" then you can math it out quickly thanks to the new UI of the production tab .

Also i think if you pick up some compressed material on a belt, it's ok to have the compressed material on your inventory, it's somewhat late game at this point and you should have made other places to gather material than straight up from the belt, plus at this stage you shouldn't be crafting a lot of stuff manually , so you won't be dealing too much with that problem , supposedly .

I've been playing in a K2/SpaceX game that's running compression, and it's been a godsend for things like a chipfarm, but it honestly feels pretty cheaty as well. It becomes simply too easy to move immense amounts of material into or out of machines -- for example by having them load directly from unstack boxes -- or production modules generally.

Didn't deadlock fix it so stacking and unsstacking wouldn't show up in the statistics?

I don't think compression should take much energy. Simply makes no sense for most things as you don't actually physically compress.

Stacking 5 iron plates on top of each other takes no energy at all. Just needs an inserter (ok some energy there) to lift the plates and put them in a stack. Or just make a little ramp in the belt that lifts the plates and let them stack. Every full stack the stack gets moved again. And belts need no energy.

Similar with iron ore. It's not compression so much as pressing it together so it forms a nice cube instead of being loose pebbles on the belts. The cube puts the same volume at the same density on a smaller area. That "compresses" the item but it's not really compression of the mater.

Now for gases compression is actually a thing and depending on the factor takes quite a bit of pressure and produces lots of heat. Expansion creates cold on the other hand. So those could reasonably take energy.

Liquids on the other hand are mostly not compressible again. Not sure how you would rationalize compressing water by a factor of say 25. Someone has to think of something for that. Some magic tech that reduces the atomic forces keeping molecules apart?

So my vote would be for compression to take none to just a little extra energy.


I like your idea of the game knowing about compressed items though. With that knowledge every recipe could work with compressed items in the same ratios as normal items at just multiply the time by the compression factor. There would be no need to new recipe icons. Just select the normal "iron gear wheels" recipe in an assembler and feed it compressed iron plates to get compressed iron gear wheels.

If assembler (and furnace and miner and ...) can automatically uncompress items then I think all there should be is a switch to tell it weather the output should be compressed or not. If you feed uncompressed items into an assembler and have selected compressed output then it either a) builds N cycles before outputing a compressed item (doessn't solve the 1 recipe per tick problem) or b) takes N time the input to create one compressed item in N times the time. I think b) is the better option. And if you feed it compressed items with uncompressed output it would uncompress the items as they are fed into it.



I also like your idea of compresssed items being 2x2 times the size on belts. That would also mostly solve the problem of generating icons for them. They simply are scaled up to 2x2 times the size. The size alone will tell you they are different from normal items.

Now that doesn't solve the issue with compressed items in the inventory. If compressed items are 2x2 times the size on belts then why not in inventories too? The equipment grid shows us how that works. Mixing compressed and uncompressed items could lead to fragmentation issues where an inventory has lots of free 1x1 slots but no 2x2 slots. But that just adds to the puzzle I think. Alternatively inventories could move uncompressed items out of the way to make 2x2 slots as needed.

One problem I still see is when inventory space runs out while you use up some items. Say the inventory is full and you take 10 compressed landfill into the hand. Then you place down one landfill tile. That leaves you with 9 compressed landfill and (N-1) uncompressed landfill. There is no space to put them both back into the inventory. Unless a stack of compressed landfill equals 4 stacks of uncompressed landfill. Then whatever you have in your hand can always be completely uncompressed and put back in the inventory.

Note: Deadlocks stacking has 1 stack of items == 1 stack of compressed items. You don't gain any inventory space by stacking, it just improves belt throughput and train loading times. I think that's fine. And the 1 big compressed stack == 4 uncompressed stacks would work the same way. But no reduction of the default inventory size there. My vote would be for inventories to collect items uncompressed and whenever they have 4 full stacks of something it gets replaced by a compressed stack and the inventory re-aranged to make it fit.

I actually don't fill up my inventory with lots of the same items usually. My bigger problem (with mods like Bobs, Angels, Pyadon) is that I have a few items of too many things. The much larger number of items simply fills up the inventory and not the high number of a few like in vanilla.

To be honest, I see compression as a bit too overpowered for vanilla. If I can replace the need for 4, or maybe 10 belts by just 1, it somehow unbalances the game. The incentive to move from yellow to red, and blue, or to build trains would be pushed back way further.

Koub wrote: ↑Sun Aug 02, 2020 10:05 am To be honest, I see compression as a bit too overpowered for vanilla. If I can replace the need for 4, or maybe 10 belts by just 1, it somehow unbalances the game. The incentive to move from yellow to red, and blue, or to build trains would be pushed back way further.

There is no reason compression would have to available before space science in vanilla or at all. Just like loaders the game has to support the features discussed above natively to make this work well. But activation of it can be left to mods.

mrvn wrote: ↑Sun Aug 02, 2020 10:59 am

Koub wrote: ↑Sun Aug 02, 2020 10:05 am To be honest, I see compression as a bit too overpowered for vanilla. If I can replace the need for 4, or maybe 10 belts by just 1, it somehow unbalances the game. The incentive to move from yellow to red, and blue, or to build trains would be pushed back way further.

There is no reason compression would have to available before space science in vanilla or at all. Just like loaders the game has to support the features discussed above natively to make this work well. But activation of it can be left to mods.

Oh I would be 100% fine with that then

@mrvn: For fluid 'compression', outside of storage tanks, I just rationalize it as high-pressure piping as a way to get 'round pipe throughput limits. It doesn't make a great deal of sense that you can somehow magically cram ten times as much water into a tank, no.

Then again, this is a game where you can carry an entire rail yard in a hip pocket. Maybe I'm overthinking it :v

AmericanPatriot wrote: ↑Sat Aug 01, 2020 5:23 pm Compression would be so over powered as to be game breaking, or would add one extra step after mining and thereafter not change the game.

same thing could be said of anything. why not listen to the people who have done entire playthroughs around compression?

Koub wrote: ↑Sun Aug 02, 2020 10:05 am To be honest, I see compression as a bit too overpowered for vanilla. If I can replace the need for 4, or maybe 10 belts by just 1, it somehow unbalances the game. The incentive to move from yellow to red, and blue, or to build trains would be pushed back way further.

come and see my starter base where i'm using Deadlock stacking. we're well on our way to a big train base with blue belts and blue stacking beltboxes, even. I just automated those last night

ptx0 wrote: ↑Sun Aug 02, 2020 6:19 pm

AmericanPatriot wrote: ↑Sat Aug 01, 2020 5:23 pm Compression would be so over powered as to be game breaking, or would add one extra step after mining and thereafter not change the game.

same thing could be said of anything. why not listen to the people who have done entire playthroughs around compression?

1. Your first statement is false.
2. What are these people saying that I haven’t heard.

Wow, so much feedback!

TL;DR

Here in short form what I think needs to be changed or explained more exactly to this suggestion. This is just a short repetition of what is written below.

Assembly/Smelter/etc.
- An assembly/smelter/etc. can produce normal or compressed items by selecting a "target"-switch: "normal/compressed". Depending on that it produces a normal or compressed item.
- The assembly has doubled slots per ingredient for the normal and compressed version
- From the UI-design and to imagine it better I think the extra slots should be - like with inserters with circuit-connection - an extra window besides the current one, and it is open if these extra slots are used somehow
- It requests both item-types from the inserters
- if the target is "normal" but inserters put in compressed items, the assembly automatically expands compressed items, until enough items are in the normal slots. And vice versa.
- This extra expansion/compression needs extra time. The process is shown in the extra window I have mentioned above.
- The idea of automatically deciding, if an compressed or normal item is assembled is history.

Robots
This is part of balancing, but some ideas of what could/should be done:
- Robots cannot transport compressed items (too heavy? )
- Or can transport only one compressed item
- Or can transport only one compressed item if that ability has been researched

Belts
Some thoughts:
- It makes no sense to use four belts with compressed items to feed flying-robot-frame assemblies. It makes much more sense to use only two belts and feed it with uncompressed items.
- The bigger compressed items block the two lanes of the belts for following expanded items. That mechanics might be possible to use for some interesting mechanics.
- Only compressed items make mixed belts possible. Only compressed items make sense if we speak about factory streets.

Research of Compression
- When should compression introduced? Also part of balancing. But it seems to be obvious, that this technique has a similar potential as the robots. If it would be too easy to reach players may think they cheat.
I see this in the same category as oil research, because that's normally the time the player needs more and more and more resources. Instead of rebuilding and expanding the main bus he can reuse it, but needs to rethink everything, because the items take now two lanes.


Energy
Usage of energy is part of balancing. There are are good reasons to make this expensive, but other good reasons to make that cheap.


Long read:

sorahn wrote: ↑Sat Aug 01, 2020 4:08 pm These? https://mods.factorio.com/mod/CompressedFluids
We use those + the stacked recipes on our servers and literally stack/compress everything.

Yes I know that of course. But the target of this suggestion is, that recipe-wise there is no difference between compressed and normal items (or fluids). It should not matter, if I have a tank of compressed liquid or normal liquid, you just cannot mix both.

The only thing we can't do stacked is: Space Science, and mining stacked ore directly (but I think there's a mod for that that too)

https://mods.factorio.com/mod/deadlock-experiments ?

billbo99 wrote: ↑Sat Aug 01, 2020 4:48 pm Recipes have fixed ingredients, you would need a change to the game engine to allow a recipe to pick from multiple different ingredients.

Hm. yes... no... the point is, that it is not different from the receipe view. Yes, they are different item-types. No, if the recpipe needs iron plates, it should not matter if it takes iron plates or compressed iron plates. The difference is just, that it prefers compressed iron plates, if it should produce compressed stuff (and vice versa). I think of it so, that an assembly has now always two slots per ingredient: A normal and the compressed one. Inserters are requested for both versions and put in both, if they are available. When the assembly is assigned to produce normal items and there is no normal item available but compressed ones - it needs to uncompress them first (filling up the slots for normal items and it takes of course some extra time). And vice versa for compressed items.


The point of this is: It works a bit slower, but it removes the high complexity of handling both normal/compressed item-types. This is essential for items like inserters or belts, which are needed in both versions in large amounts. Or for complex and expensive items like rocket silo, where you want to put in partly compressed items but want to produce just some rocket silos and not a compressed items of 20 silos or so.

This ability to mix normal and compressed items is eventually an extra research "internal compressor". Maybe a module is needed to enable this per assembly/smelter/etc., but I think this is part of balancing.

And as said this internal compressor is also a good idea for the player himself, that - if turned on - it automatically tries to optimize the slots with the disadvantage, that you need to craft it.

And I added your second comment as advantage to the list of pros and cons.

AmericanPatriot wrote: ↑Sat Aug 01, 2020 5:23 pm Compression would be so over powered as to be game breaking, or would add one extra step after mining and thereafter not change the game.

Good that you remind me to the miners: I don't know yet, if it would be a good idea to enable miners to produce compressed items. I need to play that.

And I understand your argument of overpowering, but I don't think you're right. It depends a lot of balancing, if it feels overpowered or not. For example when playing with deadlock_stacks in default it is only a bit overpowered for belts and robot logistics. For trains it is not, you can load the same amount of items as with normal items.

This suggestion allows modders to find the right balance or find totally different ways of playing with compressed items.

mmmPI wrote: ↑Sat Aug 01, 2020 9:06 pm Going that path, i would want to compress the compressed-iron-ore, once my belt of compressed-iron-ore reach its thoughput limit.

I already had this idea to combine deadlock_stacks with deadlock_crating_machines and internally I added the needed recipes to crating_machines mod. So I could compress compressed items.
What should I say: It was "interesting". And not so fun. In my opinion it currently makes no sense to have "levels of compression". One level should be enough and when you look into reality it is quite similar (you can put a 2D thing into a 3D staple to "compress" it in area, but that's all).

With 5 iron ore making an "compressed-iron-ore". 5 of those would make a "box-of-compressed-iron-ore", which if you have 5 of them you could make a "container-of-boxed-compressed-iron-ore". And if you have 5 container you can make a "large-container-of-boxed-compressed-iron-ore". no ?

no

Sounds fun but given the popularity of the (simpler) fluid-wagon vs (more complicated) barreling system, i doubt this would sounds appealing to other people than already experienced players if "the container is not destroyed and you have to ship it back".

You're right, it is a completly different game. Please don't mix compressed fluids with compressing items. A compressed fluid is still a fluid (not boxed, aehm, bottled), it's more like concentrated orange juice: for the recipes the cost of compressed fluids are just reduced. So I would eventually call compressed fluids "concentrated fluids" instead.

... usage if different fluids to create an item...
which is somewhat similar and enjoyable to play with.

I understand, I already said, handling fluids - compressed or in your form as pre-item - is in my opinion a completly different subject. There is a lot of stuff that can be done to improve the handling between this world. But not in this suggestions. I want to concentrate on items only, because I think it has the most immediate gameplay-value.

... tin and copper to make "tinned-copper-wire" ... "tinned-copper-wire", or you can make "tinned-copper-wire-coil" that you can cut later into individual wire piece, but you can also use "copper-wire-coil" that you cut into "copper-wire" and "tin-plate" (in a different machine) or even "copper-sheet-coil"=>"copper-plate"=>"copper-wire"+"tin-plate"=> "tinned-copper-wire".
It differs by making the compression process not fully revertible which is also fun

Yes. Hm. But compression would just add something to it and does not remove the fun to have such recipes.

it was a good time/tedious saver, but felt this way only because others mods were making the game more complicated aside from this aspect, in a pure vanilla game, that might feel "overpowered" in the sense of smelting is where you are supposed to deal with mass raw items, and when they are transformed they become more "dense". One could avoid the logistical challenge of mass low-density-item, which i think is a defining aspect of the unmodded factorio experience. i fear it could be a bit boring if the natural solution would be to compress at all time and only use 1 single belt per material.

I don't think so. There is always the space problem and that the long range inserters grep only 2 tiles wide. And if you place four belts to produce flying-robot-frame you don't win anything. It is much more clever in that case to use expanded items, because it takes so long and you will not have any throughput problems at any time. That kind of thoughts will make it still interesting.

Another point is, that I think there is nothing really interesting to built 16 rows of belts and repeat yourself over and over and cannot really use blueprints, because the layout of the belts differs a bit every time. Yes, that is sometimes interesting to solve space problems in this scope. But that is also the reason, why I'm unsure if miners should be able to produce compressed ore.

And an aspect, that you eventually missed with this is, that a compressed item (2 lanes wide) blocks all items that comes after it. I think that could result in "interesting solutions". And the other aspect is, that with compressed material it is much, much easier to create "factory streets", where you can use mixed belts. This is possible only with compressed items. I added that to pros.

foamy wrote: ↑Sat Aug 01, 2020 10:05 pm I've been playing in a K2/SpaceX game that's running compression, and it's been a godsend for things like a chipfarm, but it honestly feels pretty cheaty as well. It becomes simply too easy to move immense amounts of material into or out of machines -- for example by having them load directly from unstack boxes -- or production modules generally.

As said: Part of balancing. I think it's ok to have this advantage, because correctly balanced, this research might be expensive and hard to claim. Keep in mind, that this suggestion includes that compressed items take more space on belts. And when I think about it: It should be also so, that robots can eventually not transport compressed items, or only one (and/or only when fully researched robot transport).

mrvn wrote: ↑Sat Aug 01, 2020 11:26 pm Didn't deadlock fix it so stacking and unsstacking wouldn't show up in the statistics?

Isn't possible AFAIK.

mrvn wrote: ↑Sun Aug 02, 2020 12:03 am I don't think compression should take much energy. Simply makes no sense for most things as you don't actually physically compress.

Well this thought was just, because nearly any compression mod I know uses much energy. Forget about it. It's part of balancing.

Now for gases compression is actually a thing and depending on the factor takes quite a bit of pressure and produces lots of heat. Expansion creates cold on the other hand. So those could reasonably take energy.
Liquids on the other hand are mostly not compressible again. Not sure how you would rationalize compressing water by a factor of say 25. Someone has to think of something for that. Some magic tech that reduces the atomic forces keeping molecules apart?
So my vote would be for compression to take none to just a little extra energy.

Well, in my opinion we do not physically compress things, but quantumphysically. It's the same technique as used for the chests. The same is valid for liquids. It's a quantumphysically compressed fluid. The distances of the atoms are reduced.

I like your idea of the game knowing about compressed items though. With that knowledge every recipe could work with compressed items in the same ratios as normal items at just multiply the time by the compression factor. There would be no need to new recipe icons. Just select the normal "iron gear wheels" recipe in an assembler and feed it compressed iron plates to get compressed iron gear wheels.

Thanks, that was the base of this suggestion.

If assembler (and furnace and miner and ...) can automatically uncompress items then I think all there should be is a switch to tell it weather the output should be compressed or not. If you feed uncompressed items into an assembler and have selected compressed output then it either a) builds N cycles before outputing a compressed item (doessn't solve the 1 recipe per tick problem) or b) takes N time the input to create one compressed item in N times the time. I think b) is the better option. And if you feed it compressed items with uncompressed output it would uncompress the items as they are fed into it.

Yea, I came to the similar conclusion above.

I also like your idea of compresssed items being 2x2 times the size on belts. That would also mostly solve the problem of generating icons for them. They simply are scaled up to 2x2 times the size. The size alone will tell you they are different from normal items.

Also thanks. I think this is an important visual link.

Now that doesn't solve the issue with compressed items in the inventory. If compressed items are 2x2 times the size on belts then why not in inventories too? The equipment grid shows us how that works. Mixing compressed and uncompressed items could lead to fragmentation issues where an inventory has lots of free 1x1 slots but no 2x2 slots. But that just adds to the puzzle I think. Alternatively inventories could move uncompressed items out of the way to make 2x2 slots as needed.

That is an interesting idea, I like the thinking behind it, but I think using 4 slots per item is a bit too much space. Maybe 2 slots?

One problem I still see is when inventory space runs out while you use up some items. Say the inventory is full and you take 10 compressed landfill into the hand. Then you place down one landfill tile. That leaves you with 9 compressed landfill and (N-1) uncompressed landfill. There is no space to put them both back into the inventory. Unless a stack of compressed landfill equals 4 stacks of uncompressed landfill. Then whatever you have in your hand can always be completely uncompressed and put back in the inventory.
Note: Deadlocks stacking has 1 stack of items == 1 stack of compressed items. You don't gain any inventory space by stacking, it just improves belt throughput and train loading times. I think that's fine. And the 1 big compressed stack == 4 uncompressed stacks would work the same way. But no reduction of the default inventory size there. My vote would be for inventories to collect items uncompressed and whenever they have 4 full stacks of something it gets replaced by a compressed stack and the inventory re-aranged to make it fit.

Hm. Never thought to that. Hm. Some thoughts:
1. I don't like to have deadlocks balancing. I understand deadlocks position and read the discussion about it, but I think it's ok to have a short transport advantage for trains. So I don't know if this 1:4 balance will be really used.
2. I come back to your above suggestion with the four slots for compressed items: What if three of that slots show the compressed item(s), and the fourth is reserved for one expanded slot? If you put some compressed items in your inventory one (!) is automatically uncompressed into that slot.
3. Bad, if the expanded item has a slot size that is lower than the slot size of the compressed item.
Would it be a good idea to forbit compressing such items?

Koub wrote: ↑Sun Aug 02, 2020 10:05 am To be honest, I see compression as a bit too overpowered for vanilla. If I can replace the need for 4, or maybe 10 belts by just 1, it somehow unbalances the game. The incentive to move from yellow to red, and blue, or to build trains would be pushed back way further.

Dunno. Till now I never observed that. O.K. maybe a little bit later than normal, but we speak here about minutes to hours. And I think that is also part of balancing.

mrvn wrote: ↑Sun Aug 02, 2020 10:59 am But activation of it can be left to mods.

I think the devs will never implement something that huge, that should be used only for mods.

ptx0 wrote: ↑Sun Aug 02, 2020 6:20 pm come and see my starter base where i'm using Deadlock stacking. we're well on our way to a big train base with blue belts and blue stacking beltboxes, even. I just automated those last night

You say that building belts without blueprints gets repetitive, but you shouldn’t be doing that. You should make trains. The challenge of increasing throughput is a fun and interesting part of the game. And by the time you are building 16 belts at a time, you should be using bots and blueprints, and have an automatic belt supply system.

Rather than argue against the negatives, give some obvious benefits: ones that outway the negatives.

I personally really hope compression doesn’t get implemented: I would be almost obligated to redesign everything around it. Though it may be “good” in that it allows much greater throughput, it is not good in that it would be fun to use.

AmericanPatriot wrote: ↑Sun Aug 02, 2020 10:10 pm You say that building belts without blueprints gets repetitive, but you shouldn’t be doing that. You should make trains. The challenge of increasing throughput is a fun and interesting part of the game. And by the time you are building 16 belts at a time, you should be using bots and blueprints, and have an automatic belt supply system.

Well, perhaps I need to explain the dimensions I normally play with: The peak here is around 310k per minute iron ore production. That would need over 400 express belts in a row to be able to smelt it.

Building that is definitely no fun!

Rather than argue against the negatives, give some obvious benefits: ones that outway the negatives.

O.K.: With (current) compression I need only around 16. I already said I think this is a bit overpowered, but I think 32 is really enough for any Factorio game. More isn't just fun.

I don't know. It's hard to explain someone the benefits of a truck, who is used to drive bicycle.

I personally really hope compression doesn’t get implemented: I would be almost obligated to redesign everything around it. Though it may be “good” in that it allows much greater throughput, it is not good in that it would be fun to use.

i dunnooooo, in real life we have this thing called technology and we advance it - one advancement is in packing techniques. you can see where i'm going with this.

the one person who's really vocally against compression here thinks it's game-breaking but wants to tell others the way the game should be played - i.e. 'by the time you get to this stage, you should be doing this, and then do that'.

yanno, the whole fun of this game is how many multitudes of options exist to get from point A to point B. you want to make train city? no one's stopping it. bots only? it's been done. no belts? you might be called brave.

the other thing is how good it feels to advance technology and see more ways to increase throughput. some people might go ahead and redesign around packing, others can choose the challenge of foregoing it. it could be a late-game addition in a post-space world. what kind of space age society doesn't know how to crate items?