Factorio Forums

TL;DR

Roboports should output more stats for its robot network to help optimize them

What ?

Roboports today output 4 variables: Total and available logistics bots + total and available construction bots

Pri 1 wish:
The roboport should also output:
- Total number of bots currently charging in the network
- Total number of bots waiting to charge in the network
Pri 2 wish:
- Split the totals above into construction and logistics bots
- Also add number of bots currently waiting to charge at the specific roboport split into construction bots and logistics bots

Why ?

When creating larger or busier networks it's easy to add too many bots to them compared to the number of roboports supporting them. With these outputs it would be possible to automate the balancing and the deployment of new bots to the network, or remove bots till the player is satisfied with the load on the available roboports.

I'm not sure the roboport is aware of the bot charging queue.

Koub wrote: Mon Dec 21, 2020 5:21 pm I'm not sure the roboport is aware of the bot charging queue.

It actually is aware, at least the LuaLogisticCell via the attributes and Not too sure how you would go about expanding the properties / signals as found int the LuaRoboportControlBehavior though.

Hi TyrHeimdal, my opinion is this: It is not super correct to say, that only with these numbers balancing would be possible (your WHY), because it depends on many more factors, if this will be possible.

W? It’s possible without any numbers, you can just multiply with the number of roboports times 50-70 for maximum number of bots per network. That’s of course a very rough estimate, but it works most of the time very well.

Following that rule of thumb, we need also the number of roboports in the signals.
But it’s useless, if you have added modded roboports. I like for example https://mods.factorio.com/mod/Robocharger and it adds 10 charge spots per port. So it would be also a good idea to have not only the number of roboports, but also the number of charge places. And how many of them are occupied. Makes IMHO better calculations possible, than with the number of charging bots.

There are other factors, like the total number of robot parking slots. That limits the total number of robots in a way, that it makes (normally) no sense to add more robots to a network, if they cannot park.

And so on, when I think about it I have much more ideas, what’s needed to calculate the perfect number of robots. But my opinion is: this changes, depending on too many factors, like the form of the network, or the average distance of roboports and so on and as long there is no nice way to remove bots from a network, or to tell bots this roboport should contain at least this minimum number of robots to guarantee a fast response, so long the current system is more than enough to have fun.
Aka: Yes, it could make things faster/easier/exact and there is a lot of possible /hidden gameplay, but it depends too much on other factors to make that reliable for any kind of robot network.

Btw.: This suggestion has also big brothers and small sisters:

viewtopic.php?f=6&t=39474 Roboports should output missing materials to circuit network

viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

W? It’s possible without any numbers, you can just multiply with the number of roboports times 50-70 for maximum number of bots per network. That’s of course a very rough estimate, but it works most of the time very well.

Weeell, yes and no.

You can calculate how many you CAN charge, but in a network, you could have bottlenecks. say you have different areas connected with a string of ports (or any other random reason for bottlenecks). Those would be bottlenecks and potentially have huge numbers of waiting bots. If I could connect an alarm to the waiting to charge number, I could more easily identify and add more ports at critical locations

Ah. I wrote now 5 sentences before I checked my fault: I thought you count the currently charging bots only for the short moment, when they are really charging. But this suggestion makes only sense, if you count them, if they are already on the way from the queue to the charge pods. Because when the bots are empty, they fly very slow and it can take several seconds before they are really charging, so it could happen that you have 100 bots waiting for charge, but non is charging. And you would divide through zero.

But when counting “charging” at the moment, when they are assigned for charging, this makes sense.