Factorio Forums

Construction robots are not prioritizing items from storage chests over items in passive provider chests. They seem to pull items from the chest closest to where it is to be placed instead of pulling items from storage chests first like logistics robots do.

Steps to reproduce:

1. Put down a robot port by itself
2. Place a passive provider chest and a storage chest (it is easier to show if they are placed at least 5-10 tiles apart
3. Put a stack of some place able item (tested with belts) in each chest
4. Place ghosts of the item type from #3 one at a time in a line.

What should happen:
Construction robots should pull items from the storage chest to place on the ghosts unless the storage chest is empty

What actually happens:
Construction robots pull items from the chest closest to the ghost regardless of chest type

Confirmed: each chest had 2k belts.

smurphy1 wrote:What should happen:
Construction robots should pull items from the storage chest to place on the ghosts unless the storage chest is empty

But, why should it behave that way?

posila wrote:

smurphy1 wrote:What should happen:
Construction robots should pull items from the storage chest to place on the ghosts unless the storage chest is empty

But, why should it behave that way?

When asking from the logistic request slots in my inventory my logistic bots pull from the storage chests before they do passive providers, so the construction bots should work the same way, no?

Storage chests are often used as temporary junk storage until the items are needed, so when something needs them they should be emptied first, even if not the closest to free up storage space. Maybe some sort of negative distance penalty, like the chest is closer than it actually is so bots go to it more often.

It could also alternate between using the storage and passive provider as a source of items to place, though that's probably much harder to code in.

London_ wrote:

posila wrote:

smurphy1 wrote:What should happen:
Construction robots should pull items from the storage chest to place on the ghosts unless the storage chest is empty

But, why should it behave that way?

When asking from the logistic request slots in my inventory my logistic bots pull from the storage chests before they do passive providers, so the construction bots should work the same way, no?

Storage chests are often used as temporary junk storage until the items are needed, so when something needs them they should be emptied first, even if not the closest to free up storage space. Maybe some sort of negative distance penalty, like the chest is closer than it actually is so bots go to it more often.

It could also alternate between using the storage and passive provider as a source of items to place, though that's probably much harder to code in.

It makes sense for logistic bots, not so much for construction bots

The construction bots pull from the closest, it is your design decision whether that closest chest is a passive provider or a storage chest

There are many ways to set up the chests and inserters so that none are placed in passive providers if storage chests still have some

Klonan wrote: It makes sense for logistic bots, not so much for construction bots

The construction bots pull from the closest, it is your design decision whether that closest chest is a passive provider or a storage chest

There are many ways to set up the chests and inserters so that none are placed in passive providers if storage chests still have some

Why does it make sense only for logistics bots? Especially since the priority comes from the chest type. Why should active providers, storage, and passive providers behave differently depending on what type of bot is fetching items? That's seems like a very inconsistent game mechanic.

The rest of your response shows this. Why should I have to care about the distance from passive providers and storage chests to a workzone for construction bots but I don't have to worry about it for logistics bots? You seem to be saying why should it be fixed if someone could use existing game mechanics to get similar behavior. But I think the better question is why should logistic bots and construction bots have different priorities when it comes to item fetching. I think most players expect them to be consistent so what reason is there for them not to be so?

smurphy1 wrote: Why should active providers, storage, and passive providers behave differently depending on what type of bot is fetching items? That's seems like a very inconsistent game mechanic.

The bots perform different functions, and have different priorities

The way it is now, construction robots find the closest chest with the item in them. If you'd like I can move this to ideas and suggestions, but it was specifically changed by kovarex in version 0.11.17 to be this way, which makes it not a bug.

posila wrote:

smurphy1 wrote:What should happen:
Construction robots should pull items from the storage chest to place on the ghosts unless the storage chest is empty

But, why should it behave that way?

Because if the closest chest is a passive/active provider chest that is the output of assemblers then the construction bots will endlessly pull from that chest because the assembler will keep producing to keep the chest filled... which results in the construction robots entirely ignoring the thousands of items that might be located in Storage Chests just because they are further away, which is honestly said just... bullshit... because it's against prefabrication logic.

They really should pull from storage chests first and only if they can't satisfy the demand then go for active/passive provider chests.

This should be changed for consistency.
Why does one type of bots use a priority system and the other doesn't? It should be either all bots use nearest or all bots prioritise active provider over storage over passive provider.
I'm fairly certain I've seen the occasional construction bot taking items from active provider, but they don't seem to prioritise those either.

MeduSalem wrote:Because if the closest chest is a passive/active provider chest that is the output of assemblers then the construction bots will endlessly pull from that chest because the assembler will keep producing to keep the chest filled... which results in the construction robots entirely ignoring the thousands of items that might be located in Storage Chests just because they are further away, which is honestly said just... bullshit... because it's against prefabrication logic.

They really should pull from storage chests first and only if they can't satisfy the demand then go for active/passive provider chests.

Construction bots will pull from the chests only if there is demand (i.e. you are expanding your factory), not endlessly, thus you are controlling the demand.
Why does the assembler keep producing if there is empty space in the chest? Because it doesn't know you don't want that. Otherwise you would have set it up to not producing the items if there are thousands of them in storage chests via e.g. logistic condition.

Klonan wrote:

smurphy1 wrote: Why should active providers, storage, and passive providers behave differently depending on what type of bot is fetching items? That's seems like a very inconsistent game mechanic.

If you'd like I can move this to ideas and suggestions, but it was specifically changed by kovarex in version 0.11.17 to be this way, which makes it not a bug.

I guess that depends on the original reason for changing it back then. From a player perspective I can't think of a good reason why construction bots should not prioritize chests in the same way but I could be missing something. It is a little frustrating to me when I deconstruct an area and end up with a bunch of items in storage but then my construction bots ignore them in favor of passive providers next to the assembler making that item just because it's 3 tiles closer to a construction job 1000 tiles away. I want my construction bots to use up the ones that have been returned to storage before taking from new production because I don't want to produce more if I don't need to. If this is all intentional I guess I will have to wire up my production area to the logistics network instead of relying on chest types and limiting chest size but to me that does not seem like good game design to need circuits to workaround inconsistent behavior.

Muche wrote:Why does the assembler keep producing if there is empty space in the chest? Because it doesn't know you don't want that. Otherwise you would have set it up to not producing the items if there are thousands of them in storage chests via e.g. logistic condition.

You shouldn't have to do that though. You don't with logistics bots because of chest priority. If construction bots had the same chest priority then you could limit production simply by using different chest types and limiting the size of chests by the assembler.

smurphy1 wrote:

Muche wrote:Why does the assembler keep producing if there is empty space in the chest? Because it doesn't know you don't want that. Otherwise you would have set it up to not producing the items if there are thousands of them in storage chests via e.g. logistic condition.

You shouldn't have to do that though. You don't with logistics bots because of chest priority. If construction bots had the same chest priority then you could limit production simply by using different chest types and limiting the size of chests by the assembler.

I see logistic bots as having the priority of acting according to chest types, construction bots as having the priority of minimizing the construction time.

If assembler's output inserter is without logistic limits, it means that you always want it to work (if there is space on the belt/in the chest), regardless of what is in the logistic network storage, that is, the priority is for the assembler to work as much as possible.
If assembler's output inserter has logistic condition, it means that you want it to work only in those cases, that is, the priority is the amount of items in the network.
It seems to me that you want both behaviors to have the same priority. Also you seem to don't mind if construction robots take longer to complete the construction and the priority is the amount of items in the network, thus the solution is to set the logistic condition. What issues did you observe after setting the condition that made you unset it?

Muche wrote:

smurphy1 wrote:

Muche wrote:Why does the assembler keep producing if there is empty space in the chest? Because it doesn't know you don't want that. Otherwise you would have set it up to not producing the items if there are thousands of them in storage chests via e.g. logistic condition.

You shouldn't have to do that though. You don't with logistics bots because of chest priority. If construction bots had the same chest priority then you could limit production simply by using different chest types and limiting the size of chests by the assembler.

I see logistic bots as having the priority of acting according to chest types, construction bots as having the priority of minimizing the construction time.

If assembler's output inserter is without logistic limits, it means that you always want it to work (if there is space on the belt/in the chest), regardless of what is in the logistic network storage, that is, the priority is for the assembler to work as much as possible.
If assembler's output inserter has logistic condition, it means that you want it to work only in those cases, that is, the priority is the amount of items in the network.
It seems to me that you want both behaviors to have the same priority. Also you seem to don't mind if construction robots take longer to complete the construction and the priority is the amount of items in the network, thus the solution is to set the logistic condition. What issues did you observe after setting the condition that made you unset it?

By that logic, there's no reason to ever use a passive provider, when you could just use an active provider + logistic network condition. The reason for passive providers to exist is so that you can have some basic control over these things without setting up logistic conditions.

Exasperation wrote:By that logic, there's no reason to ever use a passive provider, when you could just use an active provider + logistic network condition. The reason for passive providers to exist is so that you can have some basic control over these things without setting up logistic conditions.

If you want good-enough behavior, use the simple passive provider chest. If you want highly optimized behavior with no corner cases, use complicated circuit conditions.

Sounds exactly what factorio is supposed to be about.

Muche wrote:

smurphy1 wrote:

Muche wrote:Why does the assembler keep producing if there is empty space in the chest? Because it doesn't know you don't want that. Otherwise you would have set it up to not producing the items if there are thousands of them in storage chests via e.g. logistic condition.

You shouldn't have to do that though. You don't with logistics bots because of chest priority. If construction bots had the same chest priority then you could limit production simply by using different chest types and limiting the size of chests by the assembler.

I see logistic bots as having the priority of acting according to chest types, construction bots as having the priority of minimizing the construction time.

If assembler's output inserter is without logistic limits, it means that you always want it to work (if there is space on the belt/in the chest), regardless of what is in the logistic network storage, that is, the priority is for the assembler to work as much as possible.
If assembler's output inserter has logistic condition, it means that you want it to work only in those cases, that is, the priority is the amount of items in the network.
It seems to me that you want both behaviors to have the same priority. Also you seem to don't mind if construction robots take longer to complete the construction and the priority is the amount of items in the network, thus the solution is to set the logistic condition. What issues did you observe after setting the condition that made you unset it?

The problem is that you can't make a good circuit for this.

First you can not check how many items are in storage chests unless you wire them all up into a separate network. If you have a single producer and provider chest there you can check the logistic network count - content of provider chest. But only if you have single provider chest. Otherwise you have to create a wiore network for the provider chests.

Secondly even knowing how many items are in storage chests then what? Stop producing any more items till all are removed from storage chests? Then you end up with 0 items and the producer has to catch up to demand. Destroys the idea of producing a buffer amount ahead of time.

Or you produce till a certain number of items are in the logistics network. Then you might have 50 inserters in a passive provider chest and 150 inserters in storage chests. The construction robots will use the passive provider chest and the assembler will produce more. The storage chest will never get emptied unless more than 50 inserters are used at a time. Same for belts, assembler, furnaces, rails, signals, ... There goes a lot of storage space.

Klonan wrote:The construction bots pull from the closest, it is your design decision whether that closest chest is a passive provider or a storage chest

There are many ways to set up the chests and inserters so that none are placed in passive providers if storage chests still have some

If the only way to use it correctly is to only have active providers and storage chests (at least for placeable items) then it doesn't matter what the behaviour is for passive providers and could easily be made the same as for logistic bots. Could you explain what use case we're missing so we can discuss it properly?

Sadly, active providers would work really poorly for many science items which are both placeable and consumable. Logistic bots would move them to your central storage chests then immediately back out to the requester chests, rather than what is often just 4 or 5 tiles of travel. Of course the proposed buffer chests would offer a workaround. Edit: Derp, don't mind me. Just use passive providers for these items and they'll get cleared because science packs use them.

The saving grace of the current behaviour is personal roboports. They offer a sink for the construction items that can otherwise build up (because they go through logistic bot logic not construction bot logic).

Rhamphoryncus wrote:

Klonan wrote:The construction bots pull from the closest, it is your design decision whether that closest chest is a passive provider or a storage chest

There are many ways to set up the chests and inserters so that none are placed in passive providers if storage chests still have some

If the only way to use it correctly is to only have active providers and storage chests (at least for placeable items) then it doesn't matter what the behaviour is for passive providers and could easily be made the same as for logistic bots. Could you explain what use case we're missing so we can discuss it properly?

Sadly, active providers would work really poorly for many science items which are both placeable and consumable. Logistic bots would move them to your central storage chests then immediately back out to the requester chests, rather than what is often just 4 or 5 tiles of travel. Of course the proposed buffer chests would offer a workaround. Edit: Derp, don't mind me. Just use passive providers for these items and they'll get cleared because science packs use them.

The saving grace of the current behaviour is personal roboports. They offer a sink for the construction items that can otherwise build up (because they go through logistic bot logic not construction bot logic).

Just set a logistic network condition on the inserter putting into the passive provider, then there won't be any items in passive providers if there are any in storage chests

Klonan wrote:Just set a logistic network condition on the inserter putting into the passive provider, then there won't be any items in passive providers if there are any in storage chests

A limit of 1000 would mean you permanently have up to 1000 items in the storage chests. You'd have to temporarily run out to clear the storage chests. I guess you could use combinators to shut off production when there's some in storage chests..

What if you place a buffer chest next to your passive provider?
Have it request 1 item. An inserter will pick that item and start to move it to your PP chest. While in hand, the logistics bots will run off and grab an item out of storage for your butter chest.

I can't think of a good way to make it stop once your storage chests are empty without wiring those storage chests up, but you could use a timer to drop the inserter to a 1% duty cycle.
That will make your storage empty out quite slowly but consistently. Once the storage is empty you'll have an occasional waste of a bot fighting with the inserter, but that will ensure you always have at least one available logistics bot near the factory even if the others have flown off.