Logistic Network Needs to be smarter

[Frightning]

Qon wrote:
No, wrong. If your base is designed correctly with bot behaviour in mind, then any size is possible. Separating your logistics networks is just one way to solve the problem of rising complexity when you have more connected production areas.

For optimum logistic performance, you need to understand the workings, strengths and weaknesses of bots. No magical rules, just knowledge. If you are fine with non-optimal performance then many tiny networks is probably a good enough solution in many cases.

When delivering stuff to storage chests, bots can be really stupid. All bots fly to one box, they realize that the box is full only when arriving. Then they decide what box is the second best option to delivery to. So all bot continue flying to another (random) chest that could be very far away. That can mess up the complete system. What is your solution for this? How can you design in order to avoid this mess?

This is why I use only small networks, e.g. close to a train station for train loading/unload, storage, sorting and transfer to/from belts. Otherwise, if your train delivers 20 k iron plates and the bots decide that the chest 1000 tiles away is the one, just to realize that it's full only when they arrive to fly to the next one that will also be full when they arrive. It's really aweful to abserve this crazy ballet when there are 20 empty boxes next door to the station. Plus the fact that the iron plates most like will also be used close the station. So the flying caravan all comes back.

PS: I like the bot how they are. You need to think and they are not long distance. Because I also like trains...
PPS: I'm just curious how Qon solves this problem intelligently.

And here you've made the cardinal sin with logistics robots: having the same item delivered from the same place to two different, distance places. Never design a logistics network where any high-volume item is to be moved over large distances in 1 trip by bots. In my kilobase, everything is moved by bots except ores from mines the base itself, that base processes about 8k ore atm, and mostly makes high-tier items, mostly modules and rocket parts from them, yet it uses only about 1000-1500 of the 3k+ bots the network has to do all that moving. The reason it's so efficient is because the entire base layout is extremely compact, thereby minimizing average move distance. Moveover, I even arranged the production rows for the high volume items so that they would be nearest to the items they use and near to the processes they feed, further minimizing average travel distance. (Take a look: viewtopic.php?f=204&p=217216)

[Bauer]

I unload various goods into the same active provides chests. The unloading of the train stopps when a certain amount in present in the logistic network + the stuff that is in the provider chests. Hence, I need to the trains to unload quickly, because the next trains needs to come with goods that might be needed more urgently. Therefor, the chest need to get emptied quickly, which is why I'm using active provider chests. I also need some buffer because the train travelling time is fluctuating due to jams, construction works, safe player crossings, design failures leading to grid locks *sigh*, etc.

Since the loading/unloading station is a seperate network, there are no long distances and bot time is no big issue. It would my life much easier if the bots would bring the stuff to the closest storage chest and not to the oldest (empty) one.

In fact my biggest problem is that I very carefully have to handle my automatic trash. Because I do not want it to end up in the storage chests at the train stations...

If you are using the station for one resource steady state for the furthest boxes would be empty (not enough raw recourse bandwidth) or full (too much raw resource bandwidth. Assuming worst case scenario of unloading alignment, assuming you have the bandwidth to support production and assuming it takes 4 seconds to swap trains you would have enough buffer to support 13,500 items/second/station which I believe is above the theoretical maximum of trains anyways. I had not considered multiple types of trains coming in. In that case you are probably correct with active providers. However have you considered storing your resources at their destination rather then a storage chest? So for example each green circuit machine should request 4500 iron and each copper wire machine should request 4500 copper? Yes it will take a while to reach SS but you can very easily see how many machines your bandwidth can support. Eventually your station will clog with one resource being delivered too often unless deliveries are controlled by a circuit network.

Edit oh I see you release the train based off a circuit condition

Edit 2: how many stack inserters does it take to fill a blue belt 4 or 6? I use yellow for everything

And: I have no train stacker (only 1 waiting position). Maybe this is a mayor mistake (works so far, because I can empty the trains quickly enough). Close to the stations are small factories producing something, e.g. red circuits. In most cases, belt logistics are better to control, more cost effective, and better looking than bots. I typically buffer 1.000-10.000 times the educts needed for the small factoriy in the train station and unload onto blue belts from there. Thus, I only have short distances for the bots and the train unloading is fast and compact.

Re Edit 2: It takes 3 fully upgraded stack inserters to almost fill a blue belt. In the example on the image I compress 12 inserters on 6 belts to 4 belts. Sounds a little crazy... One of the problems with belt solutions is that it is not easy to find an elegant solution to connect 12 full belts of iron plates to 40 assemblers for green circuits that all need to be close to beacons. I don't have a perfect solution ... but ... since I really do not want to build something like a 12 to 17 balancer (numbers are arbitraray) I tend to deliver the educts on undersaturated belts. "undersatured" in the sense that there is enough stuff delivered to the machines but less then 40/s.

[Bauer]

Qon wrote:
No, wrong. If your base is designed correctly with bot behaviour in mind, then any size is possible. Separating your logistics networks is just one way to solve the problem of rising complexity when you have more connected production areas.

For optimum logistic performance, you need to understand the workings, strengths and weaknesses of bots. No magical rules, just knowledge. If you are fine with non-optimal performance then many tiny networks is probably a good enough solution in many cases.

When delivering stuff to storage chests, bots can be really stupid. All bots fly to one box, they realize that the box is full only when arriving. Then they decide what box is the second best option to delivery to. So all bot continue flying to another (random) chest that could be very far away. That can mess up the complete system. What is your solution for this? How can you design in order to avoid this mess?

This is why I use only small networks, e.g. close to a train station for train loading/unload, storage, sorting and transfer to/from belts. Otherwise, if your train delivers 20 k iron plates and the bots decide that the chest 1000 tiles away is the one, just to realize that it's full only when they arrive to fly to the next one that will also be full when they arrive. It's really aweful to abserve this crazy ballet when there are 20 empty boxes next door to the station. Plus the fact that the iron plates most like will also be used close the station. So the flying caravan all comes back.

PS: I like the bot how they are. You need to think and they are not long distance. Because I also like trains...
PPS: I'm just curious how Qon solves this problem intelligently.

And here you've made the cardinal sin with logistics robots: having the same item delivered from the same place to two different, distance places. Never design a logistics network where any high-volume item is to be moved over large distances in 1 trip by bots. In my kilobase, everything is moved by bots except ores from mines the base itself, that base processes about 8k ore atm, and mostly makes high-tier items, mostly modules and rocket parts from them, yet it uses only about 1000-1500 of the 3k+ bots the network has to do all that moving. The reason it's so efficient is because the entire base layout is extremely compact, thereby minimizing average move distance. Moveover, I even arranged the production rows for the high volume items so that they would be nearest to the items they use and near to the processes they feed, further minimizing average travel distance. (Take a look: viewtopic.php?f=204&p=217216)

You are right. One must avoid large travel distances. I do so by seperating the networks, accepting the disadvantages which is what this thread is all about. For a small base you can squeeze everything into one small sized logistics network. However, I find it exceptionally difficult to use green circuits only in a small distance from the production unit.

Your images are not very easy to read, but I am really surprised how compact your base is for the 8k ore/sec. I process about 4k ore/sec and I need much more space.

[Nich]

Transitioning from belts to bots takes a different mindset IMO. Rather then having a green circuit area and a red circuit area you have 1 factory. Then you try to have all material flows in 1 direction. In my bot based factory the final product is a rocket. So Oil products flow in from the west, copper from the top and Iron from the bottom. Green circuits are mixed in with red which are dotted with blue, RGCUs, Light weight structures, and rocket fuel in the middle. This all then moves to the North middle for the rocket. If I want more rocket production I just copy paste the entire thing. So far the hardest challenge is feeding the beast. It has taken about 12 mining outpost producing about 250 iron and copper/s

Working on setting up for a second factory. I need to clear about 10 square km to secure enough new ore patches. Finally found my first decent patch with 8 mil iron ore.

[realm174]

Logistic example.gif

I think you are mistaken (or my 0.15 is broken).

All bots fly to one chest, after xx arrivals the chest is full and all bots fly to the next chest. And it is by no means the closest one.

Sorry, I'm late to the party, but from observations only, what I think happens in this case (I see that all the time in my base when I rearrange things and need to empty chests from one place and put the stuff into other chests in another area) is that say you have 4000 items being pulled from one chest, go to into another one where there's only 2000 spots available. Individually, the bots don't know what the total amount of stuff to be moved is. So the one bot picks up x items (depending on cargo size) and look at the logical destination (see other messages in this thread on how this is determined). Bot sees there is plenty of room in that destination chest, so off it goes.. Take that scenario, multiply it by whatever number of bots you have doing that task, each bot thinks there's room at the destination, so each bot goes. Halfway through the process, the destination chest is full, so the bot sees that on arrival and picks a different destination. Is your expectation that the bot would be "notified" while it's travelling that the destination chest is full? And if so, how frequently should the bots check for space at destination while they're travelling? That's what I was hoping at one point, but then started thinking about performance. I typically have 40k-60k bots flying at any given time. If you were to add a "check for space while flying" option, even if only once per second, that would definitely melt my computer.