Minimum and Maximum setting for requester chests

[Yinan]

I have noticed that my logistic robots have to go to nearly every requester chest after they have brought and item to it, because the items are being used in production.

This creates a huge load in the robots logistics network, as they have to go over and over again to those places in short succession.

It would be nice if you could request a "minimum" and "maximum" setting for the requests.

Suggested behaviour:
When he amount in the chest is lower than ne minimum, fill the chest up like usual.
If the amount in the chest is at or higher than the maximum, ignore that request until the amount is under the minimum.

That way a big load is taken of the logistics network as the logistics robots are free to do other stuff when requester chests are filled way above the minimum (depending on maximum setting).

Example
Previous behaviour: A requester chest is set to request 200 Copper plates, because the nearby assembler wants to make copper cables. The copper plates are removed and immediately a logistic robot tries to bring in new copper.
New behaviour: A requester chest is set to request a minimum of 200 Copper plates and a maximum of 400 Copper plates, because of a nearby addembler. The logistic robots will fill it to 400 and then ignore that request until it is below 200. As soon as it gets below 200, several logisitc robots will swarm in to fill it to 400 again and then ignore it again for the time being.


I hope something like that hasn't been suggested before, but I couldn't find anything (or my search-fu is not yet good enough for this board ).

[ssilk]

Well it was already requested, but I also didn't find it.

The question there was: Why? I do not really understand, what's the advantage if this... it makes no sense, cause the needed number of bot-movements is about the same.

[Yinan]

It may be the same over all, but it's not the same all the time.
You will have some peaks were the bots will have to fill up some chest, and then some other peaks where other chests needs to be filled.

And if you over produce, you can alsop have a period of idling with that when now the bots only move when another chest is under the minimum.

I gave an example of that above.
Instead of that there always have to be some bots that need to look for the copper plates, I instead can have a lot of them move the plates and then forget the chest for some time, having them free for some other tasks.

For me it feels like nearly everthing is "stuttering" because the bots aren't able to keep up with all tasks at the same time.
With this addition you would have some parts working fluently (and depending on your settings for quite some time) while others nearly stop. And then the next parts will work fluently, and then the next etc., because the bots can be (depending on the settings you make) free for a bigger task.

It's basically making the bots work in chunks instead of working on everything all the time.

[ssilk]

Can I ask you, of which size of network/how many bots in that network we're speaking?
It sound to me, as if you have 20 bots for 10 chests or so cause that explains this suggestion.

[Yinan]

Well I'm currently at around 500 bots with... to many chests to count ^ ^ (is there some page of statistics that shows me how many chests I have in my logistics network?)

But at every stage of my current map I thought that this would be a handy feature to have.

[ske]

I don't think this change would improve the overall throughput of the network.

When a chest requests 1 item, the bots bring as many items as they can carry. So if you request 100 items, you sometimes end up with 104 items in the chest.

Having the hysteresis between min/max levels would not generally mean shorter paths for the robots or more items being transported. So I don't think that it would improve things overall.

If your robots cannot keep up with the network demands, maybe you should add more robots or replace some long routes with belts.

[ssilk]

I see it the same way as ske.

There is one type of usage for the logistic bots, where behavior of "turning only on when needed" as above will bring something for the throughput.

The usage type is, when you have suddenly many requests and then a pause. I think this is eventually what Yinan means, but the requirements are very hard limited:
- All bots have nothing to do (=wait in the roboports), until there is a big peak of requesting items)
- There need to be enough bots available to fulfill the request in a time, that is equivalent to their maximum travel-distance (around 300 tiles for a bot or so...)
- So logically the chests need to have really short distance between each other.
- There should be no other requests during that time.

A typical usage case for that is, if you have a train-unload-station: Train comes in, is unloaded into active provider chests and the bots bring the items either to storage chests or provider chests, which are really near (not more than - hm - 100 tiles away).

The point is: Because the bots are all fresh charged and can bring all items within the time that is needed to recharge to fly to the target boxes and back to the roboports, this is extremely efficient usage. It takes some time until the next train comes in/is unloaded and this time is taken to recharge the bots.
The system is under optimal load, because the bots are recharged, when not needed.

AFAIK that is the only case, where some kind of "event driven bots" makes sense. Every other case is not worth to optimize.

IMHO this is eventually possible with 0.13 or already possible as a mod.

[roy7]

For me it feels like nearly everthing is "stuttering" because the bots aren't able to keep up with all tasks at the same time.

The only real solution is just adding more bots. If the request chest is running dry too fast based on the amount you are pulling out for production, increase the size of the request. That will get more bots "in the air" carrying the material at the same time. It's just a matter of setting it high enough, and then you can feed production non stop.

One advanced trick some people do with bots is try to balance your factory so that a lot of bots need to go in both directions, so they can do things on the 'return trip' instead of having long distances to go without carrying anything. Also be sure you have extra roboports to aid recharge times in areas of high activity.

[bobingabout]

As it is now, a bot will carry 4 items in a stack of said item (assuming the carrying storage it at level 3), regardless of if the chest wants 1 item or 10. if more than 4 is required, either more trips or more bots are sent to do the work. the chest is then over-filled until the desired amount is reached.

As Ssilk pointed out, if you change the behaviour to as suggested, the number of trips will not change, just the order in which they are carried out... which isn't necessarily a bad thing, a new large request on one chest can stall your robots for some time.

However, I think a better suggestion would be better bot job assignments, rather than the suggested request.

[ssilk]

AFAIK exactly this is planned (it's some times mentioned by the devs, so we can hope for it) and I move this now to won't implement.

[0xE1]

As someone with a bit of Inventory Management background, I need to say that Min/Max does improve efficiency in real world.
In Factorio it should have affect too, it of course depends on how bots are utilized, but with min/max you have ability to make optimizations.
Expected result:
In areas with moderate resources usage, bots will be called less often and thus utilized more efficiently if requested amount is less then max stack size.
And as stack size gets bigger, so will rise efficiency as bots would not be carrying less then stack size all the time, but rather supply to maximum level once and be utilized for other deliveries until min level is reached.

[ssilk]

As someone with a bit of Inventory Management background, I need to say that Min/Max does improve efficiency in real world.
In Factorio it should have affect too, it of course depends on how bots are utilized, but with min/max you have ability to make optimizations.
Expected result:
In areas with moderate resources usage, bots will be called less often and thus utilized more efficiently if requested amount is less then max stack size.
And as stack size gets bigger, so will rise efficiency as bots would not be carrying less then stack size all the time, but rather supply to maximum level once and be utilized for other deliveries until min level is reached.

Well, that could be awaited... but I would wonder, if that has any noticeable gameplay-effect. Remember: The bots try to load the full stacksize. And in case of a lack of one item you surely want them to move the items as fast as possible.

[JasonC]

AFAIK exactly this is planned (it's some times mentioned by the devs, so we can hope for it) and I move this now to won't implement.

Are you sure it's planned? Can it be moved back out of "outdated / not implemented" until it happens? Actually if what you say is true it should be moved to "ready for implementation".

I'd like this feature too, although not for the original reason described. It'd really help control the ratios of items on a train car that has a mix of items in it, for reasons that are off-topic to explain here. But it's definitely a feature I want. I was able to emulate this behavior with a circuit network although my current solution adds a lot of complexity (the simplest hysteresis controller I could come up with currently uses 4 comparators, 3 smart chests, 2 fast inserters, 3 smart inserters, a wire pole, 2 green networks and a red network, and that's per item being controlled).

[ssilk]

AFAIK exactly this is planned (it's some times mentioned by the devs, so we can hope for it) and I move this now to won't implement.

Are you sure it's planned? Can it be moved back out of "outdated / not implemented" until it happens? Actually if what you say is true it should be moved to "ready for implementation".

I'd like this feature too, although not for the original reason described. It'd really help control the ratios of items on a train car that has a mix of items in it, for reasons that are off-topic to explain here. But it's definitely a feature I want. I was able to emulate this behavior with a circuit network although my current solution adds a lot of complexity (the simplest hysteresis controller I could come up with currently uses 4 comparators, 3 smart chests, 2 fast inserters, 3 smart inserters, a wire pole, 2 green networks and a red network, and that's per item being controlled).

You took the quote out of scope! Bobbingabout said:

However, I think a better suggestion would be better bot job assignments, rather than the suggested request.

Where I said, that the job assignement/routing of the robots is planned to improve.

Not this suggestion. This suggestion has a relatively small chance to be implemented, cause requesting items has already changed a lot and is a result of CPU optimizations and a lot of other things I forgot. It comes up from time to time. I see it also as a problem for the gameplay, cause then it's not longer clear, from where to where the items flow.