[Suggestion] Bots charging priority, counting distance

[RobertTerwilliger]

Constantly having problems with bots interrupting their tasks in a millimeter before destination to go charging, sometimes even passing task destination on the way to the roboport.
Is it possible to do smth with it?))

[bobingabout]

I'm too destracted by your name to read your question, Sideshow Bob!

Ahem, not really.

I too have suffered from this effect, it would be nice if robots could plan their route, taking charge into account to include charge stops, before performing such long distance tasks.

But there are also other ideas where robots travel from roboport to roboport like highways to prevent them moving into logistic dead zones, or over enemy bases, this could be an extention of that.

[RobertTerwilliger]

Never suffered bots travelling through natives' bases, but that's the case too for some "nearly peacefull" setups, I believe (in normal setup all enemy bases that posess at least tiny threat should be eliminated)


But what I was thinking about, is:

- add a single boolean variable "low_charge" for every bot

- when bot's charge gets down to charging-need level - smal comparation should be made: say,
IF distance (current_position, task_destination) <= 10 THEN continue_task() ELSE go_charging()
set (low_charge = true)

- when bot finishes it's task (and possibly after takes new), system checks
IF low_charge == true THEN go_charging() ELSE continue_task()

//note: syntax isn't actual Factorio (Lua?) syntax - it's just to show the idea.

This way game won't make much more dynamic calculations each tick - just a bit new math at points where more much more math is done anyway - when bot gets it's charge low, and when it desides where to go next, and boolean variable even for thousands of bots won't eat much memory (1 bit - it's name probably will eat more memory actually, than data itself))

[Koub]

A long time ago, I had posted something with the same idea, but with a further refinement :
the idea would be : if a bot has to deliver something and its remaining charge will not be enough to do so, it should fly to the closest roboport on its way to recharge fully before flying to destination.

[RobertTerwilliger]

Well, for very long tasks this would probably casue bot deadlocking - if maximum charge isn't enough. Charge - move a bit, losing tiny charge - go recharging.
If having kind of treshold - it will still result in bots flying from port to port in polygon route, losing some time and wasting some charge, 'cause straight line is shorter, you know.
I understand from the link you've provided, your idea is more for bots avoiding being caught with no charge far from roboport - yes they can do that and the only way to avoid it now is not to make "C" or "O" shaped logistic networks. My idea serves another purpose and is much easier in programming sense.

Need in charge is okay - just when your base extends too much - bots start to really annoy. Sometimes base layout will make them just always fly away from requester - because the task will be always the same and charge loss will be also identical, thus if the requester a tiny bit further they can manage - they'll really frustrate you.

But I agree, if bots recharge elsewhere (not just in front of that goddamn requester again and again)) that won't bother anyone, while taking probably just the same time.

[RobertTerwilliger]

Thinking a bit more, the "low_charge" variable is even unnecessary - after task completion replace it's check by simple charge check - simpler, faster, no additional variables.

PS. I hope devs read these - I really think my idea is simple and can make quite good change...

[ssilk]

The plans are to add some kind of intelligent pathfinding to the robots, cause this described issue is just one of many. For example that you can built robot areas in U-form and the bots will go directly from one end of the U to the other and get slow in the middle, cause they can't charge there... Nice, if there are biters - I lost hundreds of bots like so...

[Yinan]

Couldn't all this be solved by making two tiered pathfinding?

i.e.
first is decided where the bots wants to go. Instead of just going there, not it looks at the nearest Roboport and declares this the start, and the Roboport which is nearest to the destination, and makes that the target.
Now, since all the Reboports have to be connected (otherwise the bot wouldn't go to the real destination in the first place), we have a graph that we can easily find the way using something like the A* Algortihm or similiar.
Additionally, this could already be precalculated whenever a new Roboport is built. Just edit the lookup table that describes how to get from Roboport A to Roboport B via all the other Roboports.

Whenever it arrives at a Roboport, it will look if it can make the trip to the next one. If not, recharge here, if yes, just go to the next roboport.

This shouldn't impact performance by much as you can recalculate the lookup table for the pathing whenever a roboport is added, but it makes sure that the Bots will only fly from Port to Port, so that a scenario like flying across a big ocean or stopping a few pixel in front of the destination just to repath to the nearest roboport (which often means that it's flying back or flying over the destination), or something similiar won't happen anymore.

[ssilk]

I think that are their plans.
http://www.factorio.com/blog/post/fff-121

[MeduSalem]

The plans are to add some kind of intelligent pathfinding to the robots, cause this described issue is just one of many. For example that you can built robot areas in U-form and the bots will go directly from one end of the U to the other and get slow in the middle, cause they can't charge there... Nice, if there are biters - I lost hundreds of bots like so...

I'm building U-forms or even ring-forms only when I want to have 2 or more seperated Logistic Networks... so sometimes I have no choice but to create L-, U- or Ring-shaped logistic networks because I have to work around the other network I don't want to touch.

That's a reason why robots should be allowed to charge at ANY roboport, wether it belongs to its network or not. That and color coded networks/improved logistic chests would also be favorable so I don't have to build U-shaped stuff in the first place.

[Yinan]

I think that are their plans.
http://www.factorio.com/blog/post/fff-121

In that FF they're only talking about the pathfinding for the biters, not the bots (considering that the bots didn't ever need pathfinding in the first place since there is no obstacle in the air and bot's can't creash into each other).

[ssilk]

Well, I mentioned the FFF due to the suggested way of pathfinding (from both ends). That is implemented and can then of course be used to calculate also paths for the bots (after that sub-feature is implemented of course).

And yes: There are no obstacles. But they need to charge and that could be done best, if they take a path over or near the roboports.