Factorio Forums

remember it's not just about CPU, you're basically asking for another flag to be stored with roboports, and this is a problem for Factorio's memory performance - which is more important than CPU. that data has to be stored, passed around, etc.. and updated in a way that doesn't cause parallelism to block. i.e. memory locality is a must.

I am not asking for anything to be added to the game, simply for some already existing values to be adjusted. If this is a misconception, please explain how in detail.

ptx0 wrote: Fri Dec 04, 2020 5:02 pm remember it's not just about CPU, you're basically asking for another flag to be stored with roboports, and this is a problem for Factorio's memory performance - which is more important than CPU. that data has to be stored, passed around, etc.. and updated in a way that doesn't cause parallelism to block. i.e. memory locality is a must.

As far as I can see, there is no other flag involved. No additional memory needed for this suggestion till now.

All what is changed here is the algorithm that decides, which roboport a robot will take to recharge. This algorithm is currently very simple. The last time I read about it, it was so, that the queue of a roboport is added to the distance of the robot to that roboport. The robot takes that roboport, where the result is the lowest. All what this suggestion changes (the OP) is that the queue is multiplied by some factor before adding.

All I added is, that there is a different multiplicator for logistic and construction bots and that for construction bots there is a max distance (which reduces the number of possible roboports), and if that distance is too far, it just will continue and look up after some seconds again. This is especially to keep the nerving of logistic bots vs. belts and to buff construction of bigger blueprints.

Kahnugo wrote: Fri Dec 04, 2020 6:44 am If the general behaviour is similar to early versions on the game, then radius translates into increased weight, which then translates into longer queue before alternatives are picked. So in my understanding increasing weights would in practice be similar to dynamically reducing the queue limit (acting as a soft cap).

ssilk wrote: Fri Dec 04, 2020 5:40 am .. I mean there is an range-indexed list of all roboports in a network. I’m sure it takes only a fraction of nanoseconds longer to scan some more roboports.

Can you elaborate on that, is there a source? Because I would really like to get some updated real information about the inner workings rather that going by what is mostly speculation based on old bits of information and general sense of how things work in the game (which is obviously potentially flawed because of my lack of in depth knowledge).

No, I haven’t the code to check it, but what I know from modding there must be extra lists of roboports and it would be stupid not to have the coordinates in an indexable form, because this search operation needs to be done several times per tick.

5 | S| 18 | 23 | 24
5 | 14 | 23 | 28
0 | 13 | 24 | 32
0 | S| 18 | 28 | 27
Where the numbers are robots in queue and S is a substation.

Dunno, what you mean with this list of numbers. If that are roboports in some kind of “fixed grid” I would add SOME around those with the highest numbers, or - if you don’t like that or if that is a steady push of logistic transport - I would reduce the number of robots in that network, because it makes no sense.

ssilk wrote: Sat Dec 05, 2020 12:31 pm

5 | S| 18 | 23 | 24
5 | 14 | 23 | 28
0 | 13 | 24 | 32
0 | S| 18 | 28 | 27
Where the numbers are robots in queue and S is a substation.

Dunno, what you mean with this list of numbers. If that are roboports in some kind of “fixed grid” I would add SOME around those with the highest numbers, or - if you don’t like that or if that is a steady push of logistic transport - I would reduce the number of robots in that network, because it makes no sense.

Each number represents a roboport and is the queue of robots on that roboport. I just took a small selection of roboports in the network, there are roboports on all sides of the ones represented here, those to the right of more congested ones are slightly more congested that the ones shown because they are more on the center of a large flow of robots.

It is not possible to reduce the number of robots of the network as then the orders would not get satisfied. It is not possible to spread it out either as the demand(and supply of empty barrels) come almost exclusively from a single MK3 factory building from factorissimo2. As I think I've mentioned earlier I have much of the floor covered with roboports as tight as I could fit it.

I would like for them to spread out a bit further using the roboports slightly off the transport lines. As you can see once it starts dropping off it doesn't take many roboports before there are empty charging stations not being utilised.

Without a picture of how this looks in game this numbers are useless and cannot be discussed.

But in that case I generally recommend to use a mod
https://mods.factorio.com/mod/Robo-Charge-1x1
https://mods.factorio.com/mod/InstantRobotCharging

And I personally like
https://mods.factorio.com/mod/Robocharger
Which is easy to update yourself (needs just a higher version number).

And this shows the problem of bots vs. belts quite well: bots are not useful for transporting big amounts of items over longer distances. The reason why I want to have construction bots buffed, but not logistic. The change for logistic would not bring very much here, but it would spread out the bots (and so the basic problem), to make it more obvious for the player.

But as said, I need to see a picture to be more precise.

I think this was the spot I took a reading on. The traffic does vary a bit depending on where it's taking the barrels from, so the numbers at this exact spot might not be the same as when I looked at them. The purpose was to show the numbers I was seeing at a specific time at a specific place to illustrate what's happening. The numbers are more relevant than the picture anyway and I don't see why you can't discuss those without seeing a picture of some roboports.

I don't intend to install mods to increase the capacity of the network, that's not why I made this suggestion. I wanted the robots to use the existing capacity, because it feels a little unsatisfying that it doesn't. If I just wanted more capacity through mods there are a ton of ways I could achieve that.

I don't know what you consider longer distances. I already estimated the average distance from source to destination to be around 75 tiles, counting the total distance ignoring that items are transported to buffer chests that are 1-5 tiles from the destination. Sure, a bit longer than the optimal bot use case, however in this case bots are still the best option since no other available option has the ability to deliver very high throughput to a limited footprint (which is what I need here, the chests need between 100 and 700 barrels per second currently). What's currently limiting me is not even congestion issues, but rather that requests aren't handled quickly enough at all times.

Kahnugo wrote: Sun Dec 06, 2020 9:35 am The numbers are more relevant than the picture anyway and I don't see why you can't discuss those without seeing a picture of some roboports.

Because it is a difference if I place 20 roboports per chunk or 0.5 roboports.

I don't intend to install mods to increase the capacity of the network, that's not why I made this suggestion. I wanted the robots to use the existing capacity, because it feels a little unsatisfying that it doesn't. If I just wanted more capacity through mods there are a ton of ways I could achieve that.

Now when I see that I’m not sure, this this suggestion would help you much. In my eyes you are overusing robots.

Or so, are all these waiting robots transport items? Or is it so, that they wait to recharge before parking in the roboport?

I don't know what you consider longer distances.

Above 500 tiles.

I already estimated the average distance from source to destination to be around 75 tiles,

One reason more to use belts instead.

the chests need between 100 and 700 barrels per second currently). What's currently limiting me is not even congestion issues, but rather that requests aren't handled quickly enough at all times.

I don’t know what you’re building. I assume some kind of train station need to be filled/emptied. You’re saying you won’t use mods. But then you need to build so, that it works reliably. I have build similar things in the past, and it works up to very high capacities like a cat.

When you want to transport 700 items per second with bots reliably, you need 200 bots per second. You say it is 75 tiles times 2 (they need to go back) you have a distance of 150 tiles. Per second you said they can travel about 30 tiles per second, which means you need 600 bots at minimum. I would say with 900 you are safe. Should be working with this layout. If not, I think you’re making something quite wrong. Is that the an extra network? If not it explains the delay. Do you have more such similar constructions? You need to know that Factorio has an upper limit of bots, that can be ordered per second. I remember 600 logistic tasks can be made per second in total.

ssilk wrote: Mon Dec 07, 2020 8:36 am

Kahnugo wrote: Sun Dec 06, 2020 9:35 am The numbers are more relevant than the picture anyway and I don't see why you can't discuss those without seeing a picture of some roboports.

Because it is a difference if I place 20 roboports per chunk or 0.5 roboports.

But it doesn't matter when the point is that 12 tiles away from a roboport with a robot queue of 32 there is a roboport with 0 queue. what roboports there are in the chunk behind the roboport with 0 queue is irrelevant. The ones on the other side are not all that interesting either, because I'm interested in the gradient of the robot queues and roboports on the other side, assuming symmetric behaviour, would only matter in terms of size of the spike. The non visible roboports are essentially affecting the system by a constant. (Hence it doesn't change the overall behaviour).

ssilk wrote: Mon Dec 07, 2020 8:36 am

I don't intend to install mods to increase the capacity of the network, that's not why I made this suggestion. I wanted the robots to use the existing capacity, because it feels a little unsatisfying that it doesn't. If I just wanted more capacity through mods there are a ton of ways I could achieve that.

Now when I see that I’m not sure, this this suggestion would help you much. In my eyes you are overusing robots.

Or so, are all these waiting robots transport items? Or is it so, that they wait to recharge before parking in the roboport?

My aim is to get more usage out of roboports that are currently not fully in use, but still fairly close to the flow of robots. I'm not expecting it to remove congestion from the network, that's just a fee a have to pay (in GW and UPS) to converge all my resources to what is essentially a single chunk.
It's not possible to see if the robots waiting to charge are idle or working and it's not relevant for this case either as it's only about increasing the spread a bit more when roboport charging queues increase.

ssilk wrote: Mon Dec 07, 2020 8:36 am One reason more to use belts instead.

I already explained why I am using robots and why it is not possible to use other means of transportation. Belts transport up to 45/s, belt to chest is abysmal, in particular because the top transfer rate would be a single chest to chest inserter rate with stack size 10 and fluids become unmanageable in large quantities in tight spaces. (I'm quite certain I already explained that I'm transporting items into a factorissimo2 building).

the chests need between 100 and 700 barrels per second currently). What's currently limiting me is not even congestion issues, but rather that requests aren't handled quickly enough at all times.

I don’t know what you’re building. I assume some kind of train station need to be filled/emptied. You’re saying you won’t use mods. But then you need to build so, that it works reliably. I have build similar things in the past, and it works up to very high capacities like a cat.

ssilk wrote: Mon Dec 07, 2020 8:36 am When you want to transport 700 items per second with bots reliably, you need 200 bots per second. You say it is 75 tiles times 2 (they need to go back) you have a distance of 150 tiles. Per second you said they can travel about 30 tiles per second, which means you need 600 bots at minimum.

To have 700 items arrive per second you need: 700 * average time per robot trip / 4 robots at minimum (there are reasons why this is not possible in practice). That means assuming 150 tiles per trip, 80% energy spent on movement contributing to the item transfer and 4 items per trip (almost the case in this instance, but not quite) an average trip time (I am assuming here that the 20% loss covers waiting time and detours for charging) of 9.5 seconds, means 0.421 items per second per robot. So 1663 robots, furthermore each water barrel that goes in comes out as an empty barrel. So 3546 robots (Edit: On second thought, this numbers is inflated that there is significant overlap between the two transports, in reality the number is probably closer to 125-150% of the water barrel transport, this covers for the fact I completely forgot to factor in the transport of other items ) to get 700 water barrels inside per second.
My current energy production is 9.5GW of nuclear power, so just the nuclear power would by these calculations require at least 9.5*100(heat exchangers)*103/50(water barrels needed to feed them)/700*3546 = 9914 robots to sustain. That is not counting the 950 SPM factory also inside the same building. That's not far from what I need in practice in average (there are other issues that I wont go into here, because it's not related to the topic).

ssilk wrote: Mon Dec 07, 2020 8:36 am You need to know that Factorio has an upper limit of bots, that can be ordered per second. I remember 600 logistic tasks can be made per second in total.

I think you're confusing things with construction queues. Many logistic networks would have completely broken beyond function if this was the case. But there definitely are some limitations in the logistic manager (not 600 tasks per second though). Have in mind that I am actively consuming close to 2k water barrels/s (3900 barrels handled per second outside the factory and at least the same amount handled inside the factory, not counting the 4k robots working at the packaging facility and) along with 950 SPM produced and transported through nested layers of factory buildings.

it might be interesting if there were a mod interface to enable some kind of smarter pathfinding algo for bots. modders could then add a "Smart Logistics Bot" that could be used for the more intensive parts.

ptx0 wrote: Tue Dec 08, 2020 2:14 am it might be interesting if there were a mod interface to enable some kind of smarter pathfinding algo for bots. modders could then add a "Smart Logistics Bot" that could be used for the more intensive parts.

I would prefer that, too. All we discuss here is super theoretical or discussion of problems, that occurs when overusing robots.

ssilk wrote: Tue Dec 08, 2020 6:41 am

ptx0 wrote: Tue Dec 08, 2020 2:14 am it might be interesting if there were a mod interface to enable some kind of smarter pathfinding algo for bots. modders could then add a "Smart Logistics Bot" that could be used for the more intensive parts.

I would prefer that, too. All we discuss here is super theoretical or discussion of problems, that occurs when overusing robots.

It's kind of annoying that most posts don't actually discuss the suggestion, but all sorts of other suggestions relating robots (I thought these were one suggestion per thread). It's getting repetitive, but I'm not suggesting to change robot behaviour fundamentally (not suggesting a pathfinder change, currently it's straight line to destination for optimization reasons), but a change to weights on how it picks charging destination.
Imagine you have a container for 30000 units of whatever. But it can only contain 20000 because it's dispersed too late to spread out in the whole container. Of cause you wont notice it much if you only use it to store 5000 units, but it's not satisfying when you try to store 20000+ and it overflows at the top.

As said: logistic network is not thought for that.
That’s why the discussion spreaded, because it took me a while to understand that you’re not talking about”normal” usage cases.

If you added for the “why” in the OP “because I need to transport up to 50,000 items per minute”, this discussion would have been much shorter.

Kahnugo wrote: Tue Dec 08, 2020 9:20 am It's kind of annoying that most posts don't actually discuss the suggestion, but all sorts of other suggestions relating robots (I thought these were one suggestion per thread). It's getting repetitive, but I'm not suggesting to change robot behaviour fundamentally (not suggesting a pathfinder change, currently it's straight line to destination for optimization reasons), but a change to weights on how it picks charging destination.
Imagine you have a container for 30000 units of whatever. But it can only contain 20000 because it's dispersed too late to spread out in the whole container. Of cause you wont notice it much if you only use it to store 5000 units, but it's not satisfying when you try to store 20000+ and it overflows at the top.

my friend, this is implementing of pathfinding for robots!

because you're trying to give them a better path to their destination - one that gives them better access to charging. potato, potato.

personally, i like that the robots aren't totally foolproof, they require some thought to be put into their design more than just spamming roboports down for better charge coverage. i think maybe others feel the same way, which is why they aren't really supporting/discussing your suggestion.

ptx0 wrote: Thu Dec 10, 2020 8:06 pm my friend, this is implementing of pathfinding for robots!

because you're trying to give them a better path to their destination - one that gives them better access to charging. potato, potato.

That is not path finding... I am not concerned about the destination of the goods when adjusting how to find the destination for charging. Pathfinding is finding a path from somewhere to a destination. This has nothing to do with how it determines which roboport to go to.

ptx0 wrote: Thu Dec 10, 2020 8:06 pm personally, i like that the robots aren't totally foolproof, they require some thought to be put into their design more than just spamming roboports down for better charge coverage. i think maybe others feel the same way, which is why they aren't really supporting/discussing your suggestion.

If people do not support what I suggest, maybe addressing it would be a good way to go about it instead of talking about unrelated stuff. Why would it be a bad thing, what are the pro's and cons. So far people are hardly acknowledging what I've written in my original post.

It doesn't help that what I'm saying is taken out of context and/or being misrepresented constantly. For example:

ssilk wrote: Wed Dec 09, 2020 6:10 am
As said: logistic network is not thought for that.
That’s why the discussion spreaded, because it took me a while to understand that you’re not talking about”normal” usage cases.

If you added for the “why” in the OP “because I need to transport up to 50,000 items per minute”, this discussion would have been much shorter.

If you read my Why section you'd know that this is just plain false. If you actually read what I've been posting you would know that it is not being limited I am concerned about, it is HOW the system seems to have a technical limit before a gameplay limit. What I mean by that is that gameplay elements (things like charging rate, number of charging stations, battery size of robots and so on) rather than technical limitations (in this case that robots tend to wait around at congested roboports rather than taking a relatively short trip, less than 20% of the time spent, to charge at an empty charging station).

Is there any solid reasoning behind why the robots aren't going for those charging stations. If the answer is to limit the throughput of robots, then I suggest doing it through gameplay means. If it is not then is there something else preventing this from being changed.

THAT is why I made this post, but apparently if people don't understand what I am asking or why, then it's better to talk about something else than to actually ask what I mean.

Pathfinding is finding a path from somewhere to a destination.

Somewhere: where the robot sees “oh, my fuel is going below 20%”. Destination: the roboport, where the robot can recharge. That’s pathfinding, because it is an optimization algorithm.

Is there any solid reasoning behind why the robots aren't going for those charging stations.

Well, this made me thinking. I’ve made me the work to look a bit deeper into this subject, because I was a bit unsure, if all I already said was correct.

- robot pathfinder searches for a roboport, where distance multiplied by waiting queue is minimal.
I’ve looked into the wiki:
https://wiki.factorio.com/Logistic_network

Generally, a roboport can charge between 50 and 70 bots per min, 4 at a time, but are not very efficient at charging large queues of bots and can quickly become overworked.
When the charging-queue for the bots gets too long, the bots (and their loads) will slow down. Normally a robot flies to the nearest roboport to recharge. If the queue on that roboport is too long, they eventually choose another port. This is specified by the ratio of <distance to different roboport in tiles> / <queue size of robots waiting>.

So I was wrong. I thought it is a linear distribution (distance minus waiting queue), but this non-linearity of 1/n is what you see: a roboport with distance of 100 and one robot waiting has the same weight as a roboport with distance 50 and two waiting or one in 25 tiles and 4 and so on, until 30 waiting robots, in distance of four. This is what you see: the robots tend to keep as near as possible to their current position.
- this explains why not all of your tight standing roboports (distance 4) are occupied but all of my wide standing roboports are used for charging (distance 50-200).

If the answer is to limit the throughput of robots, then I suggest doing it through gameplay means

Meanwhile I think this is a complex balanced mixture between minimal CPU-usage, a clever mechanism to let robots charge at other roboports, while avoiding long detours and the already mentioned bots vs. belts discussion. Koub has made a nice overview about That discussion: viewtopic.php?p=513823#p513823
I’m not going to repeat that discussion here.

Some personal thoughts about this:

- from my experience I can say, that logistic robots are not good in handling a steady stream of many items reliably, because of charging. Items that where earlier ordered arrive later. This leads to “gaps” when you want to achieve a steady item-stream.
- all that can be done is: increase buffer-size and use multiple ways to transport items,
- which is for example, that you can add belts as a second transport, which reduces the loads for the robots, which are then able to handle sudden demands more rapidly. Or reduce the distance. Many possible solutions.


Robots are perfect to handle sudden requests with extremely (!) high throughput with a distance up to 100 tiles, but then they need time to recharge and rest in the roboports. I remember I’ve had no problems to load/unload a train station with a throughput of 40000-80000 items per minute. Trains come in, inserters unload wagons, robots bring it to requester/storage chests, robots recharge and go to sleep, 10 seconds are enough, until next train comes.
This works so much better, because a roboport has a limited capacity of parked robots: when there is nothing to do, the robots go into the roboports, but when the next roboport is full, the robot has no other choice than to go to another, eventually much more distant roboport and recharge there. In that case it’s a linear distribution.