How do robots decide? How to make them more efficient?

[Pendragon]

It just took for me to build concrete all around my factory more than 5 hours with about 1500 construction robots working simultaneously. What made them slower was the decision making of robots. As far as i have experienced, there is no build priorities for robots, they just make everything randomly. Which is so far off being efficient and fast. It is also inefficient to choose where to take the resources from. Almost all of the robots taking the concrete from exact one provider chest while there are 6 others.

So, it is obvious that robots are not working perfectly. But is there a way to make them work more efficient? Is it at least possible to distribute all the resources equally all around the factory? That might make some things work better for robots for sure.

https://i.gyazo.com/beaa000e77dc3c535edf46f31f970cca.jpg

[brian_va]

Place smaller blueprints, repeat once built. Could use more bots as well.

[Pendragon]

Thanks, that would make things a bit faster, but not exactly the answer i am looking for.

[Warlord]

Every job for robots goes into a sort of queue. Every tick, the game goes through the queue and looks for an available robot to work on it. The job tries to pick the closest non-busy robot to the (material source?) job that it can, and assigns it the job. Thus, a robot closest to the chests storing the materials is picked to deliver.

Now, since the game is constantly going through the list of all concrete jobs, it pretty much randomly finds a single concrete job to deploy a robot to. But if you think about it, it doesn't really make it less efficient to have the concrete deployed randomly than it does to do it based on range.

Honestly, unless you are fine with robots delivering one concrete at a time to a large area, do it yourself. You can use the "+" key on the numpad to increases the paint-size when laying down concrete yourself to a large size. This can be much much faster than doing it via robots, though it is more manual.

EDIT: I don't really know of any way to improve the material distribution. If it is a one-off large job (like laying concrete), there's not much of a point to re-distributing the contents of concrete chests to be closer to the source jobs. But if you really want to, check into the green buffer chests. These can be used to move contents of provider chests closer to requesters without them actually being in requester chests.

[AlexMBrennan]

The job tries to pick the closest non-busy robot to the (material source?) job that it can, and assigns it the job.
But if you think about it, it doesn't really make it less efficient to have the concrete deployed randomly

I am not sure that this is correct but let's assume it is, and let's imagine the following scenario: R is roboport, P is provider, _ is space, B is the blueprint target
R_P_______________________________________________R__P_B

As outlined by you the left (i.e. most distant) roboport will dispatch bots because they are marginally closer to the provider chest which massively increases the total distance that has to be covered by bots.

Do you still think that this is the most efficient way of doing things?

[Colonel Sanders Lite]

Originally posted by AlexMBrennan:

The job tries to pick the closest non-busy robot to the (material source?) job that it can, and assigns it the job.
But if you think about it, it doesn't really make it less efficient to have the concrete deployed randomly

I am not sure that this is correct but let's assume it is, and let's imagine the following scenario: R is roboport, P is provider, _ is space, B is the blueprint target
R_P_______________________________________________R__P_B

As outlined by you the left (i.e. most distant) roboport will dispatch bots because they are marginally closer to the provider chest which massively increases the total distance that has to be covered by bots.

Do you still think that this is the most efficient way of doing things?

In that situation, there is a decision that has to be made about which provider to be use before picking the bot. That being said, I'm not too positive on how exactly that decision is made. I think the algorithm looks something like this though -

edit - I know now that this is wrong see my post below

pick the job to be done

pick the raw materials
   If the materials are available in an active provider chest
      pick the nearest active provider chest
   else If the materials are available in a storage chest
      pick the nearest storage chest
   else If the materials are available in a buffer chest
      pick the nearest buffer chest
   else If the materials are available in a passive provider chest
      pick the nearest passive provider chest

pick the nearest free bot to the selected provider chest

Again, I'm not too sure on that. Some experimentation may yield different results.

[Warlord]

I wasn't too sure about whether it is the closest robot to the job, or the closest robot to the material. It's one of the two, but I do not know which one. I'm not saying one is more efficient than the other. I'm sure there are all kinds of cases where one way would be more wasteful.

(like in your example, if the closest provider to the job was empty, does it pick the closest robot to the job that then has to backtrack to the full provider?)

[Pendragon]

Originally posted by Warlord:

Now, since the game is constantly going through the list of all concrete jobs, it pretty much randomly finds a single concrete job to deploy a robot to. But if you think about it, it doesn't really make it less efficient to have the concrete deployed randomly than it does to do it based on range.

It isn't making it less efficient but it is actually making it kind of annoying to human eye. It is happening like this, bots are choosing the blueprint randomly, not giving a priority to closest one and starting a job on distance without finishing the closer ones. It is having weird results like this before the whole queue is finished.
image: https://i.gyazo.com/beaa000e77dc3c535edf46f31f970cca.jpg

Originally posted by Warlord:

Honestly, unless you are fine with robots delivering one concrete at a time to a large area, do it yourself. You can use the "+" key on the numpad to increases the paint-size when laying down concrete yourself to a large size. This can be much much faster than doing it via robots, though it is more manual.

That's a very cool thing! Thanks, tho that would be much better to learn that earlier for me but nothing we can do. :D

Originally posted by AlexMBrennan:

The job tries to pick the closest non-busy robot to the (material source?) job that it can, and assigns it the job.
But if you think about it, it doesn't really make it less efficient to have the concrete deployed randomly

I am not sure that this is correct but let's assume it is, and let's imagine the following scenario: R is roboport, P is provider, _ is space, B is the blueprint target
R_P_______________________________________________R__P_B

As outlined by you the left (i.e. most distant) roboport will dispatch bots because they are marginally closer to the provider chest which massively increases the total distance that has to be covered by bots.

Do you still think that this is the most efficient way of doing things?

With the example above i have given, it is pretty obvious that bots do not care about the blueprint distance, they just -probably- care about the providing resource distance.

Originally posted by Colonel Sanders Lite:

pick the job to be done

pick the raw materials
   If the materials are available in an active provider chest
      pick the nearest active provider chest
   else If the materials are available in a storage chest
      pick the nearest storage chest
   else If the materials are available in a buffer chest
      pick the nearest buffer chest
   else If the materials are available in a passive provider chest
      pick the nearest passive provider chest

pick the nearest free bot to the selected provider chest

I didn't researched the logistic system research yet so i only experienced it via using only passive providers and a single storage chest which i putted in the middle of the map to try out if it will make things more efficient, and yes i think bots prioritize storage chests against passive providers.

But there was another weird thing, happened, when you look closer to the image i shared you can see that the bots are taking the concrete from exact same provider chest while there are 7 others. That chest obviously not the closest for everyone, but yet they somehow decide to use all of the resources on this box before going to another. And it was usually not happening because my production was already exceeding the demand.

Originally posted by Warlord:

I wasn't too sure about whether it is the closest robot to the job, or the closest robot to the material. It's one of the two, but I do not know which one. I'm not saying one is more efficient than the other. I'm sure there are all kinds of cases where one way would be more wasteful.

(like in your example, if the closest provider to the job was empty, does it pick the closest robot to the job that then has to backtrack to the full provider?)

Exactly, there should be an algorithm where the bots will check both closest resource and the blueprint distances, and compare all of the possibilities to find the most efficient route before leaving the roboport. Which might kind a create some performance issues in some sort of situations, in this case developers might not want to implement this kind of an algorithm.

[Emmote]

The more efficient the bots the more calculations and decisions that would need to be made. In bot heavy games that would kill the UPS and lag the game to hell.
And it wouldn't even improve the rate work gets done in a lot of situations.

It's better all round to just build more bots.

[Warlord]

Originally posted by Pendragon:

It isn't making it less efficient but it is actually making it kind of annoying to human eye. It is happening like this, bots are choosing the blueprint randomly, not giving a priority to closest one and starting a job on distance without finishing the closer ones. It is having weird results like this before the whole queue is finished.
image: https://i.gyazo.com/beaa000e77dc3c535edf46f31f970cca.jpg

Ohhh, believe me, I wish it was that way too.

Certainly, I'd also prefer that roboports and/or personal robots would do the jobs closest, but I think the way the devs have handled potentially massive job queues that they have to simply iterate through the list dumbly. If you have ever laid out a large solar field somewhere, and were confused when a local build order for a single assembler takes forever, it shows itself.

[Pendragon]

Originally posted by Warlord:

Originally posted by Pendragon:

It isn't making it less efficient but it is actually making it kind of annoying to human eye. It is happening like this, bots are choosing the blueprint randomly, not giving a priority to closest one and starting a job on distance without finishing the closer ones. It is having weird results like this before the whole queue is finished.
image: https://i.gyazo.com/beaa000e77dc3c535edf46f31f970cca.jpg

Ohhh, believe me, I wish it was that way too.

Certainly, I'd also prefer that roboports and/or personal robots would do the jobs closest, but I think the way the devs have handled potentially massive job queues that they have to simply iterate through the list dumbly. If you have ever laid out a large solar field somewhere, and were confused when a local build order for a single assembler takes forever, it shows itself.

Yeah that's another huge problem, i experienced that as well. But that is actually another topic. Prioritizing jobs that would take less amount of time than others would fix the problem kinda. For example if robots ordered to build 500 solar panels and a single inserter, they should go for that inserter first for sure.

[Colonel Sanders Lite]

I've been doing some testing on bot job selection and my earlier thoughts where wrong. Based on my experiments, I now think the algorithm looks much more like this -

pick the job to be done

pick the raw materials from the source *nearest to the job site*

pick the nearest free bot to the selected material source

The type of provider chest does not play into the decision at all.

Mostly, this will provide pretty good results but can cause an increase in flight time under a specific situation.

To use AlexMBrennan's diagram style, this would look like this -

R_P____________________________B_______P

In this situation, the materials would come from the provider to the right of the build site so the bots would actually fly past the build site to get the materials.



If anybody wants them, I can set up a downloadable save for my various experiments and you can try these things for yourself.

[Pendragon]

That's why bots should surely have a more advanced algorithm to decide for the best and search in depth.

[Emmote]

Originally posted by Pendragon:

That's why bots should surely have a more advanced algorithm to decide for the best and search in depth.

Did you miss my reply?
More advanced means more processing means more lag.

[vts6482]

Originally posted by Emmote:

Originally posted by Pendragon:

That's why bots should surely have a more advanced algorithm to decide for the best and search in depth.

Did you miss my reply?
More advanced means more processing means more lag.

This. Imagine the hit on UPS of what is being suggested in this thread - logic to infer that the player wants to prioritise building inserters over solar panels... what?

[Colonel Sanders Lite]

Originally posted by Emmote:

Originally posted by Pendragon:

That's why bots should surely have a more advanced algorithm to decide for the best and search in depth.

Did you miss my reply?
More advanced means more processing means more lag.

The processing time is definitely a big issue, yeah.

The way it is now is right *most* of the time. With just a fairly small amount of design care, the current system really does work very well.