Example screenshot:
- bot-charging.jpg (1.14 MiB) Viewed 850 times
Also note that this is after researching robot speed 10, so travel time is short even to distant roboports, but here they refuse to go even a few tens of tiles away.
The problem seems to be with the algorithm used to prioritize which roboport to charge at. The page https://wiki.factorio.com/Logistic_network#Roboports describes the algorithm thusly:
I believe this is referring to the queue size of the roboport the bot is waiting at, and the distance to an alternative candidate roboport. But let's consider some sample numbers. In my screenshot, I estimate there are around 40 bots waiting at the 10th roboport from the right, while the rightmost roboport is 40 tiles away and has no bots. Dividing these, we get 40/40. The quoted text does not say what the threshold is, but I surmise it is 1. Since 40/40 is not less than 1, those 40 bots continue to wait, while the 41st would switch. But that is absurd, since for bot #40, it would take less than a second to fly to the open port but (I estimate) around 10-20 seconds to wait in the queue.If the queue on that roboport is too long, they eventually choose another port. This is specified by the ratio of <distance to different roboport in tiles> / <queue size of robots waiting>.
By dividing distance by bots, the existing algorithm treats flying N tiles as equivalent to waiting for one bot in the queue (where N is the undocumented threshold, probably 1), but waiting is much more expensive than flying N tiles for any value of N consistent with observation. This also does not appear to take robot speed upgrades into account, nor the queue size of the candidate alternative.
I would suggest, when evaluating candidate roboports, that for each such roboport, we estimate charging time by calculating distance/speed + queue_size*charge_time, and select the roboport with the smallest estimated charge time. Ideally, this would be done when the bot first decides it needs to charge, rather than only after getting impatient waiting for its first choice, but this is still a sensible calculation even if only done after arriving at their first choice and deciding whether to switch.
Regardless of the cause, the current algorithm clearly produces bad results, as shown in the screenshot, and the game does not provide mitigation. The best solution seems to be to install mods that increase the charging capacity of individual roboports, but mods should not be required to overcome broken mechanics.
This issue has been reported a few times elsewhere, including:
The response in each case seems to some combination of "it's working as intended" and "any improvement would be too CPU intensive". I disagree with both. I think the example I've given (with attached save file) adequately falsifies the former, and I'm fairly confident this can be fixed (or greatly improved) by simply changing the arithmetic rather than doing any new computation.
