Smarter Bot Charge Queue

[saors]

I think that bots should be smarter when it comes to queueing to be charged.

Instead of all circling around the closest roboport, they should calculate their position in line and how long it will be before they can charge. Once a bot has that time it will then check if there are any other roboports in the network that are close enough to charge them faster, if there are, the bots should go there and charge before continuing with their business.

[malventano]

I agree with this. Alternatively, I believe a MK2 Roboport would be handy, with faster charging / more charging nodes. This would help prevent the initial problem, which happens later in game as logistics load becomes larger.

[ssilk]

The logistic bots are optimized for using low amount of CPU. All that calculations take a while, by adding low gameplay-value.

What I found much more useful in my games was adding a mod that adds small charging-only roboports. And THAT I would find indeed a useful addition to the game, cause it is a small sub-game where to add those charge-only ports in an optimal way.

[malventano]

The logistic bots are optimized for using low amount of CPU. All that calculations take a while, by adding low gameplay-value.

What I found much more useful in my games was adding a mod that adds small charging-only roboports. And THAT I would find indeed a useful addition to the game, cause it is a small sub-game where to add those charge-only ports in an optimal way.

I follow you, and I've been using that mod myself on a very large map, but I've found that the calculation overhead is actually greater by adding more charging roboports as opposed to modding roboports to have more charging stations (meaning less added roboports themselves).

[saors]

The logistic bots are optimized for using low amount of CPU. All that calculations take a while, by adding low gameplay-value.

What I found much more useful in my games was adding a mod that adds small charging-only roboports. And THAT I would find indeed a useful addition to the game, cause it is a small sub-game where to add those charge-only ports in an optimal way.

I follow you, and I've been using that mod myself on a very large map, but I've found that the calculation overhead is actually greater by adding more charging roboports as opposed to modding roboports to have more charging stations (meaning less added roboports themselves).

That's a good idea. That would make for a good research upgrade. Either Logistics or Energy research could upgrade the number of charge ports.

[Rseding91]

I think that bots should be smarter when it comes to queueing to be charged.

Instead of all circling around the closest roboport, they should calculate their position in line and how long it will be before they can charge. Once a bot has that time it will then check if there are any other roboports in the network that are close enough to charge them faster, if there are, the bots should go there and charge before continuing with their business.

They already do this.

[ssilk]

What Rseding means is, that the bots already looks at the charge queue length and if queue is too long the bot chooses another port.
Or in other words (as I understand it): The path to the next roboport is equal to the distance to that port plus the queue length; the shortest path-length wins.

[Hannu]

The logistic bots are optimized for using low amount of CPU. All that calculations take a while, by adding low gameplay-value.

I am not sure than they have optimized a right thing. If you think a megabase with thousands of bots, better thing to optimize would be used CPU cycles per transported item and distance. Current CPU-cheap bots are very inefficient especially if base is not planned to save CPU. They use slow routes, they run out of charge or thousand bots wait for loading. I think that fighting against hardware limits is not very good challenge in any game, although at some point it may be necessary. I am not sure if there would be more optimal situation, but I do not believe it without better arguments.