Factorio Forums

Desired effect: prevents bots from entering certain areas.

Problem statement: On my megabase, I have 3 continents with complete bot coverage. Far too often, the bots will try to cross the massive lakes that separate them. The entire bot network would collapse as thousands of bots got lost crossing those lakes or a desert that I didn't place roboports in. I've had to segregate my bot networks and build systems to maintain and move supplies between each.

Suggestion 1: A structure that prevents bots from entering certain areas. Either a building with an effect radius, or something that works like large power poles that have lines between them that bots cannot cross.

Suggestion 2: change bot behavior so that they never leave roboport range. If, for some reason, bots find themselves outside of port range, they should seek the nearest one and cancel orders.

Both of these would require pathing checks to be made when the bot leaves a roboport (either from initial activation or after a charge) or leaves a chest, or picks up or places an item (for construction robots).

Hi,

Maybe you'd like to have a look at these topics. they all share the philosophy of your suggestion, and have been discussed and elaborated for some time :
https://forums.factorio.com/forum/vie ... =67&t=8905
https://forums.factorio.com/forum/vie ... f=6&t=2259&
https://forums.factorio.com/forum/vie ... 849#p70661

Although an exclusion zone would work, and could be useful, I still prefer the idea that robots follow the path, going from roboport to roboport like a highway, rather than just flying from Point A to Point B. This would also solve your problem, because they wouldn't even try to enter the areas with no roboports, they'd travel past the roboports linking zone A with zone B.

They should go from A point to B point but also should always stay in Roboport range. Right now they took the shortest route and often leave the Roboport area.

The basic problem with all of the solutions is the cost of pathfinding.
The reason we can have thousands of robots flying around at a time is because they do not need to make a path to their destination. They only fly in the direction of their target and recharge when they are low on energy. Doing pathfinding for so many robots would halt the game to a crawl.
It's the same with biters. When biters can't track you fast enough, it's because the game can't keep up with the path updates.
Pathfinding is expensive .
Any solution to the problem should be just as fast as the current system.

Also I'd like a robot to know if it can reach its destination without having to recharge, and get to closest roboport before delivery if needed. Right now, I often see robots get close to requester chest, and realize "uh-oh! I'm just one tile away, but just realized I need to fly 20 tiles back to get some energy and come back after."

Koub wrote:Also I'd like a robot to know if it can reach its destination without having to recharge, and get to closest roboport before delivery if needed. Right now, I often see robots get close to requester chest, and realize "uh-oh! I'm just one tile away, but just realized I need to fly 20 tiles back to get some energy and come back after."

like when starting the journey plot out the path and check whether the bot can make it if not plot out how far it can get and find a port within X tiles of the path near where the bot runs out.

Then let the bot fly to that port directly and recharge and then repeat.

There's no need to deal with all this fancy pants pathing. Just have roboports part of a network. Everything inside the orange zone is a part of that network(chests, requesters, etc.), and orange zones that overlap merge into a larger network. Robots will not handle logistics outside this area because they are not aware of it.

Green zones won't merge, allowing multiple networks to service the same construction/repair duty and making it easier to separate zones.

Next, add charging stations for players who wish to support their robots without expanding the network. These can serve in emergencies where a robot over extends itself and is desperate for energy.

bobucles wrote:There's no need to deal with all this fancy pants pathing. Just have roboports part of a network. Everything inside the orange zone is a part of that network(chests, requesters, etc.), and orange zones that overlap merge into a larger network. Robots will not handle logistics outside this area because they are not aware of it.

Green zones won't merge, allowing multiple networks to service the same construction/repair duty and making it easier to separate zones.

Next, add charging stations for players who wish to support their robots without expanding the network. These can serve in emergencies where a robot over extends itself and is desperate for energy.

How do you know when a robots path is outside the network? To check that you have to make some kind of boundary check with the networks edges and if the robots does go outside the network then you have to make a path for the robot.
It might sound simple to do it, but to find the shortests path from a to b is really expensive, Especially when you have thousands of roboports and it's not uncommon to have that.

How do you know when a robots path is outside the network? To check that you have to make some kind of boundary check with the networks edges and if the robots does go outside the network then you have to make a path for the robot.

A) Don't build horseshoe networks.
B) Use smaller, tighter, linear networks, I.E. don't build horseshoe networks.

Robots aren't supposed to haul evvvvverything. They exist mainly to patch up weaknesses and inefficiencies in your factory lines. If your base has reached a point where thousands of goods have to move from one side of the base to the other, it's time to use logistical TRAINS.

bobucles wrote:

How do you know when a robots path is outside the network? To check that you have to make some kind of boundary check with the networks edges and if the robots does go outside the network then you have to make a path for the robot.

A) Don't build horseshoe networks.
B) Use smaller, tighter, linear networks, I.E. don't build horseshoe networks.

Robots aren't supposed to haul everything. They exist mainly to patch up weaknesses and inefficiencies in your factory lines. If your base has reached a point where thousands of goods have to move from one side of the base to the other, it's time to use logistical TRAINS.

Say that isn't helpful, the idea is to prevent robots flying where there is no coverage, you're saying just build networks that lack areas with no coverage. So effectively you have added nothing useful to the suggestion only that it wouldn't be needed if you deliberately avoid the issue.

Beside, people use robots in their own way, they aren't just as duct tape for poor design, they can be used to make some incredibly efficient, incredibly fast systems.

How is it that you're managing to build a logistic system that is both incredibly efficient and so grand sweeping that you have to worry about drones crossing into horrific no-bot lands?

The only reason for a bot exclusion zone is so that drones don't risk themselves flying between distant bases. If orange zones establish networks, and bots ignore requests outside their network, then you already HAVE exclusion zones. If your network is such an odd "W" shape that bots have to fly over dead zones to reach their target, that's on you. Every new AI test drains CPU resources, and in a world with thousands of drones CPU efficiency matters.

The only thing that would really help is if players could make charging stations that don't establish logistic zones. This lets them expand their drone support and gives more control over drone networks.

bobucles wrote:How is it that you're managing to build a logistic system that is both incredibly efficient and so grand sweeping that you have to worry about drones crossing into horrific no-bot lands?

This is the map screen shot of the west half of my base: Lets say I want to build a new outpost on the far west edge. Their supplies are located on the far east side of this map. The construction bots will attempt to cross those lakes. It is impossible for me to just build charging stations on those lakes. Yes, I have developed a solution. I segregated my bot networks and have outpost building supply trains. I also don't use belts on my outposts, the bots pick up the ore from the mining drills and deliver them to the train loading stations. Yes, it is incredibly fast and efficient, both to set up and to run. Since this is a vanilla map on default settings, it isn't worth the time and effort to build the belts. Many small deposits will feed each station. I do still need to haul out to each little continent about 1k of each bot type, and supplies, but I have trains that do that for me. I also never manually place rail, I just use blueprints with roboports built right into the rail system. Any other questions?

Exclusion zones might be almost as expensive to pathfind as always staying inside the roboport area.

Though one straightforward method for bot ai comes to mind.

• Check if the goal is in range with current energy level and speed upgrades. This is hopefully trivially fast.
• If not, go through ALL the roboports, and out of the ones in range, pick the one closest to the goal, then go there.
• If none within range are closer, then... do what they currently do.

This should work for lakes and such, that are vaguely roundish, and no complicated path is needed.

keyboardhack wrote:It might sound simple to do it, but to find the shortests path from a to b is really expensive, Especially when you have thousands of roboports and it's not uncommon to have that.

... Thousands? Ah. Then the above might affect performance if you mark a thousand trees for removal all at once, or your bots routinely operate at extreme ranges.

MadZuri wrote: I just use blueprints with roboports built right into the rail system.

Ooooh. Good idea. I shall remember that for huge maps.

Why is everyone saying that the pathfinding for the bots will be expensive? Pathfinding for biters and such is expensive because there are a lot of potential ways to arrive at any point P between points A and B. Each little 1m x 1 m square is a potential point the biter can arrive in (or blocked from), and for a distance of a thousand such squares, there can be up to a million points that must be considered (the order is about distance-squared). For a sizable band of critters, that's a significant load, especially if you're not caching already-constructed paths.

The drones are way different. They travel point-to-point via flying, avoiding all terrestrial obstacles. As such the only nodes of interest are the (a) roboports, (b) logistic chests, and (c) players. That's maybe a few thousand even for a large base, which is a piece of cake for any good computer, especially if the drones don't path all at once and furthermore cache their paths (which is quite feasible because most of the nodes are static) when they're on the move. Also, if bots reuse other bots' paths (which happens a lot), it gets even cheaper.

MadZuri wrote: Suggestion 2: change bot behavior so that they never leave roboport range. If, for some reason, bots find themselves outside of port range, they should seek the nearest one and cancel orders.

I'd like to second this idea.

Currently, you can only have fully connected convex roboport coverage without any holes or enemies within. This doesn't work when you try to connect outposts. I use roboports to repair laser towers along a railway. Problems when the whole network is connected is that the robots leave the coverage area

* then they either lose power and take forever

* or they run into enemies and are destroyed.

Temporary solution:

* Subidivide the coverage area into convex parts.

Better solution:

* Make the robots not leave their (orange or green) area and make them recharge when the remaining range is smaller than the distance to the recharging station.

ske wrote:

MadZuri wrote: Suggestion 2: change bot behavior so that they never leave roboport range. If, for some reason, bots find themselves outside of port range, they should seek the nearest one and cancel orders.

I'd like to second this idea.

Currently, you can only have fully connected convex roboport coverage without any holes or enemies within. This doesn't work when you try to connect outposts. I use roboports to repair laser towers along a railway. Problems when the whole network is connected is that the robots leave the coverage area

* then they either lose power and take forever

* or they run into enemies and are destroyed.

Temporary solution:

* Subidivide the coverage area into convex parts.

Better solution:

* Make the robots not leave their (orange or green) area and make them recharge when the remaining range is smaller than the distance to the recharging station.

problem is that they then need pathing which is already a significant cost for biters.

Pathing for the robots is a long-term-plan.

There are many issues fixed with that, for example that robots fly till one tile to the target, then return to recharge, then fly back.

Other threads:
https://forums.factorio.com/forum/vie ... f=6&t=3283 Logistic bot pathing improvement
https://forums.factorio.com/forum/vie ... f=6&t=7870 Robots should check whether they have sufficient energy.
https://forums.factorio.com/forum/vie ... =6&t=13457 Multiple Roboport/Blueprint suggestions

EDIT:
And I found this bug-report
https://forums.factorio.com/forum/viewtop ... =48&t=4966 robots flying inefficient

ratchetfreak wrote: problem is that they then need pathing which is already a significant cost for biters.

I concur on this one. In a typical game there are a gazillion tiles on the ground but only so many roboports per network. So yes, the cost is higher but I'd guess it's still pretty limited. With delaunay triangulation and path caching it will be even lower than A* path search because many robots use the same paths very often (e.g. when emptying a chest at a train unloading station). Short paths within the same roboport cell are no different.

Implementing these changes efficiently is going to take some time though. In the meantime I'll be watching my robots losing power and getting attacked by biters and go down in flames

ssilk wrote:Pathing for the robots is a long-term-plan.

Good to hear that, give us a slow but steady stream of improvments.