TL;DRThe (hidden) loader would be the missing device to implement boxing.
There is the (very old) idea of boxing: viewtopic.php?f=80&t=19343
I recommend to read the first part of that article to follow the rest here.
I played a long time around with some mods, that implemented boxing, and I think this is something, that has great potential for Factorio to bring it on "the next level". I think factor 50 more throughput at the same CPU utilization is possible. Alone with that you can see the potential.
The problem is: there is no way to say "this is the best way to implement boxing". There is still a reason, that there where many mods, that implemented boxing in one or the other way. And I think this is good, that is the right way.
Now comes the loader into game. The loader is a hidden device, that was not finished to implemented. Instead the stack-inserters have been implemented. See https://www.factorio.com/blog/post/fff-128 and later.
Here an picture from there:
My new idea is now: The loader is the missing device fox boxing/compressing or unboxing/decompressing all the masses of goods.
I described the idea at first here: viewtopic.php?f=6&t=44847&p=264722&hili ... er#p264722
but I explain it here more in detail.
We need two new devices that I call now "compressor" and "decompressor". The look about so:
The compressor has a connected loader (as seen above in the picture 1-2 tiles) on the left down side and the compressor itself (I think to 2x2 tiles).
Code: Select all
The compressor-device: ___ | | >>>|___| ^ Loader The DE-compressor-device: ___ <<<| | |___|>>> ^ ^ Unloaders
The de-compressor has in this case TWO unloaders, one on the left-up, the other on the right-down side.
Note, that the loader can be used only in conjunction with compressor/decompressor and belts. So there is either a belt, then the loader, then the compressor or vice versa. Or for liquids a pipe, then the loader, then the compressor and vice versa.
What I mean is: All other usages of loaders will be removed, to reduce the complexity of this new compressor device.
The loaders are also "free" for the compressors: You build the compressor and then add the loader(s). That works a bit like with the rail-signal: The game shows the places where you can built a loader. But the loaders have no extra cost and are able to handle express belts or pipes with full throughput. Think of it like a big vacuum cleaner.
That all is of course more or less modable: Size of compressor, number of loaders, length/size of loader and so on...
WHat it does?
Simple rule: The loader-part of the compressor is thought for the mass of items , what should be compressed (or has been decrompressed).
Other input (by inserter or player default) is the box-item; for output the unboxed box-item. Sounds more difficult as it is. See this:
In this case we have 3 loaders, which enables us in the best case to compress 4800 items per minute. So even for bigger mining sites it is possible to have only one loader.
Code: Select all
Compressor: ___ >>>| |<<< >>>|___|O==== I ====== >>> BULK-INPUT (delivered by the loaders) I OPTIONAL BOX-ITEM INPUT (inserter taking box-item from belt for example) O OUTPUT (also an inserter, that puts the boxed item on belt)
It looks similar for the decompressor:
Code: Select all
___ <<<| | ===I|___|O=== I INPUT (inserter takes a compressed item from belt) <<< BULK OUTPUT O OPTIONAL BOX-ITEM OUTPUT
- There is a clear distinction of what is bulk- and what is box-item. And with that the correct recipes are quite clear and simple to calculate.
- You don't need to set filter inserters to output the right items to the right belts.
- With two and more bulk-outputs the bulk is halfed, tripled.... for each output. That enables also an "elegant way" to have a factor of 1/3 for a belt.
I refer for decompressor/compressor now always as compressor only.
Each type of compressor defines a list recipes. (That is also one of the reasons why this needs to be a new device)
A player cannot set a receipe on a compressor (like with furnaces). But there can be many different types of compressors.
Each type of compressor can have it's own list of recipes defined: You can define a list of items, that can be handled by one type of (de-)compressor and the game then knows, how to handle the rest. So it is a bit working like a furnace.
An example of what compressor-types a game might provide:
- Barreller: Handles all kinds of fluids, needs as "box"-item a barrel and the loader sucks from a pipe. Thinkable to have several loaders as input, each with a different liquid.
- Resources: This packages all kinds of raw-resources into bigger ones with a factor of 1:10. No box-item needed for that, the compressor just box it with spit.
- Advanced: This is what the boxing mod provides for example: It boxes with the size of the stacks and needs a box.
Uncompressing must not need similar to boxing. There needs not to be a perfect symmetry between boxing and unboxing. So the box-item can vansh for example or the output is reduced.
Due to several thought - that I would not like to go into detail here - there should be two stacks: One for the bulk-item and one optional (!) stack for the box-items. The size of the bulk-stack is by default twice the number of the boxed bulk-item size.
This means the compressor can compress only one item per time. Of course you can have different items/fluids on the loaders.
Maybe we need also filters for the loaders (input/output), which can offer a very interesting sub-game.
Preview: Production Streets
Now think, we enable, that the compressor can handle more than one item per time. Many difficulties to solve, not part of this suggestion.
What you have then are boxes, that contain different items. Pre-filled in the right ratio. Simple example: A box can be filled with 200 iron and 300 copper wire. And now the clou: A circuit assembly can pick up this box directly from belt and produce 200 circuits plus one box. Maybe that is also much faster?