[0.10.x] Logistic robots carry "maximum" isntead of "needed"

[erikem]

Logistic robots always carry the maximum amopunt they can assumign upgrades (4 in my case) instead of needed amount. The rest goes into storage chests and garbages them dramatically.
Setup description (save https://dl.dropboxusercontent.com/u/164 ... cts_02.zip):

• Isolated roboport with no active logistic robots
• Passive provider chest with 600 turrets
• Empty requester chest with filter for 1 turret
• Empty storage chest
• At least 1 logistic robot in player inventory

Steps:
1. Let the logistic robot out
2. Wait until logistic robot enters roboport

Expected:
1. Logistic robot exits roboport
2. Logistic robot picks up as many turrets as requested (1) from provider chest
3. Logistic robot places requested amount of turrets (1) into the requester chest
4. Logist robot returns to the roboport

Actual:
1. Logistic robot exits roboport
2. Logistic robot picks up as many turrets as it can (4) from provider chest
3. Logistic robot places requested amount of turrets (1) into the requester chest
4.Logistic robot places the rest of the cargo (3 turrets) into the storage chest
5. Logist robot returns to the roboport

This example may seem small but with huge automated factories it's a disaster.

Imagine a factory producing electric engines and a factory producing flying robot frames. Factories are nearby so the time needed to carry engine from provider to requester chest is minimal and mcuh smaller than time needed to craft flying robot frame.

Now the frame factory finishes production and takes 1 engine from requester chest. This triggers logistic robots to go and pick 4 engines, deposit 1 into requester chest and 3 into storage chest. This means that for 1 production cycle single set of factories produce 1 engine for usage and 3 just for fun (storage).

In general no problem occurs if the consumption of the produced goods is bigger than production. Once production provider chests are empty logistic robots would go for storage chests and empty them.

But in case when production is larger than consumtpion the stocks may grow almost unlimited while I would expect to have a direct control over them by setting storage limits on my passive provider chests.

[hoho]

Can you use inserters to move the stuff from storage to provider chests? Probably not ideal but should fix the overflowing of storage chests.

[erikem]

I actually do it but there will be always a provider chest closer to the requester for some of the goods.

Problem here is not the overflow of the storage chests (you can always palce more) but in uncotrollable growth of certain goods.

As in my previous exmple I have 2 factories for electric engines and 1 for flying robot frames. Both engines factories point to the same passive provider chest with limit of one stack = 50 engines. After a while I have 50 engines in that passive provider chests and ~400 more in my storage chests.

[sillyfly]

You can put a smart inserter with a limit on logistic system count. This way the factory won't produce if there are enough items in storage.

[erikem]

Thx, a good solution which definitely will work but uprading 200+ factories and 300+ smelters with such inserters migh take some serious amount of time. Plus each time I extend my production lines and increase my consumption needs I would have to go through all of those inserters and update their conditions.

[jeroon]

This was also discussed here. The solution there is to give the storage chest a higher priority than the provider chests. Sounds like a good solution to me, so all we need is implementation (hi kovarex )

[kovarex]

I'm just in the middle of doing that, the priority will be

• Active provider
• Storage
• Passive provider

I believe it will solve this problem, and I also believe it has more sense to do it this way.

[kovarex]

Ok, it is done for 0.10.2, so I'm moving this to resolved for next release.

[erikem]

And still having them carry as much as requested and not as much as they can would save those logistic robots a lot of extra motion.

[squisher]

And still having them carry as much as requested and not as much as they can would save those logistic robots a lot of extra motion.

I disagree. On a large scale that could drain your available logistic robot count. Suppose an assembler consumes a single item, depleting its requestor chest by one. A bot begins a delivery of a single item. While the bot is in flight, 3 more items are depleted, causing 3 more bots to initiate a delivery. By the time the first bot gets there, it could have delivered all 4 items, and you would have 3 bots free for other activity.

Note that a requestor keeps track of how many items are in transit. So when item #2 of 4 is requested, it knows there are already 4 in transit and does not send out a new request.

[erikem]

On the otehr had for slow-production items a bot carries 4, places 1 and then carries 3 to a quite distant storage chest. With the new priorities next bot will pick up 3 from distant storage chest (while passive provider is just a tile away), will carry it to requestor and bring back to a distant storage 2. Next one... And so on and so forth.

With the new priorities I will have to put storage chests in various places all over my base so that bots won't have extremely long trips.

As for the calculations. Imagine a distance between passive provider and requestor being on average 10, while between storage and requestor being 50.

Bots carryign as much as they are asked would travel (for long production items), over the period of 4 items requested:
- 4 times the distance 10 = distance 40

Bots carrying as much as they can would travel (for long production items), over the period of 4 items requested:
- 10 to get from provider to requestor + 50 to deposit to storage 3 left
- 50 to get from storage to requestor + 50 to deposit to storage 2 left
- 50 to get from storage to requestor (Lets assume that within this time factory crafted 2 and needed 2)
Total distance: 210

So for fast-consumed items bots picking up teh max are the best because of the prediction-like behaviour
For slow-consumed itmes bots picking up as much as they are requested do teh best job.

There are 2 solutions which would make bots efficient in both cases:
1. Let them "predict" need and pick based on that - a bit hard to code probably
2. Let them actually drop everything they have at requester (except player) if there's enough space even if it goes a bit above the filter

[kovarex]

Predicting is really problematic, practically impossible.
It would be strange to drop more the required for the requester.

I believe, that for high-frequency demand it works good, and for low-frequency demand, it just isn't needed so much, so it is ok.

[erikem]

I believe, that for high-frequency demand it works good, and for low-frequency demand, it just isn't needed so much, so it is ok.

As I have mentioned I ended up with over 500 electric engines while all my providers in total supported 100 maximum. Same for normal engines, speed and productivity modules 1 and 2 and lotsa other stuff which is currently clogging my storages and already wasted some resources I didn't want to invest at that time.
The demand for these items may not be that big but with large enough scale of production such clogging becomes annoying at least

It would be strange to drop more the required for the requester.

Same could be said for "trying to deliver more than required"

When we say "deliver more than required" it always mean "maximum 3 items more" (in case it needed 1 and robot delivered 4) which should not be a problem in 99.99% cases.

[ssilk]

A) if you made it so, you must made it wrong. Insert into your provider chests with a smart inserter limited by logistic network, then it won't produce so much.

B) Delivering more than required is a big problem in conjunction with the equal operator for circuit network.

[erikem]

A) Because being new to the game I expected existing limits (passive providers) to be enough
B) Agreed. Didn't think of this

And still these robots carrying too much create extreme amounts of garbage in my storage chests

[ssilk]

Hm.

To say it with my words: Your problem is, that you put in items in passive provider chests, which are then used in a requester chest and because the requester chest always needs only one, but the robots always bring 4, the rest (3) is put into a storage chest? Meanwhile the provider chests are refilled and your overall storage of that item rises and rises.

If that is so I've some questions:
- if you followed my suggestion A from above nothing is produced anymore. Is it so? If not why complain?
- why do you have so many provider chests, when you need only one to satisfy everything?
- why is your base so big, that your bots need to fly extremely long ways?

Is ask, cause I think you make some basic thing wrong.

[kovarex]

Hm.

To say it with my words: Your problem is, that you put in items in passive provider chests, which are then used in a requester chest and because the requester chest always needs only one, but the robots always bring 4, the rest (3) is put into a storage chest? Meanwhile the provider chests are refilled and your overall storage of that item rises and rises.

Not anymore in 0.10.2

[erikem]

- if you followed my suggestion A from above nothing is produced anymore. Is it so? If not why complain?

Was and probably is noob at this game. Thought that limit on providers would be enough

- why do you have so many provider chests, when you need only one to satisfy everything?

I was optimizing my base to use as little belts as possible. Even smetling is done via robots. Assembler setup in this case is: two assemblers and 3 chests in between them - 2 requesters and 1 provider and ofc inserters. On the downside this forces me to use identical recipes for both assemblers in most of the cases which is still ok for me. This way each pair of assemblers has a provider chest of it's own. I can share a save if ya wanna look at my setup

- why is your base so big, that your bots need to fly extremely long ways?

Usually they don't but storage chests can't be near each pair of assemblers and will always be closer to some of them and further from some other. As for the size of the... I've tried to cover it with roboports optimally and I have 450+ of them

Is ask, cause I think you make some basic thing wrong.

Could be. One thing I love the best about this game is an almost unlimited opportunity for learning and optimization =)

[ssilk]

Was and probably is noob at this game. Thought that limit on providers would be enough

Hm. I used this strategy once, too. But I think with 0.10.1 this is indeed not longer useable in that way. Sad. But the limits are still useful, see down.

- why do you have so many provider chests, when you need only one to satisfy everything?

I was optimizing my base to use as little belts as possible. Even smetling is done via robots. Assembler setup in this case is: two assemblers and 3 chests in between them - 2 requesters and 1 provider and ofc inserters. On the downside this forces me to use identical recipes for both assemblers in most of the cases which is still ok for me. This way each pair of assemblers has a provider chest of it's own. I can share a save if ya wanna look at my setup

One of my best bases are those, where I mix all three transports together: Belts, trains, logistic bots.

- Belts should and must be used for the basic materials; ore, plates. I use them in many parallel belts and bring them to the points in my logistic net, where it is needed. Smart Inserters put the stuff into passive provider chests. The chests have limits! There they are useful, to ensure, that every chest is filled, but not too much is stored. I could say much about other tricks, but I think this gets soon too special and we are here already off-topic.
- Trains are for the long transports, but also good for mass-transport, cause it can transport much more than belts with the same need of space. The wagon is a very useful buffer, if used without locomotive and it's usage is with the filter now - well this will be part of many experiments in my next world.
- Logistic bots are good in small areas and for the higher level items. The modules for example. Capsules. And the doozens of different items you need for building. But when you see big lines of logistic bots, flying between two points or areas, then you made something wrong: Therefore are the belts! It is sometimes a big release to even built one basic belt between those points and use the lanes to transport just a bit of the two most needed stuff between those points. The "needed rest" then can be done by the logistic bots in ease. It makes the difference between "cannot be handled" and "useful". A steady stream of needed items over distances longer than 50-100 tiles should be handled as far as possible by belts or trains!

- why is your base so big, that your bots need to fly extremely long ways?

Usually they don't but storage chests can't be near each pair of assemblers and will always be closer to some of them and further from some other. As for the size of the... I've tried to cover it with roboports optimally and I have 450+ of them

Well. I measured this a bit and what I say now is not sure:
For the logistics (not for construction) I recommend a maximum size of 200x200 or maybe 300x300 tiles. And the formula for the number of bots is then just the square-root of the area multiplied by 2 plus 100.
So with a size of 300 tiles^2 the maximum number of bots should be about 700. This makes sure, that you don't get any big bottleneck.
The number of roboports is then about number of bots divided by 50-70. So there should be a minimum of 10 roboports !

And I repeat: This is for the central area for the logistic bots only, the construction bots are a completley different category! And of course it doesn't make sense to have 700 bots, if only 100 are used. But if you have yet 500 and 450 are used, well, that can make sense to add some. But is is quite a bit act of balancing, cause when you come near to the limits, the logistic bots begin to behave chaotic. That's not a fault of the algorithms, it's just very natural.

Is ask, cause I think you make some basic thing wrong.

Could be. One thing I love the best about this game is an almost unlimited opportunity for learning and optimization =)

[kovarex]

Another option is to have an checkbox "Exact count" in the requester panel.
It would be unchecked by default, and it would allow bots to carry little bit more in that case.