[2.0.73] Storage chest dropoff priority affected by recent inserter activity

[Ecthelon]

I have attached a save which led me to this discovery.

In the save you will spawn near a decider combinator with an extra blank condition. If you remove that condition the copper wire production next to it will begin.

The decider combinator I mention in the post

03-16-2026, 22-20-30.png (432.39 KiB) Viewed 283 times

You will notice that the bots pick up copper plates from the nearest storage chest with copper plates in it. This is exactly what I would expect.

However, bots picking up the new copper wire from the active provider chest will take the wire down to a few different storage chests far below the nearby copper wire storage chests. EDIT: To emphasise what I put at the bottom of this post, every one of these chests already has some copper wire in, so they should have the same priority.

I was trying to figure out for ages what was causing those chests to be prioritised, and why it wasn't even a single chest being prioritised but a spread of a few seemingly at random.

Eventually I realised that it seems to be something to do with the fact that they actively have inserters adding more copper wire to the storage chests. If you hand drop copper wire onto the belt leading into the copper wire storage tests near the crafting setup, bots will occasionally start dropping off in those chests too. If you stop dropping the copper wire then the bots will go back to only dropping off in the far away storage chests.

If you stop the flow of copper wire into the far away chests and start the flow into the nearby ones, the bots will gradually shift over their priority until eventually they only drop off in the nearby ones.

The fact that the priority of the storage chests for dropoff is clearly affected in this way struck me as a bug. They should all have identical priority level for drop off as they have the same filter for copper wire and all have some items in already. In that circumstance I would expect the bots to drop off at the nearest one of those chests with space in it.

[Rseding91]

Thanks for the report however this is not a bug. Robots will pick storage chests with "some of the item already in it" over empty ones as part of the logic for where soemthing should go.

[Ecthelon]

Sorry but no, every relevant chest already has copper wire in it. You can see that in the save.

[Rseding91]

Sorry but no, every relevant chest already has copper wire in it. You can see that in the save.

They will prioritize chests with "some of the item already in it" over empty ones. Beyond that, they don't pick a specific one out of that list (there is no closest-first when picking which one to fill in this case) - they just take "the first one with some of the item in it that still has space".

[Ecthelon]

What qualifies as the "first" chest though? I can tell you it's not the first chest I placed that the bots are using, and note that the bots in the example I've provided don't drop into any single chest but instead seem to spread their dropoffs between any chests that have had items inserted recently.

I don't know what the "intended" behaviour was in this circumstance (though closest chest with relevant filter and existing items makes a lot of sense to me, particularly as that's the logic used when picking up ingredients for a requester chest), but I can't imagine that whether an inserter has been active on the chest recently should be anything to do with it.

[Rseding91]

Whenever the contents of the chest change it's moved to the front of the list of 'chests with this item in it'.

[Ecthelon]

Whenever the contents of the chest change it's moved to the front of the list of 'chests with this item in it'.

Ah well that would explain what I'm seeing then. Is that the way it should work though? It can lead to some pretty unintuitive behaviour.

What's the reason behind it not using the nearest chest like when searching for a storage chest to supply a requester chest?