Factorio Forums

A try to make a better definition of this idea.

Reasons to make containers: Faster handling of items. Storing of items. Transporting/logistics. Will make everything faster and should be easy to understand/handle, cause basically nothing changes. Will enable to scale the game to an incredible throughput, which is eventually needed to achieve the game-target. Makes trains more useful.

Basic idea about containers
Containers are slots! A chest has slots and one slot is like a container. (Means, that a container can contain a number of items of one type)
A container has like a slot no intelligence. You cannot control which item is filled into a container/slot. The first item filled in determines all items (it's like a slot). This can only be controlled by filling it.

Graphical representation
Imagine a container like a barel-like form made of a steel plate. On the outside of it the containing item is printed and about how full it is (100%, 50%, 10% or empty). Its eventually bigger than normal items (see next).

Size on belts
A container is maybe "bigger" than a normal item and takes both sides of a belt!? (just an idea...) I think this is also needed to distinct a container from an item and to see about how much is inside it, otherwise it would be too small.

Handling
A container can be handled like a normal item, when taking it up. It takes one slot and shows which item/how many are inside.
When you need to open a container (e. g. you craft something or take one item out of it) the container-hull is destroyed and the items in the container remains as slot-items. The game-logic tries to avoid destroying containers as long as possible and tries to use single items first.

Inserters
A container can be handled by the inserters like a normal item. (I think the idea of having only special inserters doesn't bring the game forward). Filter inserters works also with containers as known.

Auto-repacking containers
When in a chest or in the inventory the last slot is used an automated refilling tries to fill non-empty containers with the same item into one to make slots free.

Filling stations (creating a container and filling it)
A filling station works a bit like an assembly-line: Its about the same size (or smaller, 2x2). It takes some items to build a container (one steel plate?) and has an input-door for the stuff, that is filled into the new container (with a cone?). The input doors can be imagined like in the factory-idea ( https://forums.factorio.com/forum/vie ... t=20#p7318 ), the input.door is, where you put a belt into it, the output-door, where you place a belt out of it. When the container is full, or after some time (like the train-station) or when filled for a minimum percent, the filled (or empty or not fully filled) container comes out of the output-door. I think it is important, that the filling doesn't take inserters, because this needs too much energy/time and this will destroy the advantage of containers.

Inside of the filling station
It is pure purpose, that it will make problems to fill a mixture of items on the belt into containers (because the filler has a internal buffer slot, the second non-matching item blocks the rest!).
Assume we have a belt full of iron-ore and we will fill it into containers. The iron ore is stored into the buffer until the container is built. When it is built, the buffered iron-ore falls into the container and the rest is filled from the belt. Now there is a single item of copper ore on the belt, because we built a mine to near to the copper-field. The copper will go into the buffer, also other copper-items, while the iron-ore runs through. When the iron-ore-container is full it is put on the output-belt and the next container is filled with copper-ore, because it is in the buffer. So this container is not very full, because we have said that it is packed after 30 seconds. But meanwhile, the iron-ore in the buffer was refilled. This works well unless a third item (cole) is on the belt. This blocks everything because there is no buffer left for it.

You can craft a container yourself (every empty container takes one slot) and put stuff into it until it is filled.

Put the things out of the container,
Because it is just pure thin iron-plate a container is not reuseable. Taking out an item destroys the container hull and the items remain in the slot. Of course the container must be inside a slot before. If not, it behaves like a box, which is picked up if you inventory is full.

In chests
A inserter which outputs things from a chest tries first to output lose items. If there are no left it opens the containers (destroys them) by using the lower filled containers first.

In assemblies
If an inserter puts a container into an assembly, the slot must be free before. This means, that a mixture of lose items and containers will only eventually work, because the slot must be completely free before inserting a container in it. (The assemblies need to have as many input-slots as items needed.)
This means also: Inserting from a chest to a assembly doesn't destroy the container, the container is just put into the assembly (again: only possible, when the slot is empty before).

An alternative way
would be to have unpack-stations, which works similar to the filling-stations. But I don't like this idea, because it is complicated enough; fill and unpacking has also it pitfalls, e. g. a container cannot be unpacked, if there is no empty slot, so I think this is complicated enough.

Logistic robots & containers
Logistic robots can carry a whole container. Maybe a research is needed for that.This enables to have much less logistic-robots than now and with them the container-idea makes much more sense, because todays logistics is nearly impossible without containers.

Priorities
The logistic robots try to transport containers first, even if the way is a longer (no idea how much? about double as long?). With this mechanic we try to force the player to use either containers or lose items, because inserters try to use loose items first.

Containers and assemblies
This is not ready thought to the end: When you have logistic-robots in this stage and your factory throughput is high enough to fill a container within seconds (>200 basic-items per minute!) you can research that logistic robots can put a hole container on an assembly-station (no inserter needed anymore to put the container into the assembly). This means, that you don't need input-inserters, input belts etc. anymore. But you will need output inserters/belts of course. This should speed the game extremely up but keeps it interesting and makes it possible to introduce a LOTS of new items.

Container yard
A container yard can imagined like a "hall of (provider)-chests". It is therefore of course much bigger then a chest (4x4 to 7x7?).
Because you cannot insert single items, a input-container-crane takes containers in it when you move a container to the "input-area".
I think there should be no filter. Every container is put by the crane into it.

Like a provider chest
Because the container storage works similar to a provider chest, logistic robots can put and take containers from here! (The crane is only to connect filling stations directly and to get over the time, when you haven't researched logistic robots).

Provider chest vs. container storage place
This is perhaps another topic: the provider chest are currently not very useful, because you don't have any control about what should be stored inside. I think it should be removed! Instead only the container yard can be used and it should work similar to the storage-house in Siedler3, where you can just say, which items (and here also how many slots of them) should be stored inside. This makes a provider chest not a requester chest! Only currently unused containers are stored here and this behaviour depends also only the logistic robots, not the input-crane!

Logistic networks
works similar to everything else. Cable it.

Wagons
Just like in a chest. A single inserter can fill a wagon within seconds with containers. Makes much sense and gives Locomotives much, much more sense, because you don't need a buffer-chest in front of the wagon anymore.

Railway station and other transports
I can imagine also that a "railway station" is nothing else than a combined filling station/container yard. When thinking further, this is also the only way to transport items over water with a ship (harbor) or airplane.

Destruction
When destroyed a container behaves like a chest.

Research/Balance/How early in the game?
I would say, containers/filling-stations should be available before logistic robots. The container yard should be available at the same time with the logistic robots, but must be researched extra.

Now I have forgotten the containers in the early game.
Containers can - as described - crafted by yourself. This should be possible from beginning. To make a chest, which has only one slot remaining (so that not too much items are stored) you can build containers for every slot and fill it with one item each (e. g. wood). The remaining slot is filled. The auto-repacking doesn't work in this case, because you filled the slots with empty containers before filling them with wood.

But I admit, that a much smaller chest (2 slots only) would be sometimes useful in the early game...

You are basically describing the current railway system if we scaled down the tracks to the size of belts, and the wagons to the size of chests.

No.

Railways have many disadvantages. Only one of it is the immense afford to fill wagons, which can be made much easier with containers.

Perhaps differently explained: Containers are used to handle a big amount of things as one.

In reality a Chinese manufacturer fills it with jeans (thousands of jeans!), puts it on a ship and brings it to Europe. Here the container is put on the train and transported to a storage. The container is opened and the jeans will be split into small parts for every shop.

Now imagine, what would happen, if you wanted to make that jeans by jeans? Item by item?

Understood?

In Factorio it is completely the same thing! it makes handling of items much faster and much easier. It enables the transport over long distances. It is nothing else as a basic necessity.


And while I'm thinking about it: It should be not possible to put a container on fast- or express-belts for some reasons.

I know what containers are.
And you could do the same things with wagons if there was a way to efficiently switch wagons from and to trains.

Sorry, I didn't want to blame you. And to your comparison: Hmmmm. No.

A wagon needs to be filled by inserters, can run only on rails, cannot be put into a chest or assembly, cannot be carried by logistic robots (even if this is not very logical, because you can put a wagon in a container and a container can be carried ), is very big, has many slots, cannot lay on ground like an item or roll filled on a belt...
And so on, the differences are ... big. I see a container as a universal transport case and a game, which is about infrastructure should have it.

Lets see from another point: In other built-up games you need one wood and one stone to build a house. But what else as a container could "a stone" and "a wood" be?
It's a placeholder. It could be used as currency between players...



But you made me think about a train production line. Some controller at the end which tells a completed train, what route he should take. Hm. A shunt yard? It would be a cool idea...

Ah, OK. I didn't read that stuff carefully enough.

That idea is even more useless.
If the filling station is very small, it will be pretty much overpowered. And it won't fit into the game, because it will be the only building that doesn't need inserters.

If the filling station is large, it will only be a way to powerup the logistics bots on long range flights, and make railroads even more useless.

tonberrytoby wrote:If the filling station is very small, it will be pretty much overpowered. And it won't fit into the game, because it will be the only building that doesn't need inserters.

Miners don't need inserters. And, well, the size of the filler is just because I thought it should be bigger than a chest. It's no problem to have it much bigger. And it needs an inserter for the iron-plates you need to make a container.
And please read it: inserting with inserters takes much energy. And we talk about significant dimensions of energy...

If the filling station is large, it will only be a way to powerup the logistics bots on long range flights, and make railroads even more useless.

No. It makes it more worth, because robots will never be nearly as fast as trains. Lets see it like this: every item, which is transported cannot be used for production. So it is a must to keep the number of items you transport as low as possible. Simple calculation: 100 logistic bots transport about 12800 iron plates in containers in double the time (much slower) then 4 trains with some wagons. not to talk about the resources needed for the robots... This means you have about 64000 iron plates more for production. This is a big reason to use trains instead of logistic robots, because you will be on long tracks a way faster with them.

... Eventually it's too mean to let LR's prefer containers... must rethink this...

I have plans for something similar for my mod, is an warehouse, made with belts, inserters and bricks, where you can insert one type of item, and there are allways 5 items of that type in it.

I would like to add, that it would be very practical, if a container can be "pre-labeled".
Currently with the first item filled into a container, the container will be labeled and then it cannot include any other item. Pre-labeling anticipates this to the production of the container.

This influences the filling-station: The filling station has an option to pre-label the produced container. You don't need to fill it, if you say that filling with 0% in 0 secs are fine it will be outputed imediatelly.
And items, which are in the buffer can be removed by an inserter out of the filler.

The reasons for that are
- create prelabeled containers with unused item-type. Fetch them and put them into a chest. The containers tamp the stacks, which cannot be filled with anything else. This is eventually much easier, than making smart inserters, which fills a chest up to xxx products.
- sorting materials fast. Materials, which doesn't fetch into a container can be easier sorted out. Therefore you can put items out of the buffer.


[I think about something which gives every container a unique number and you can say "container X should be brought to container station Y, because they lack item Z". This is only possible while labeling it!

The containers idea is quite interesting. We discussed it a bit with kovarex couple of evenings ago. We actually thought of a much simpler version than you propose. Basically there would be a Packager and Unpackager entity. They would both be directly connected to the transport belts. The inserters themselves would not operate with the containers - just putting items into the packager and taking them from the unpackager. This would allow bigger throughput only through the belts (not trains / logistic robots).

Thats good to hear.

This type of setup was my first thought when I begun thinking about this and then I tried to integrate the locomotives with it. But maybe you find a better idea to transport the containers with locomotives... I found, this is needed, but you sit on the "source"

Well I was thinking of something similar, but different at the same time
Gimme some time to find out if my idea is worth it before posting it

Nirahiel wrote:something similar, but different at the same time
Gimme some time to find out if my idea is worth it before posting it

Welcome in my world.

Edit: ignore the first page. Currently the description from splwnd makes much more sense. Currently a quick implementation would be to have special inserters, that greps into a chest and outputs a whole stack onto belt. Or from belt into assembly. Maybe half stacksize would be good, because it doesn't make sense for items,which have stacksize < 4.

Stumbled over this and after re-reading I realized that this is implemented as loaders. See especially splwnd’s post.
Moved to implemented