Make all bots stay inside their network

[factoriouzr]

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?

This is exactly what I am saying, that "the construction bot behaviour is smarter than the logistics bot behaviour because it improved the gameplay".

I also agree with all your points and was thinking the same things.

I think all of the points you and I mentioned are desired behaviours and would improve the gameplay.

[factoriouzr]

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.

Think creativity. What if you want a non-rectangluar base?

What if you expand you base a little one way to get a new really good resource deposit that results in your base not being rectangular? Without clearing the biters and placing structures there to prevent them from respawning, bots would constantly suicide because they would go outside the network. Even if you clear the biters they respawn too fast and would cause you the same issue. To prevent this you would have to place buildings there to prevent the spawns of new bases. However if you leave this area undefended then the next biter wave would destroy these buildings and biters would be allowed to spawn there again. The other option is to constantly replace the buildings when they are destoryed. Not only is this resource intensive, but not fun. The only realistic option is to build a wall and turrets and thus results in an unimaginative rectangular base again.

What if you are still early to mid game and roboports are expensive and you can't afford to put roboports filling a large rectangular area completely. What if resources are scarce for whatever reason and you simply can't put roboports everywhere. If you leave gaps now out of necessity because you need roboport coverage at your borders to repair damage from biter attacks, robots could take forever to get there making them useless because they fly over large areas where they run out of power.

With the current rectangular limitation of bases, lets say you have a base that's covered completely by placing 10 x 10 roboports in a square formation. Then you decide to extend your wall a little bit in one direction by adding 2 more roboports. Then to prevent bots from suiciding you need to extend the entire length of your wall and roboport coverage so you will need 20 more roboports instead of 2. This leads to very uninteresting base design by necessity because if you don't want to build trains and outposts this is all you can do. This problem becomes exponentially bigger as your base grows and most importantly it restricts creativity and fun.

Think of the possibilities this would allow that you can't do now. You could put roboports along the perimiter of your factory only and have that supplied by belt or other means with repair packs etc and have a construction bot only network that just defends your perimiter. The bots wouldn't fly over the center of your base and run out of power.

[sparr]

I think this problem is actually a bigger example of a much smaller problem that should get resolved anyway.

Even in a tiny network, a bot with almost-dead batteries will start to move towards a destination, run out of charge, then return back to base to recharge. If bots were smart enough to not do that, they would almost-automatically become smart enough to not suicide across big gaps.

[Rseding91]

It's programming: anything within logic can be done. But, it's also a game: the limitations of the system are part of the puzzle that is the game. Robots not being super smart is part of that puzzle and is not likely to ever change.

[Mehve]

Think creativity. What if you want a non-rectangluar base?

That's kind my point when I refer to trying to make a screwdriver do the work of a hammer. Why the insistence on a single massive roboport network? One of the best roboport optimizations you can do is to NOT connect them, letting you control exactly where certain bots are stationed when needed. In your "offshoot" example, why not just use a logistically disconnected port at the new offshoot, have it collect what is needed and then load it on a short belt to carry back into range of the main network?

[BenSeidel]

Think creativity. What if you want a non-rectangluar base?

That's kind my point when I refer to trying to make a screwdriver do the work of a hammer. Why the insistence on a single massive roboport network? One of the best roboport optimizations you can do is to NOT connect them, letting you control exactly where certain bots are stationed when needed. In your "offshoot" example, why not just use a logistically disconnected port at the new offshoot, have it collect what is needed and then load it on a short belt to carry back into range of the main network?

Because doing that for every t-junction in a train network is doable but is extremely obnoxious. It also depends on what you mean by "optimisation". Different sized hammers and screwdrivers have different uses. If you only have a sledge hammer and a screwdriver to put in a tack... what will you use?

Large networks are extremely usable for low throughput-low demand situations, such as repair packs for you walls / rail network or for your new area constructions where you don't care how long it takes for the construction to complete, including deconstructions of forests. I continually hear how people don't like setting up outposts because they get there and never have enough materials. If you could have a low throughput network connecting each of your outputs then it would remove that need to go back to your base for those extra 2-3 mining drills, or if you were ok with the wait, the need to carry them at all.

Recently I redid my train base and was able to get a fully covered construction network over my base. Since then I now know that I will never be using the personal roboports to build anything ever again.

the limitations of the system are part of the puzzle that is the game

Yes, but when talking about what the limitations are/should be it is best to look at the solutions that are currently used that will no longer be required/viable vs the solutions that will become available.

Currently the solution of "build in a rectangle", or at least in some shape with no concave edges. This solution will no longer be required.
None of the other solutions will be altered:
The current solution of having isolated logistics networks will still be required and will not be altered.
The current solution of placing more roboports to get more throughput will still be required.

What solutions will become viable?
Building a perimeter network to repair walls & turrets.
Building networks to handle construction and repairing of large rail networks.
Having a base that has concave edges.

So the real issue is, is the shift in the solutions acceptable or desirable? because it really does not make the game easier, just less fiddly.

[factoriouzr]

It's programming: anything within logic can be done. But, it's also a game: the limitations of the system are part of the puzzle that is the game. Robots not being super smart is part of that puzzle and is not likely to ever change.

Yet construction robots are smart enough to find the closest chest with an item that they need instead of just always prioritizing active providers, then storage chests, then passive providers.

How about that robots can insert modules into factories? That seems like a pretty advanced task.

I think it's rather arbitrary where you draw the line on how smart robots can get. I think the question you have to ask is what the gameplay advantages will be. You can look at our previous posts and you will see tons of gameplay advantages and no disadvantages (gameplay wise). By not making the robots smarter, all you are doing is forcing rectangular bases. There is NO puzzle to solve with this at all. You always have to build rectangular bases this way as robots will suicide. YOU HAVE NO OTHER CHOICE. You can make smaller bases and many outposts with local roboports that you supply by train, but these outposts will be rectangular as well.

In other words you are forcing rectangular roboport supported bases. You could put roboports just a small space away from other roboports in the same base and supply them with everything they need (walls, turrets, roboports, robots, repair packs etc) via inserters and belts going across the gap, but this is tedious and detracts from the gameplay. Then since roboports that touch their logistics zones automatically join, it makes it easy to later down the line expand these two close together networks to be larger and accidentally connect the two.

In other words, supplying multiple robot networks that are really close to each other and dealing with the annoyance of keeping two or more (say 10) networks separate just isn't worth it to me. I will just make rectangular bases then. This game is about automation to avoid tedious and repetitive tasks (that's why we have factories, otherwise you can hand craft everything for the entire game).

I think this feature would add to the game in many positive ways and improve the player experience.

[ssilk]

Hm. All what you both describe here is about play-style.

And that is always difficult to discuss.

For example: I would never come to the idea of using the logistic network to supply anything longer than 500 tiles, cause the train takes for 500 tiles distances just 8 seconds and for 1000 15 seconds. About 10 times faster than robots.
The things become difficult, when I also say "I will refuse to discuss that there are situations, where it is eventually better not to use trains for such distances."

[MeduSalem]

By not making the robots smarter, all you are doing is forcing rectangular bases. There is NO puzzle to solve with this at all. You always have to build rectangular bases this way as robots will suicide. YOU HAVE NO OTHER CHOICE.

You can make your base octagon/circle-shaped without suffering robots taking detours.

But basically I get that L-shapes and star-shapes are out of question.

Ring shapes (where one logistic network surrounds another smaller one) can be problematic too... I would wish that in this case the robots at least would be smart enough to consider charging even at "foreign" roboports if they are closer than roboports from their own network. Would at least solve problems with ring-shaped layouts or layouts where two or more seperate logistic networks are close to each other.

[BenSeidel]

Hm. All what you both describe here is about play-style.

And that is always difficult to discuss.

For example: I would never come to the idea of using the logistic network to supply anything longer than 500 tiles, cause the train takes for 500 tiles distances just 8 seconds and for 1000 15 seconds. About 10 times faster than robots.
The things become difficult, when I also say "I will refuse to discuss that there are situations, where it is eventually better not to use trains for such distances."

Hmmm. I don't think we are discussing what play-style is better than another play style. Yes, you may cut it off at 500, I may cut it off at 1000, but we can both play quite well with our cut-offs, and thats the point. I don't think that any of the "pro-changers" have said that "this build is far superior" or "Everyone MUST play this way", but "if you change this it allows us to do...." where the example is something interesting and different from the current status quo.

I can understand if there were arguments such as "doing this would make trains obsolete" or "doing this would cause belts to randomly explode" but so far there have been none of those arguments. There have been no examples of where it would be OP or break something entirely, only "If you do that you are doing it wrong" or "If you build it this way then you will get the result you want" where the "this way" is an intricate circuit design that you need a Phd to understand. Also, calling a design wrong is just, well, wrong (unless it really does not function like when you forget an input ingredient).

We are simply trying to say that this change has the benefits of allowing people to play their way, even if it is having your robots fly 4000 tiles. It may not be optimal, but it's their choice, or could be anyway.

I am interested in it because of all the shit-crazy setups I could do, but I also believe it will enhance the game because it allows people with less experience and less time on their hands to create their own oddly shaped network without having to say
"the green wire is connected to the combinator"
"the combinator is connected to the red wire"
"the red wire is connected to my wrist watch"

[factoriouzr]

Hm. All what you both describe here is about play-style.

And that is always difficult to discuss.

For example: I would never come to the idea of using the logistic network to supply anything longer than 500 tiles, cause the train takes for 500 tiles distances just 8 seconds and for 1000 15 seconds. About 10 times faster than robots.
The things become difficult, when I also say "I will refuse to discuss that there are situations, where it is eventually better not to use trains for such distances."

It allows for more options, it doesn't prevent or encourage any kind of play style.

What you are discussing is your play style and assuming what you do, is the only proper thing to do.

Also with the infinite research coming in the next version, you entire argument would change and now you can supply a larger network and still keep to your criteria. Also don't forget there are mods which can increase the speed of the bots and mods that add faster bots.

There are many ways to play the game and many designs of a factory. I say give the players the options and they will use it as they want to play the game.

[ssilk]

What you are discussing is your play style and assuming what you do, is the only proper thing to do.

No. first: I don't play like so. I made an example. And yes, I would not come to the idea to use bots that way, but the limits of 500 or so are just pulled out of the air.
What i really do is, I look, what's the best way to play that map. And if I see: uh, I need to make my factory like an "U" I think: did you remember what happened the last time you tried that? And I can decide in that moment: will I try that again, perhaps I have an idea how to manage that, or will I avoid this. I can decide!!
[Yes, I played many times with bases like so. At times, when bots where lost when they didn't charge soon enough. I lost several thousands of bots, cause I sent them accidentally through native villages. For example. And on the other hand I played games with such kind of supply and that was really boring: it took endless until I had enough resources at the outposts. In the end I think found me thinking, this kind of "robotsupply" is really not worth playing. My opinion .]

Second: assumed this suggestion is implemented. Then the players will soon find more and better ways to make suggestions. There is just no end of the wishes they have. When it would be going about the players we would have meanwhile a dozen more types of belts (each in three different speeds), natives that digs the resources for you and inserters that can walk while playing "my baby sunshine"

Third: There are limits that can't be ignored. Always. In this case CPU and development. And the simple question I need to ask as some kind of representend of the community is: is this better than automatic belt laying? (for example of course)
It's that kind of pondering, which makes me thinking: hmmmmmmmmm.

If someone would ask me, what will bring really fun into Factorio to solve these kind of supply problems I can name you three suggestions that are in my opinion much better:
A) Logistic trains (see the mod from Optera)
B) "Colored" Logistics (Even if Rseding say this ain't gonna be implemented, but that's true for his suggestion, too. )
C) "Supply rockets", there is also a mod, AFAIK
D) new type of logistic network like B, but much more expensive and much faster and only for small amounts. Like using pneumatic post. There is a suggestion and a mod for 0.12.

There are many ways to play the game....

True. But in any case you will find sooner or later limits.

[BraveSteelDragon]

I think that the underlying issue behind this suggestion is a needed overhaul of the logistic bots' behaviour when on very large roboport networks...

Improving the bots' pathing? Absolutely yes!
Is it something vital that would indeed improve some aspects of gameplay? Not really.

Improved pathing is always good, not just for the current logistic bots, but also for future objects and projects that would require similar solutions.
However, like i learned myself while playing with outstretched bases: "Are roboports truly useful on the long (literally) run?". So long that you need to actively repair and resupply a defensive line, or make a highly compact production line, then go for bots; But if you need to carry things a long distance away, it starts to make less and less sense the further away you get from the core of your operations.

Even if with the improved pathing, the material resources you save up by not having to manufacture additional robots, only end up being consumed by more roboports, and more roboports will often lead to needing more bots regardless (just like, you can probably guess it, a perfectly square network).

In the end, it all boils down to diminishing returns.

[factoriouzr]

What you are discussing is your play style and assuming what you do, is the only proper thing to do.

No. first: I don't play like so. I made an example. And yes, I would not come to the idea to use bots that way, but the limits of 500 or so are just pulled out of the air.
What i really do is, I look, what's the best way to play that map. And if I see: uh, I need to make my factory like an "U" I think: did you remember what happened the last time you tried that? And I can decide in that moment: will I try that again, perhaps I have an idea how to manage that, or will I avoid this. I can decide!!
[Yes, I played many times with bases like so. At times, when bots where lost when they didn't charge soon enough. I lost several thousands of bots, cause I sent them accidentally through native villages. For example. And on the other hand I played games with such kind of supply and that was really boring: it took endless until I had enough resources at the outposts. In the end I think found me thinking, this kind of "robotsupply" is really not worth playing. My opinion .]

Second: assumed this suggestion is implemented. Then the players will soon find more and better ways to make suggestions. There is just no end of the wishes they have. When it would be going about the players we would have meanwhile a dozen more types of belts (each in three different speeds), natives that digs the resources for you and inserters that can walk while playing "my baby sunshine"

Third: There are limits that can't be ignored. Always. In this case CPU and development. And the simple question I need to ask as some kind of representend of the community is: is this better than automatic belt laying? (for example of course)
It's that kind of pondering, which makes me thinking: hmmmmmmmmm.

If someone would ask me, what will bring really fun into Factorio to solve these kind of supply problems I can name you three suggestions that are in my opinion much better:
A) Logistic trains (see the mod from Optera)
B) "Colored" Logistics (Even if Rseding say this ain't gonna be implemented, but that's true for his suggestion, too. )
C) "Supply rockets", there is also a mod, AFAIK
D) new type of logistic network like B, but much more expensive and much faster and only for small amounts. Like using pneumatic post. There is a suggestion and a mod for 0.12.

There are many ways to play the game....

True. But in any case you will find sooner or later limits.

There is just no end of the wishes they have. When it would be going about the players we would have meanwhile a dozen more types of belts (each in three different speeds)

I don't think this is a good argument. We are playing a game that we see things can be improved on and it's part of the development process to give suggestions for improvement to the game. By your logic, nobody should ever suggest anything because then "there is just no end of the wishes". Also by your logic, personal roboports should not have been implemented into the game because there were already regular roboports that a player could place down, then put passive provider chests, then store all their items in these chests, then put construction robots into the network, and then provide power and the robots would do the same thing as a personal roboport.

Obviously this approach is tedious and not fun at all. As such the community (me included) wanted personal roboports to make this type of gameplay fun and give the players more options. As such the personal roboport was implemented. I think the game is way better for it and for the likely rare players that don't want to use it, they don't have to. As such it only adds to the game.

By the same logic, my suggestion only adds to the game as well. There are only positives that were mentioned so far.

Also there is a key difference that should be noted when you say "players we would have meanwhile a dozen more types of belts". The key distinctions is that modders can't implement my suggestion, but modders can and have added more types of belts. So if you want more belts, you can get a mod that is fully functional for that purpose, but you can't make a mod to make the bots stay in their network.

is this better than automatic belt laying?

Now you are talking prioritization. This is a suggestion forum. Leave prioritization out of it. That's a separate process.

If someone would ask me, what will bring really fun into Factorio to solve these kind of supply problems I can name you three suggestions that are in my opinion much better

Again, this is prioritization, and also not very supportive

True. But in any case you will find sooner or later limits.

True, but I never said make an infinitely large roboport network. Again this isn't an argument against my idea.

[factoriouzr]

I think that the underlying issue behind this suggestion is a needed overhaul of the logistic bots' behaviour when on very large roboport networks...

Improving the bots' pathing? Absolutely yes!
Is it something vital that would indeed improve some aspects of gameplay? Not really.

Improved pathing is always good, not just for the current logistic bots, but also for future objects and projects that would require similar solutions.
However, like i learned myself while playing with outstretched bases: "Are roboports truly useful on the long (literally) run?". So long that you need to actively repair and resupply a defensive line, or make a highly compact production line, then go for bots; But if you need to carry things a long distance away, it starts to make less and less sense the further away you get from the core of your operations.

Even if with the improved pathing, the material resources you save up by not having to manufacture additional robots, only end up being consumed by more roboports, and more roboports will often lead to needing more bots regardless (just like, you can probably guess it, a perfectly square network).

In the end, it all boils down to diminishing returns.

Again, I am not talking about large networks, I'm talking about more options for shapes of networks and opening the doors to more unique designs.

Let each player decide how large or small they want their networks, this just gives players more options and creativity.

[ssilk]

After some thinking I tag this with "logistic-robots-overhaul" and I (or somebody) will move this into a new list.

[BraveSteelDragon]

I think that the underlying issue behind this suggestion is a needed overhaul of the logistic bots' behaviour when on very large roboport networks...

Improving the bots' pathing? Absolutely yes!
Is it something vital that would indeed improve some aspects of gameplay? Not really.

Improved pathing is always good, not just for the current logistic bots, but also for future objects and projects that would require similar solutions.
However, like i learned myself while playing with outstretched bases: "Are roboports truly useful on the long (literally) run?". So long that you need to actively repair and resupply a defensive line, or make a highly compact production line, then go for bots; But if you need to carry things a long distance away, it starts to make less and less sense the further away you get from the core of your operations.

Even if with the improved pathing, the material resources you save up by not having to manufacture additional robots, only end up being consumed by more roboports, and more roboports will often lead to needing more bots regardless (just like, you can probably guess it, a perfectly square network).

In the end, it all boils down to diminishing returns.

Again, I am not talking about large networks, I'm talking about more options for shapes of networks and opening the doors to more unique designs.

Let each player decide how large or small they want their networks, this just gives players more options and creativity.

Fair enough, but remember that each and new feature that the devs add (or modify) will impact people that (for how unlikely it could ever be in factorio) will never use such feature.

Think of this: how well would a rewrite of the current pathing algorythm scale? Would it work for 4 roboports in a perfectly square shape? How about 8? 10? 20? What if all roboports are interconnected (e.g. no 'empty' gaps between their covered areas)? What if the roboports are in a perfect row? An arc? Or as some suggested, a circle?
Would this change affect construction and combat bots? If yes, how much? Would it be for the worse or the better?
Would a rewrite of the pathing code be actually worth it's cost in human (coding, debugging and testing) and virtual (RAM, processor time, save file size) resources, compared to a player's option to just build their roboport network in a way that such problem would not persist?

I'd say that even if the changes suggested come through, the benefits of 'properly' behaving logi bots would be very minimal compared to the time that could've been allocated to other features or more pressing matters.

[ssilk]

I could think to this algorithm (precondition is, that source and target-destination is in the same logistic network, of course):

1. Calculate the nearest roboport.
2. Fly to that port.
3. When arrived: Calculate a route between/over the interconnected roboports. (This route can be cached for later, so this is very fast after it is calculated once).
4. Choose the next roboport in that route and fly to that.
5. Continue with 3 until robot is at the last roboport.
6. Fly to the target, eventually charge before.

This algorithm is really simple, but the afford for the first calculation is about 100 times bigger and the afford for the cached version is about 10-20 times bigger. And the robots will fly non optimal routes.
You need to distinct: Is a direct fly in that case better? Doubles the afford another time, cause you need to calculate in both directions (from source and target-direction).

IMHO this is no way to go, if you have thousands of bots.

BUT

What if the above optimized algorithm is used, when there are only SOME bots in a network?

Let's say so: We have a ne w technology: Mass Robots or so. Without that tech we can have only - hmmmm - 50 robots on the air at the same time. And the behave with this "new" algorothm.

But with "Mass Robots" it works limitless, but with the current algorithm.

...

Hm. Much more thinking needed here.

[MeduSalem]

Well I have a quite... "odd" idea to throw into the mix for the AI pathfinding problem in general:

Vectorized Pathfinding ontop of a flow field.

http://leifnode.com/2013/12/flow-field-pathfinding/
https://gamedevelopment.tutsplus.com/tu ... medev-9007
https://www.youtube.com/watch?v=Bspb9g9nTto

That stuff exists for a quite long time already but nobody really dared to implement it in large scale into successful games yet because it has some minor problems in certain special cases, which might actually not apply in Factorio due to how there basically are no "obstacles" in the way of Robots since they fly above everything.


So basically how that works is that the Requester Chests would create an attracting force field around them in the first step and then to create a vector map based on the flow field, which then requires the bots only to follow the vectors until they reach their target destination since every vector on each tile would basically point towards the target.

The downside is that it takes a lof of initial calculation to establish these force fields and the vector maps... but once it's there there's no additional pathfinding to be done. Bots get assigned to just follow a specific vector map by looking at a tile's vector and multiplying it with the speed they travel and that's it. Also this costly initial calculation can be distributed over several seconds and doesn't have to be done "immediately" in one cycle.

The upside is that the more robots you have the better it would scale because then the initial setup benefits more and more and more robots.
Also everything that's outside the logistic network range would automatically be "skipped" and not even considered for creating the flow field/vector map because it's "tabu-area".



So there would be several vector maps though:

One for Requester Chests when bots are delivering (so robots flow towards requester chests)
One for Prodiver Chests when bots have something to pick up (so robots flow towards the Provider Chests)
One for Storage Chests when Requester Chests are all satisfied (so robots flow towards the Storage Chests)
One for Charging the robots on low energy and when they are no longer needed (so robots flow to the nearest Roboports)

In a robots life cycle it would basically cycle through the various vector maps that all exist in parallel.

So basically the vector maps would all act like a huge pathing cache that's permanently there and only gets updated once the player removes/adds something to the game. And the updating is basically only superpositioning the various individual maps.



I mean, yeah... In my opinion I think the current pathfinding in Factorio for the robots is quite good already even with its little oddities and doesn't really require a fundamental rework just to cover Ring/Circle/L Shapes. So my post is more like a hypothetical idea thrown into the mix.

The only thing that really could be better though is the charging behaviour of robots... it would be good if robots could even use foreign roboports (roboports outside the own network) for charging if they are for some reason closer or less congested than the roboports of their own network. That would already alleviate several issues.