Logistic Bots stuck in far parts of Base

[Dark_star]

Late game problem with large base and logistical bots.
After delivering item they go to nearest Roboport and park, do not seem to return to central part of factory .
Example: gun turret requester calls for ammo, the bot drops off item then goes to nearest roboport and (goes on vacation) parks.
The only way it seems to get them back is to do a massive transfer in factory area which should call every available bot to be used. The out laying bots should be call back but may not reach factory area in time and again go park a little closer to factory area.
These might be called the reserve bots except for time to travel back to factory if needed.
Note: This massive transfer does causes the bots to spread out around the factory's Roboports.
any ideas?

[5thHorseman]

I'm still new at robots but the thing I'd try first is to just not have such a big area serviced by a single network. I'm starting to favor the idea that the main factory should be one network and then anything else should be separated into smaller networks, maybe with a series of arms on 1-tile borders to transfer items between networks as needed, or trains for longer distances.

The second solution is to just ignore that bot. If he's not actually needed then what's he hurting being up there? Maybe you'll need a bot up there and you'll be happy that he's nearby.

[Dark_star]

It is a good idea and one of the best accepted methods, but my style is more encompassing, to have all areas enclosed and covered by Roboports instead of outposts method.
Also unfortunately the number of "vacationing" bots can be in the hundreds . between 25% and 30% of total.
Note: I do not move raw material( iron/copper/oil) with bots (not energy effective) belts or train only.
Thanks

[TheSkiGeek]

I suppose that if you really wanted to, you could have a system that manually removes robots from the outlying roboports and ships them back to the middle of the base. Inserters can pull bots out of the roboports when they're "parked".

But the way it's currently designed, the bots go where they're needed and don't fly around when there aren't jobs to do (which would waste power in general; it just happens to be what you want them to do in this one case.)

It might be nice to be able to set the maximum number of bots that can be at rest in a particular roboport for cases like this.

Edit:

Bots are really not ideal for long-distance one-way material transfer, since they spend half their time flying back empty-handed. This is inefficient in terms of bots and wastes power. Having a supply train that goes around to top up chests in different locations works better. Or you can run a long mixed belt in a loop with the supplies.

[Harkonnen604]

Making idle bots pick random roboport to go for vacation would probably solve the problem and evenly distribute them across the base.

[TheSkiGeek]

Making idle bots pick random roboport to go for vacation would probably solve the problem and evenly distribute them across the base.

This would waste even more power and is still not what the OP (or, most likely, anyone) wants their logistic bots to do.

[Harkonnen604]

Bots are expected to be right there when you need them. When you have 500 bots, all on the edge because you paved there last time, they still sit there in the corner while 50 (out of 500) bots fly to do some task. Then these closer to center bots keep doing other tasks if 50 bots is all you need in regular situation, and you constantly keep waiting for bots because that 50-bots mini-horde chases your logistic request over and over again. If roboports would be limited to hold 50 bots at most, they would spread better and having 500 bots would actually have value in decreasing delays in bots arriving to your needs since almost every roboport will have some of them.

[Frightning]

I don't see how having the bots parked at the edges of your base is really a problem. The logistics network will keep asking for more bots until it has enough to tend to every task demanded of it (or runs out of available bots, and hence a task queue forms). If you have a large number of bots parked near the outskirts, then those bots obviously aren't needed for current demand, sure if you suddenly have a burst of demand (e.g. train with cargo arrives) there will be a longer delay while the additional bots head back to the central area to take on those new tasks, but you could just as well suddenly have demand for periphery jobs, the network has no way to know that, so it defaults to don't do anything unless there's a reason to. Realistically, all you end up having is a longer 'lag-time' from sudden demand in your central area, to that demand being met with bots.

[Harkonnen604]

If you have a large number of bots parked near the outskirts, then those bots obviously aren't needed for current demand ... Realistically, all you end up having is a longer 'lag-time' from sudden demand in your central area, to that demand being met with bots.

You get lag-time all the time, not just during sudden demand in central area. Suppose you have 450 logistic bots parked near the edge when you deconstructed train station full of ores. Central area requires about 50 bots to do the stuff, so they fly there. BUT each time a bot is chosen for the task, it picks nearest idle bot out of these 50, and if those 450 bots would spread out including center, the bot picked for central tasks would generally be closer than one of those 50. So, if those 450 bots were not idly sitting their asses on the edge, but spread out instead - if would decrease average lag inside central area for menial tasks like performing character logistic slots refilling.

The proposal is - whenever bot becomes idle (no task to do), it does not head to nearest roboport, but heads towards randomly selected roboport inside logistic network, recharging on the way there. Note that bot is considered idle during this trip, so it can be picked up for some task before it reaches that selected target roboport. This way those 450 idle bots will spend their idle time with purpose by spreading over the base and thus reduce average lag on both sudden demand surges and regular bot jobs. Yes, it will increase power consumption a little due to long trips to outskirts, but who cares.

[bobucles]

I think it would be nice enough if we could use the Red X option on roboport storage, just like with any other chest. If you don't want bots filling up on the fringes, just close the storage slots so they don't pile in.

[ssilk]

Related problem: viewtopic.php?f=6&t=24600 Improvment to Roboports Charging

One idea also described here: viewtopic.php?f=6&t=28176 Control Number of Bots in Roboport/RP Content To Circuts


The described idea is, that each roboport has some kind of circuit, which inserts or outputs robots from the roboport or into the roboport, depending on how much robots are in the roboport and how much are in the whole logistic network. The logistic bots move then the free bots around to fill them into the roboports or empty them.

[Dark_star]

These are great suggestions for "improving" current system. For now until a mod happens, moving bots by train/car (airplane mod) back to central factory area seems best.
Also having depots of common items located at far points loaded by trains, may help keep bot count down.
But there is still the CPU/bot usage problem which needs a programing approach.
Funny, managing bots is like a FEDx distribution problem. (how to get aircraft back to a central point)
Thanks for everyone's ideas.

[Frightning]

I think it would be nice enough if we could use the Red X option on roboport storage, just like with any other chest. If you don't want bots filling up on the fringes, just close the storage slots so they don't pile in.

+1 for ingenious suggestion!

[Frightning]

If you have a large number of bots parked near the outskirts, then those bots obviously aren't needed for current demand ... Realistically, all you end up having is a longer 'lag-time' from sudden demand in your central area, to that demand being met with bots.

You get lag-time all the time, not just during sudden demand in central area. Suppose you have 450 logistic bots parked near the edge when you deconstructed train station full of ores. Central area requires about 50 bots to do the stuff, so they fly there. BUT each time a bot is chosen for the task, it picks nearest idle bot out of these 50, and if those 450 bots would spread out including center, the bot picked for central tasks would generally be closer than one of those 50. So, if those 450 bots were not idly sitting their asses on the edge, but spread out instead - if would decrease average lag inside central area for menial tasks like performing character logistic slots refilling.

The proposal is - whenever bot becomes idle (no task to do), it does not head to nearest roboport, but heads towards randomly selected roboport inside logistic network, recharging on the way there. Note that bot is considered idle during this trip, so it can be picked up for some task before it reaches that selected target roboport. This way those 450 idle bots will spend their idle time with purpose by spreading over the base and thus reduce average lag on both sudden demand surges and regular bot jobs. Yes, it will increase power consumption a little due to long trips to outskirts, but who cares.

If those 50 bots in the central area really are sufficient, then it won't have need of the rest of the 400 bots on the outskirts. It's when they suddenly aren't sufficient that it will call outskirts bots in to do work, this is what I meant about sudden demand, even something as small as suddenly moving 50 items to the player character would count as sudden demand (it's demand beyond the regular, recurring jobs that the bots do). The thing is, the bots that satiate that sudden demand will now naturally end up parking near where ever that demand was, and so bots will be drawn back to the central area up to the highest 'spike' in demand. What usually causes bots to accumulate at the outskirts is when the job involves taking something from the central area and depositing it at the outskirts, that bot then looks for the nearest port and goes there unless it gets a new job. So if you are finding that your bots always end up most on the outskirts, the reason is because you have a lot of '1-way' jobs which are from central area to outskirts.

[zebediah49]

Why not use the bots to return each other? On your "no-vacation" outer-edge roboports, have an inserter (preferably a regular one) relocate the bots from the roboport into a provider chest. Then, you can have a request chest back in the middle that requests them and then re-injects them into the network where you want them.

Note that by using a slow inserter, you give the bots a chance to carry their brethren, saving you a bit of load -- three get moved from roboport to chest, causing a fourth to jump out and grab those three. If the inserter is too fast, it could grab too many (requiring more central bots to come and make the round-trip.

[Harkonnen604]

Why not use the bots to return each other? On your "no-vacation" outer-edge roboports, have an inserter (preferably a regular one) relocate the bots from the roboport into a provider chest. Then, you can have a request chest back in the middle that requests them and then re-injects them into the network where you want them.

Note that by using a slow inserter, you give the bots a chance to carry their brethren, saving you a bit of load -- three get moved from roboport to chest, causing a fourth to jump out and grab those three. If the inserter is too fast, it could grab too many (requiring more central bots to come and make the round-trip.

Haha That's nice!

[Dark_star]

Why not use the bots to return each other? On your "no-vacation" outer-edge roboports, have an inserter (preferably a regular one) relocate the bots from the roboport into a provider chest. Then, you can have a request chest back in the middle that requests them and then re-injects them into the network where you want them.

Note that by using a slow inserter, you give the bots a chance to carry their brethren, saving you a bit of load -- three get moved from roboport to chest, causing a fourth to jump out and grab those three. If the inserter is too fast, it could grab too many (requiring more central bots to come and make the round-trip.

Great idea .