"Optimisation of logistic robot movement" should include making them a little smarter about where they try to move and when. While "staying in the green zone" would be a nice to have feature, there are tons of other simple things that could be improved upon... Like how they often almost reach their destination and then suddenly turn around and travel a long distance away from it because they passed their power threshold, after having wasted a huge amount of that power (and time) flying toward a destination that they could easily have determined was "unreachable" with their current charge level. When one bot occasionally does it that's just a slight nuisance, but when several hundred bots all do that at the same time (for example, when you re-enter your logistics network after using up a lot of your requested items), it can be Extremely Aggravating, having to sit there waiting for the massive swarm of bots to slowly get recharged by the handful of roboports they scattered to after not quite reaching you.ske wrote:Are we getting something to make the bots stay in the green zone?
It should be a fairly straightforward matter to check the distance to a location when determining a new path (say, they've just launched and are heading toward a provider chest, or they've reached the chest and picked up the cargo and are now ready to head toward the requester or the player). If the distance exceeds the distance they are willing to travel with their current amount of power, then do the following: figure out where they will be when they run out of power, find the closest roboport to that location as if they were already there, and set a direct course for that roboport instead. Once they've recharged they can repath, following the same logic, until they reach their destination. Of course, if the target is a moving player, it's possible they'll run low on power and have to divert toward a roboport anyway... But if a player is running away from their poor logi bots, they deserve what they get.
Dealing with issues like wide gaps in a logistics network (U or C shaped networks or situations where someone has unwisely placed roboports along all of their rail lines, for example) would undoubtedly require some additional logic to avoid having robots get "trapped" in one area. But all of that would only need to occur at the moment when the bot determines its new path, and all of the ticks between then and when it reaches that destination are just going to be "move toward destination" along with whatever checks they currently run as they move (for things like the player moving out of the logistics coverage area, the destination no longer existing, and such). A well designed base with a dense roboport network running thousands of bots instead of belts would likely avoid the aforementioned pitfalls -- and any time that the distance to be traveled is less than how far they can go on their current charge, no additional logic would be required anyway. So the performance cost shouldn't be too significant even before it gets thoroughly optimized.
Another thing that would optimize the gameplay experience (rather than the speed of the code behind it) would be that when bots are waiting to recharge, particularly if they are out of power, the next bot in line for a certain charging pad should begin moving toward that pad without waiting for that pad to free up, so that the entire process of handling a swarm of bots which all want to recharge from the same roboport is not drastically slowed down by pads sitting empty but reserved for bots that have to cross the distance from where they're waiting. Since bots don't collide with each other, allowing the next bots in line to move into position so they can instantly begin charging as soon as the bot currently being charged finishes would speed up matters even when bots aren't out of power, and the difference when they are would be quite dramatic.
And speaking of waiting to charge, a bot which just wants to fly to a roboport and dock for a nap should never cut in line ahead of bots that currently have jobs to do -- they should always get bumped to the end of the queue. (For that matter, why can't they just recharge on their docking cradle inside the roboport???) And bots which are already carrying cargo should always have higher recharge priority than bots which are on their way to pick up cargo, except maybe for construction bots that have been assigned to deconstruct objects which conflict with blueprint ghosts (like trees and rocks)... Non-conflicting trees can wait, but having a bot holding an item and hovering over the correct location but unable to place it is terrible. Maybe you can optimize the job assignment code to avoid creating that situation in the first place, though!
... Another feature that would be lovely to have is a non-mod structure with a small footprint (perhaps 2x2) that serves solely as a robot charging station. No docking space, no need for it to extend the logistic network, and it should only function at all if placed inside the orange-brown logistics coverage area of a full roboport... or at least the green zone. That way, when you're building those factories with no belts and thousands of bots, you don't have to spam hundreds of large, blocky, not-exactly-cheap, and perhaps even more annoyingly, stacking only to 5 at most roboports everywhere, taking up lots of floor space, making it difficult to walk through an area, and filling the map with crazy quilt patterns of dotted yellow lines and weird coverage zone shapes. If a small area needs to operate around 500 bots, just throw down a couple of roboports to give the bots enough docking space and sufficient logistics coverage, and distribute a couple dozen Auxiliary Robot Charging Stations (or towers, or platforms, or whatever you think they should be called) throughout the areas those bots are likely to be frequenting, and you'd have a much more elegant and much friendlier solution.
