Make all bots stay inside their network

[factoriouzr]

Right now bots fly straight to their destination. This creates the following problems for all roboport networks that are not perfect rectangles:

1) Robots often die because they fly over non-roboport covered areas which are usually infested with biters
2) Robots run out of power and take a long time to go to the nearest roboport to recharge. This slows down accomplishing the tasks you gave your bots. It also removes more and more bots from the available number of bots because they all end up flying slowly back to recharge leaving less bots to satisfy other requests. This also significantly contributes to the first issue in that biters run out of fuel when flying over undefended territory and are easily sniped by biters.

The solution is simple. Make all bots always stay inside their respective zones (construction or logistic zone) while pathing to their destination. They should still path in straight lines, but those lines should be the most optimal while staying within the roboport covered zones.

[Rseding91]

Solution: don't build roboports that cause them to flow over biters.

Making robots follow paths would add unnecessary complexity to them slowing the game and making them take longer to do their jobs.

[ssilk]

This has been discussed several times.
There is a list of suggestions around it and I add this too:
viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot enhancements
See below Handling of Robot-Routing / Pathing / Charging

I see similar problems in this as Rseding91: It would take up too much CPU to calculate that for all bots. And - much more important - it is part of the game: The robots do a good job, but it is not optimal in all cases. The bots would become boring, if Factorio would calculate optimal routes. That points also much more to their use-case: Bots are super usable around a "centered" factory. Anything else is problem of the player.

What I would expect as player is, that the game warns me about this: I would like to see some kind of alarm or so. I think that is really important!

[BenSeidel]

What I would expect as player is, that the game warns me about this: I would like to see some kind of alarm or so.

It does, there is a little red warning saying "Your bots are dead"

[factoriouzr]

Solution: don't build roboports that cause them to flow over biters.

Making robots follow paths would add unnecessary complexity to them slowing the game and making them take longer to do their jobs.

Not really a "solution", but it is a workaround.

The issue with it the way it is, is that it forces the player to always build rectangular bases and outposts if they support robots. It makes base design boring.

If you calculate the path in real time every time a bot wants to do something, then yes, it's a huge performance hit. However I suggest you treat it like a graph. Each roboport is one node in a connected graph and all you have to do is calculate a path between the roboports themselves to avoid going into an area where there is no roboport within x distance (ie. you can make bots travel to the location of roboports before reachign their destination, then have them move out and build or do what they need to once they get to the closest roboport).

Also you already calculate and cache biter paths, why not calculate a grid of tiles robots can can move to? You would only have to update this grid when a roboport is added or removed from the network.

[BenSeidel]

What I would expect as player is, that the game warns me about this: I would like to see some kind of alarm or so. I think that is really important!

Just thought of an idea for this. What if the game rendered a red colour on the ground when you moused over a roboport (or while building) for areas that a robot could travel that is not covered by a logistics cell. It should be reasonably easy to calculate as its just a ray tracing algorithm. Also as its not something that needs to be synchronised in multiplayer, updating the cache can be done on a background thread.

[ssilk]

I suggest you treat it like a graph. Each roboport is one node in a connected graph and all you have to do is calculate a path between the roboports...

Ok, your algorithm against: Go to coordinates X,Y - like now.

What do you think is 100 times slower?

[BenSeidel]

What do you think is 100 times slower?

100 times slower is just code optimisation if they both have the same complexity.

Doing a comparison between the two,
Current algorithm:
Chest is modified: its contents or requirement is placed in a FIFO queue (constant time)
Bot becomes idle: it's put in a FIFO queue (constant time)
Scheduler runs, gets first bot (constant time) and first request (constant time) and first supplier (constant time).
Bots path is planned from X to Y, constant time.

Node based algorithm:
Chest is modified: its contents or requirement is placed in a FIFO queue (constant time)
Bot becomes idle: it's put in a FIFO queue (constant time)
Scheduler runs, gets first bot (constant time) and first request (constant time) and first supplier (constant time).
Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is), get chests current logistics cell (constant time). Look up precomputed path (constant time, linear space). Schedule bot for movement along pre-computed path.

Looking at the cost for each step, both algorithms should take the same amount of time to process each bot. There will be additional memory required, a few extra bytes per roboport, but all in all it could be made to work with minimal, if any, impact to UPS.

If you want to consider the amount of extra time a bot would spend in the air, then it will actually decrease. Why? Because of the minimum distance calculation. When above that minimum distance the bot will have to recharge. With the current system that means a detour. With a node based system it would not as they are already heading towards a roboport. Of course if the roboport has a large charging queue then it would mean a detour, but it should be far less than the current detours the bots take. You can also bake in a check to see if the bot needs charging when it passes a roboport, or just make them charge if there is a free port.

So honestly, it could be made to work. The only issues is if they want the game to operate in this fashion.

[Rseding91]

Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is)

That's not constant time. That's walking the entire logistic network set of roboports to find the path it can go to reach the target which is O(N) time compared to O(1) time.

[BenSeidel]

Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is)

That's not constant time. That's walking the entire logistic network set of roboports to find the path it can go to reach the target which is O(N) time compared to O(1) time.

Are you talking about getting the bot's current logistics cell? or the pathing part?
If its getting the current logistics cell you could associate each bot with a cell. The association can be as simple as "I'm at this chest, this chest is in this logistics cell, therefore I am in this logistics cell".
If its the pathing aspect, you can cache the routes with an O(N^2) cost in space and a constant time of 2 dictionary lookups. The space can also be reduced if only the required paths are calculated. The paths can also be lazy-loaded, so even when placing a new roboport it won't cause a massive amount of lag.

[Rseding91]

Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is)

That's not constant time. That's walking the entire logistic network set of roboports to find the path it can go to reach the target which is O(N) time compared to O(1) time.

Are you talking about getting the bot's current logistics cell? or the pathing part?
If its getting the current logistics cell you could associate each bot with a cell. The association can be as simple as "I'm at this chest, this chest is in this logistics cell, therefore I am in this logistics cell".
If its the pathing aspect, you can cache the routes with an O(N^2) cost in space and a constant time of 2 dictionary lookups. The space can also be reduced if only the required paths are calculated. The paths can also be lazy-loaded, so even when placing a new roboport it won't cause a massive amount of lag.

Or it can be left as it is with zero cost to dispatch any robot to any point on the map.

[sparr]

I have always felt like long distance bot travel is verging on abuse of the game mechanics anyway. If you want a U-shaped base, give it three separate bot networks.

[ssilk]

I think what's more needed with the bots is
A) more clever search for chargeing and when to charge. For example avoid deadlocks by flying back and forward (several ways to do this). Instead take in some situations a completely discharged bot into account.
B) enable the roboports to request % of bots that should be parked waiting for jobs. So that the bots spread better and you can place more bots on item-sources. You can put bots into roboports automatically, and with this you can drag them also out automatically.
C) enable "colored logistics": have multiple logistic networks intermixed together.

[factoriouzr]

I suggest you treat it like a graph. Each roboport is one node in a connected graph and all you have to do is calculate a path between the roboports...

Ok, your algorithm against: Go to coordinates X,Y - like now.

What do you think is 100 times slower?

100 times slower is an exaggeration and you forget that you only have to update the graph when you place/remove a roboport then you have precalculated all the paths already and you can use caching.

[factoriouzr]

What do you think is 100 times slower?

100 times slower is just code optimisation if they both have the same complexity.

Doing a comparison between the two,
Current algorithm:
Chest is modified: its contents or requirement is placed in a FIFO queue (constant time)
Bot becomes idle: it's put in a FIFO queue (constant time)
Scheduler runs, gets first bot (constant time) and first request (constant time) and first supplier (constant time).
Bots path is planned from X to Y, constant time.

Node based algorithm:
Chest is modified: its contents or requirement is placed in a FIFO queue (constant time)
Bot becomes idle: it's put in a FIFO queue (constant time)
Scheduler runs, gets first bot (constant time) and first request (constant time) and first supplier (constant time).
Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is), get chests current logistics cell (constant time). Look up precomputed path (constant time, linear space). Schedule bot for movement along pre-computed path.

Looking at the cost for each step, both algorithms should take the same amount of time to process each bot. There will be additional memory required, a few extra bytes per roboport, but all in all it could be made to work with minimal, if any, impact to UPS.

If you want to consider the amount of extra time a bot would spend in the air, then it will actually decrease. Why? Because of the minimum distance calculation. When above that minimum distance the bot will have to recharge. With the current system that means a detour. With a node based system it would not as they are already heading towards a roboport. Of course if the roboport has a large charging queue then it would mean a detour, but it should be far less than the current detours the bots take. You can also bake in a check to see if the bot needs charging when it passes a roboport, or just make them charge if there is a free port.

So honestly, it could be made to work. The only issues is if they want the game to operate in this fashion.

Well stated! Exactly what I was thinking. Thanks

[factoriouzr]

I have always felt like long distance bot travel is verging on abuse of the game mechanics anyway. If you want a U-shaped base, give it three separate bot networks.

But then you have to supply those bot networks with laser turrets, walls, repair packs, logistics bots, construction bots, resources etc. This exposes other issues with trains, complex logistics setups, no auto repair for rails etc. These systems can also use improvement.

Also how is it abuse when the whole game is about building large factories? Why should bots have limits on size where belts or trains do not? All sizes should be allowed. The only soft limit will be in the user being able to live with how long it takes material/bots/trains to travel from place to place. Also don't forget this game is heavily modded and mods can enhance aspects of the game.

[factoriouzr]

Bot's path is planned: Distance from X to Y is calculated (constant time). If less than X, direct path, otherwise get bot's current logistics cell (should be constant time, if not can be made so it is)

That's not constant time. That's walking the entire logistic network set of roboports to find the path it can go to reach the target which is O(N) time compared to O(1) time.

Are you talking about getting the bot's current logistics cell? or the pathing part?
If its getting the current logistics cell you could associate each bot with a cell. The association can be as simple as "I'm at this chest, this chest is in this logistics cell, therefore I am in this logistics cell".
If its the pathing aspect, you can cache the routes with an O(N^2) cost in space and a constant time of 2 dictionary lookups. The space can also be reduced if only the required paths are calculated. The paths can also be lazy-loaded, so even when placing a new roboport it won't cause a massive amount of lag.

Or it can be left as it is with zero cost to dispatch any robot to any point on the map.

It's actually not zero cost, it's constant time. Also this feature can be made to work with minimal performance impact and it would add to the gameplay by allowing smarter bots and more interesting bases instead of all rectangular surrounded by walls.

As an example, construction bots can prioritize storage chests instead of passive providers same as logistics bots do now, but they don't. Construction bots find the closest location of a good and take it from there. This is where bots are made a bit smarter for gameplay improvement. What I'm suggesting is the same thing. Make bots smarter so they don't suicide for gameplay improvement. This would also have other benefits as already mentioned of not needing to take nearly as many detours to charge along the way.

Again the paths can be cached through the network the first time a bot tries to fly there same as for biters. The search would also be easier as there are less points to check and they can be done incrementally as the bot flies and the paths could over time be improved as more bots fly that way. Ie. the path doesn't have to be 100% optimal the first time. Basically there are ways to do this efficiently it's just a matter of if you guys want to implement it or not.

[Boogieman14]

As an example, construction bots can prioritize storage chests instead of passive providers same as logistics bots do now, but they don't. Construction bots find the closest location of a good and take it from there.

When something was blown up by a biter attack, you'll generally want it replaced asap and not by the time a bot has managed to drag an item from the other side of the factory. It makes perfect sense for construction bots to prioritize closest available item.

[BenSeidel]

When something was blown up by a biter attack, you'll generally want it replaced asap and not by the time a bot has managed to drag an item from the other side of the factory. It makes perfect sense for construction bots to prioritize closest available item.

I believe he was saying the same thing, that the construction bot behaviour is smarter than the logistics bot behaviour because it improved the gameplay.

So the real question is, will this feature add anything to the current gameplay? Putting the perceived performance concerns aside, I think that it will. There are just too many benefits:
It will allow for more creative base design.
It will allow you to deal with a body of water and not just landfill it over.
It will prevent your robots from committing suicide.
It will prevent the bot detours for charging that currently occur.
It will prevent bots going into no man's land, running out of power and returning, then repeating the process forever.
It will allow the player to have isolated bot networks surrounded by a single large logistics one, eg Wall defences could have their own repair network without the issue of repair bots flying needlessly over your base.

Can anyone think of any side effects that are not desired?

[Mehve]

I would very much like to see the base that benefited from this idea.

Why is the roboport network being set up in such a way that there's either a vast expanse of empty space or a bunch of biter nests between two operational points? Because to me, this sounds far less like "base creativity" and a lot more like trying to make a screwdriver do the job of a hammer.