Logistic Bot AI Improvement with Storage Chests

[MeduSalem]

I'd like to suggest a small improvment for the Logistic Bot AI:

1. When an Active Provider Chest has Items then the Logistic Bots should take these Items to the CLOSEST Storage Chest with the same Item RELATIVELY to the Active Provider Chest from which it was taken.
2. When there is no Storage Chest with the same item that still has free space (so picking an empty Storage Chest) then to the CLOSEST empty Storage Chest RELATIVELY to the Active Provider Chest.
3. And what is also necessary... and which might actually be the MOST IMPORTANT: CHECK if there is actually going to be enough room in the Target Storage Chest before sending the Logistic Robot there. Consider how many Logistic Bots are already on the way to that Storage Chest... and don't send any additional bots there if you already know there's not going to be enough space for all the items they carry.

I think these improvements should be there, the third one might actually be the easiest because its already done the same way with Requester Chests.



Currently it doesn't do any of that. If there are multiple Active Provider Chests outputting the same item then ALL Active Provider Chests want to dump their stuff into the SAME Storage Chest, no matter where it is on the map. So Bots go all over the map even if there might be a closer Storage Chest with the same item that still has space.

And once the Logistic Robots pick an empty Storage Chest then they don't pick the closest relatively to the source Chest... no... they pick them in the order in which the Storage Chest were first placed in the map, which is total garbage and causes a lot of chaos.

Also if you have a lot Active Provider Chests or otherwise high throughput then the amount of Items in-air greatly outnumber the available space in the Target Storage Chest, so when bots finally arrive at the Target Storage Chest they find that there's no room left... so they ALL have to go for the SAME Storage Chest elsewhere... so what you get is a Logistic Bot Snake of bots going from place to place. Don't know if anyone else ever noticed that effect:

Logistic Bot Snake

snake.jpg (114.63 KiB) Viewed 3558 times

I hate when it does that because I know the Target Storage Chest will be full before even a small fraction of the Logistic Bots had a chance to dump their stuff. So the Snake goes elsewhere... rinse and repeat. And as the snake goes elsewhere it builds up because more Bots will join the madness due some becoming temporarily stuck with charging up at Roboports. Which in turn requires a lot more total energy because a lot of bots are wasting their energy going around in circles.

I mean I have a smart furnace that has peak output of 20k Items/min... and I measured that it takes about 2000-4000 Active Logistic Robots to deal with that because a lot of them is stuck in the Bot Snake going from place to place until they are lucky enough to be under the few bots that get a chance to to dump their item in the Target Chest.



Another solution to the mess might be to let us set Slot Filters into Storage Chest similar to how Train Wagons have them, maybe even with Circuit Network connection where the Circuit signal tells the Storage Chest which Items to accept. Then some of the chaos above might be alleviated because you can at least specify something like an "area of operation".

[ssilk]

I know what you mean. This stupid behavior of the bots can take minutes until you have eventually luck and there are some chests, that are close together

After some thinking I tag this with "logistic-robots-overhaul" and I (or somebody) will move this into a new list.

[MeduSalem]

Yeah... In theory the Storage Chests should work like RAM/Cache systems work in NUMA platforms... where everything is accessible for every Core, but each Core tries to work with local ("nearby") locations first before allocating memory that's further away if there's no more local memory available. There they try to avoid to work with far away resources to avoid latency problems.

So in a metaphorical sense Active Provider Chests and Requester Chests should try to work with nearby Storage Chests first and then spiral outwards in the search for workable Chests if the Chests nearby are insufficient. It would be totally okay if the system does it in Manhatten method to avoid doing a Square root for finding nearby chests.

And in no way should the system try to send like >10000 Items to a Storage Chest when it can only handle 2400 or 4800 (depending on Stack Size) instances of said item.

[Rseding91]

#1 and #2 are already how robots work. #3 has been on my to-do for a while but there's currently no quick way to say "the chest will be full" and I don't want to eat a ton of CPU time doing those checks every time a robot sets out.

[MeduSalem]

#1 and #2 are already how robots work. #3 has been on my to-do for a while but there's currently no quick way to say "the chest will be full" and I don't want to eat a ton of CPU time doing those checks every time a robot sets out.

So basically it only freaks out like that and causes snakes of logistic bots because the #3 thing is not being done?

So they would pick a closer Storage Chest but they can't because they don't know that the target chest will be full. Ironic.


Well if it is that CPU intensive... how do Requester Chests work? What if someone requests like 10000 Iron Plates to a Requester Chest... fully knowing that the Chest can only hold 4800 Plates at maximum? There must be some logic that assigns only 1200 Bots to deliver 4 plates each. Or is that CPU intensive as well?


Maybe I'm thinking not too deep into it... but I guess there has to be something like a table for each Storage Chest with the current amount of items per slot. So the problem is running through all 48 stacks looking if there's still space? And that for each robot that sets out?


Couldn't it be done like so that internally the Storage Chest works like a "low priority" Requester Chest (only taking from active provider and only if no real Requester Chest needs something) that always requests the Difference between Maximum possible Items minus the Current Amount of Items inside the chest on a per "item-type in the chest"-basis?

So for example the Storage Chest currently holds 600 Iron Plates... then the Storage Chest acts like a "low priority" Requester Chest that requests 4800-600 = 4200 plates? Then if an Active Provider chest gets items and all real "high priority" Requester Chests are satisfied then it can assign up to 4200/4 = 1050 Bots to deliver Iron Plates, after which the Storage Chest will be full.

The total amount (the 4800 in case of Iron Plates) might be depending on how many free slots and how many Iron Plate slots there are in the Chest... so if another item type is also in the chest the 4800 gets reduced by 100 for each foreign slot.

So for example if the Storage Chest holds 600 Iron Plates in 6 Stacks and also 500 Copper Plates in 5 Stacks then the Requested amount is (48 - (6+5))*100 = 3700 Items. A more detailed calculation for each slot might be necessary though, but not for foreign slots.

Maybe something like that... Though I now get why it might be too CPU intensive/complex.


Maybe it would be easier if one has to select a unique Item type for each Storage Chest upon placing it. So placing a Storage Chest and the clicking on it gives a window and you select which item is allowed to go in there. Then the Storage Chest only accepts that item... which would make it A WHOLE LOT easier to check how many items there are currently in the chest... and on top it would make everything a lot cleaner... because I always despised having mixed items in Storage Chests and also not being able to control which items go inside.

[Rseding91]

#1 and #2 are already how robots work. #3 has been on my to-do for a while but there's currently no quick way to say "the chest will be full" and I don't want to eat a ton of CPU time doing those checks every time a robot sets out.

So basically it only freaks out like that and causes snakes of logistic bots because the #3 thing is not being done?

So they would pick a closer Storage Chest but they can't because they don't know that the target chest will be full. Ironic.


Well if it is that CPU intensive... how do Requester Chests work? What if someone requests like 10000 Iron Plates to a Requester Chest... fully knowing that the Chest can only hold 4800 Plates at maximum? There must be some logic that assigns only 1200 Bots to deliver 4 plates each. Or is that CPU intensive as well?.

The game knows how much is in a given chest and how many are on the way so it can say "the request will be fulfilled" If you order 50,000 items to a requester chest the robots will attempt it and until the chest is actually full they keep getting sent (over sent). Just normally nobody does that so you don't notice it's a thing that can happen.

[MeduSalem]

The game knows how much is in a given chest and how many are on the way so it can say "the request will be fulfilled" If you order 50,000 items to a requester chest the robots will attempt it and until the chest is actually full they keep getting sent (over sent). Just normally nobody does that so you don't notice it's a thing that can happen.

Hahaha... Well I have to try that at some poiint...

But apart from that it's really ugly though. So I guess... all safety checks skipped for performance reasons. No wonder that Bots perform that much better on mega bases...


Though it might actually be safe to assume that a chest can't take more than (Item-Stack-Size * 48)... which means that this could be a quick-check... so after (Item-Stack-Size * 48) items are on the way you can pick another Storage chest.

That said there might still be some bots that can't dump everything, but at least there aren't completely unrealistic amounts of bots trying to enter items.

[Rseding91]

The game knows how much is in a given chest and how many are on the way so it can say "the request will be fulfilled" If you order 50,000 items to a requester chest the robots will attempt it and until the chest is actually full they keep getting sent (over sent). Just normally nobody does that so you don't notice it's a thing that can happen.

Hahaha... Well I have to try that at some poiint...

But apart from that it's really ugly though. So I guess... all safety checks skipped for performance reasons. No wonder that Bots perform that much better on mega bases...


Though it might actually be safe to assume that a chest can't take more than (Item-Stack-Size * 48)... which means that this could be a quick-check... so after (Item-Stack-Size * 48) items are on the way you can pick another Storage chest.

That said there might still be some bots that can't dump everything, but at least there aren't completely unrealistic amounts of bots trying to enter items.

That's my current plan It won't be perfect but it will help prevent a large portion of the 'snake' that happens.

[MeduSalem]

That's my current plan It won't be perfect but it will help prevent a large portion of the 'snake' that happens.

Good to hear!

Don't know how much CPU time it takes exactly and how the data is structured in detail but it might even be worth trying to subtract "foreign-occupied slots" from the 48 slots in total before multiplying it with the Item-Stack-Size... that might reduce an additional number of bots from the snake without being too performance heavy.

If the data is structured something like that "Iron Plates=6 Slots, Copper Plates=8 Slots, Unuccopied=34 Slots" ... like a coarse-grained table (additionally to the fine grained table that holds exact values for each slot) then it might help for quick checks too. Then you can assume that something in between 34 slots and 34+6 slots fits inside the chest.

Better would be obviously if one knows exactly how much of the pick-up item-type is already in the Storage chest and how many "foreign slots" there are to subtract any unnecessary amount of robots... but the more fine-grained the checks the more performance heavy it is.

I guess the AI improvements and the caused performance degradation will require profiling anyways to see how it really turns out.