Robot prioritisation of requests for same resource

[CorBlimey]

Hello

How are requests for the same resource prioritised, in particular in a constrained supply scenario? Is it by proportion of request satisfied (i.e. increasing size of request will prioritise that chest compared to others) or is it by distance from supply? Or some other criteria?

Edit: ok, I ran some tests. a) distance has no effect (at least within the 1 roboport radius I tested) on equal requests, b) request size has no effect on priority when equidistant from both robots and supply (e.g. a requester for 100 and 200, supplied with only 200 will both end up with 100 each) c) combinations thereof made no difference. Damn. Not sure how I can ensure some certain chests get the lion's share of resources, short of having 2 chests so they get twice the share.

[vanatteveldt]

I think the only thing you could do is something complicated like having two requester chests ("priority" and "normal") with low request and inserters into the actual input chest. The priority inserter inserts whenever the priority chest is < X; the normal inserter inserts whenever both priority and normal chest are <X.

[zebediah49]

I believe that the canonical (if somewhat more expensive in terms of flat resources) solution is by programming the inserters.

You use the requester chest as normal, but let it fill up to your specified level. Then, you configure the inserter going from chest to <use> to be on the logistic network, and only active if there is spare (say, more than 100) of the item available to the logistics net. Note that items in blue chests don't count as available.

This way, those activities will only work when there is a surplus of items. You can rank them based on how big the requirement is: more than 100 items activate factory set A; more than 500 activate B. Thus, when there are more than 100, you start consuming them in A, and if you have enough to get a stockpile up to 500, B will also turn on.

------

Note that this will only allow you to do a strict hierarchy model. It doesn't support "2/3rds go one way, 1/3rd goes the other" modes -- you would have to use physical splitters for that. That shouldn't be a problem though; I can't think of a use-case where there isn't a better solution available (such as an A>B activation condition).

[CorBlimey]

I believe that the canonical (if somewhat more expensive in terms of flat resources) solution is by programming the inserters.

You use the requester chest as normal, but let it fill up to your specified level. Then, you configure the inserter going from chest to <use> to be on the logistic network, and only active if there is spare (say, more than 100) of the item available to the logistics net. Note that items in blue chests don't count as available.

This way, those activities will only work when there is a surplus of items. You can rank them based on how big the requirement is: more than 100 items activate factory set A; more than 500 activate B. Thus, when there are more than 100, you start consuming them in A, and if you have enough to get a stockpile up to 500, B will also turn on.

------

Note that this will only allow you to do a strict hierarchy model. It doesn't support "2/3rds go one way, 1/3rd goes the other" modes -- you would have to use physical splitters for that. That shouldn't be a problem though; I can't think of a use-case where there isn't a better solution available (such as an A>B activation condition).

awesome idea. I didn't think of that. Thanks!

[golfmiketango]

Hello

How are requests for the same resource prioritised, in particular in a constrained supply scenario? Is it by proportion of request satisfied (i.e. increasing size of request will prioritise that chest compared to others) or is it by distance from supply? Or some other criteria?

Edit: ok, I ran some tests. a) distance has no effect (at least within the 1 roboport radius I tested) on equal requests, b) request size has no effect on priority when equidistant from both robots and supply (e.g. a requester for 100 and 200, supplied with only 200 will both end up with 100 each) c) combinations thereof made no difference. Damn. Not sure how I can ensure some certain chests get the lion's share of resources, short of having 2 chests so they get twice the share.

Just wanted to say, this post has been a real revelation for me. Now that I know the answer to how robots handle scarce resource distribution -- a fact I'd simply been too lazy to figure out myself -- I have been able to accomplish all sorts of things that previously never quite seemed to work right. Exploiting this "flaw" in robot planning is a powerful tool. I'd encourage anyone who skimmed over CorBlimey's post to read it again, carefully. Understanding this opens up a lot of simple, ugly tricks that can be easily used make huge quick/dirty changes to how scarce resources are distributed.

[Frightning]

Hello

How are requests for the same resource prioritised, in particular in a constrained supply scenario? Is it by proportion of request satisfied (i.e. increasing size of request will prioritise that chest compared to others) or is it by distance from supply? Or some other criteria?

Edit: ok, I ran some tests. a) distance has no effect (at least within the 1 roboport radius I tested) on equal requests, b) request size has no effect on priority when equidistant from both robots and supply (e.g. a requester for 100 and 200, supplied with only 200 will both end up with 100 each) c) combinations thereof made no difference. Damn. Not sure how I can ensure some certain chests get the lion's share of resources, short of having 2 chests so they get twice the share.

Just wanted to say, this post has been a real revelation for me. Now that I know the answer to how robots handle scarce resource distribution -- a fact I'd simply been too lazy to figure out myself -- I have been able to accomplish all sorts of things that previously never quite seemed to work right. Exploiting this "flaw" in robot planning is a powerful tool. I'd encourage anyone who skimmed over CorBlimey's post to read it again, carefully. Understanding this opens up a lot of simple, ugly tricks that can be easily used make huge quick/dirty changes to how scarce resources are distributed.

Yea I have done a lot w/ bots more recently for my kilobase. The fact that they try to satisfy requests uniformly makes them inherently ideal for loading chests at a train loading station because they naturally ensure that the chests fill (approximately) uniformly. I've also learned a lot from my kilobase on how to read the production screen and check the right chests to see if I really need to produce more of X or not.

[CorBlimey]

Hello

How are requests for the same resource prioritised, in particular in a constrained supply scenario? Is it by proportion of request satisfied (i.e. increasing size of request will prioritise that chest compared to others) or is it by distance from supply? Or some other criteria?

Edit: ok, I ran some tests. a) distance has no effect (at least within the 1 roboport radius I tested) on equal requests, b) request size has no effect on priority when equidistant from both robots and supply (e.g. a requester for 100 and 200, supplied with only 200 will both end up with 100 each) c) combinations thereof made no difference. Damn. Not sure how I can ensure some certain chests get the lion's share of resources, short of having 2 chests so they get twice the share.

Just wanted to say, this post has been a real revelation for me. Now that I know the answer to how robots handle scarce resource distribution -- a fact I'd simply been too lazy to figure out myself -- I have been able to accomplish all sorts of things that previously never quite seemed to work right. Exploiting this "flaw" in robot planning is a powerful tool. I'd encourage anyone who skimmed over CorBlimey's post to read it again, carefully. Understanding this opens up a lot of simple, ugly tricks that can be easily used make huge quick/dirty changes to how scarce resources are distributed.

Yea I have done a lot w/ bots more recently for my kilobase. The fact that they try to satisfy requests uniformly makes them inherently ideal for loading chests at a train loading station because they naturally ensure that the chests fill (approximately) uniformly. I've also learned a lot from my kilobase on how to read the production screen and check the right chests to see if I really need to produce more of X or not.

It makes loading simpler for sure. It could be nice to have a little control over unloading though, but it is on balance definitely good that the closest one is used in preference. I use passive providers as it avoids the need for an additional 'trip' of active providers (even if that trip is getting the material closer to its consumer). I suppose, however, that it doesn't really matter if one provider is always drained while the others are only partly. Once one chest (inserter unloading) cannot keep up with supply, the bots will start to use the first & 2nd, then 3rd and so on so ultiamtely there will always be an equilibrium at some point the only 'cost' is having a larger inventory (the chests not being currently utilised) than necessary.

It is amazing how efficient bots can be if you completely design your base around them. My 2 minute rocket factory functions on a paltry 2-2.5k bots (it spikes much higher when factory has been idling for a bit or a train deadlock messed up my ore supply and then it all arrives at once (yes sometimes I forget I temporarily parked my shuttle on the mainline ), but once it is in smooth continuous production it settles to 2-2.5k used), with the only belts used to get coal to plastic chem plants (as it is near to its consumers so quite far from my train terminus).

[Frightning]

~snip~

It makes loading simpler for sure. It could be nice to have a little control over unloading though, but it is on balance definitely good that the closest one is used in preference. I use passive providers as it avoids the need for an additional 'trip' of active providers (even if that trip is getting the material closer to its consumer). I suppose, however, that it doesn't really matter if one provider is always drained while the others are only partly. Once one chest (inserter unloading) cannot keep up with supply, the bots will start to use the first & 2nd, then 3rd and so on so ultiamtely there will always be an equilibrium at some point the only 'cost' is having a larger inventory (the chests not being currently utilised) than necessary.

It is amazing how efficient bots can be if you completely design your base around them. My 2 minute rocket factory functions on a paltry 2-2.5k bots (it spikes much higher when factory has been idling for a bit or a train deadlock messed up my ore supply and then it all arrives at once (yes sometimes I forget I temporarily parked my shuttle on the mainline ), but once it is in smooth continuous production it settles to 2-2.5k used), with the only belts used to get coal to plastic chem plants (as it is near to its consumers so quite far from my train terminus).

I know exactly what you mean about bot efficiency. My kilobase currently handles 3200 iron ore/min and 2700 copper ore/min, everything in that base is moved by logistics bots, no belts, and I am typically using just 600 of my 3000 bots (now that all bot upgrades are done), it spikes to about 1000 when multiple fully loaded trains arrive at once.

Edit: I forgot to add, I use active providers at my main unloading stations because they handle all 4 ores, coal, copper ore, iron ore, and stone, so I need to be sure that overproduction of one won't gum up the works and prevent other needed resources from being able to be unloaded from the train. For my oil train, I think I will make them passive providers so that I can ensure filled barrels won't start flooding my storage due to insane overproduction during windfall period.