dron charging

[zggz]

1. We need optimal route. Look at the 2-nd screen pls. They wait time for charging when a lot of free roboports near.
2. 4x1MW too low. We need 3-4 times more effective. May be more slots or more fast charging..
3. Now dron factory looks like in my screen. 2k drons work and 2k wait for charge.

P.S. Drons when waiting for charging take fps. 19 fps is not good in 2018 year.

[Engimage]

1. Bots already have optimal routes. By optimal I mean the easiest to calculate and maintain during flight. This might not look optimal from your visual perspective but making bots more "smart" will definitely increase CPU usage and will make your UPS even worse.
2. If you want more charge there is a mod to research bot battery capacity by Klonan https://mods.factorio.com/mods/Klonan/R ... y_Research
3. It is your personal choice to use 2k bots on your screen. Try to add more things like direct feed or belts to make bot density acceptable. In your case transporting copper wires by bots is a culprit. Make them direct feed between assemblers and you will cut bot usage in half for your setup.

[zggz]

1. Bots already have optimal routes. By optimal I mean the easiest to calculate and maintain during flight. This might not look optimal from your visual perspective but making bots more "smart" will definitely increase CPU usage and will make your UPS even worse.
2. If you want more charge there is a mod to research bot battery capacity by Klonan https://mods.factorio.com/mods/Klonan/R ... y_Research
3. It is your personal choice to use 2k bots on your screen. Try to add more things like direct feed or belts to make bot density acceptable. In your case transporting copper wires by bots is a culprit. Make them direct feed between assemblers and you will cut bot usage in half for your setup.

1. Look at the screen. 1-8-200 drons... if you think thats optimal - go away from this planet.
Now they go to the nearest roboport. If they will take random roboport in coverage area - thats will be good with out additional load for cpu.
2. Thank you, i will try it. But i want to make factorio better and for this we need to make some changes in base mod.
3. Belt based base uses 2 times more fps at the same workload.

[BenSeidel]

It's not an issue with the mechanics but with your expectation of the mechanics.

Bot density follows the squared-cubed law. When you increase the size of a build (in the horizontal to begin with for simplicity) you not only increase the distance the bots have to fly but also the number of goods output by your factory. So, lets say you increase the width of your build by 20%. This means your bots now have to fly 2*20% further (there & back) AND you have 20% more items being requested & produced. This means that your net overall increase of bots-in-the-air is
original_count * (1 + 2*0.2) * (1+0.2).
or, more generally (I% is increase)
original_count * (3I + 2*I^2)

The important part is the I^2. This shows that if you double the width of your build you will need over 4x the number of bots.

If you do the maths for an increase in both width and height (it's more complected as you also have Pythagoreans theorem in there as well as some probability to get the expected distance each bot will travel), but you still get something whos most dominant term is an I^3.

With this idea, lets look at your issue.
YES, you have unused roboports that are right next to used ones. BUT you will always get this. If the dev's "fixed" it for this size, then when you double the build size you would see it again but more so as you would expect to utilise not three layers of roboports, but 4 or 5 or 6. At what point does the issue then become "My bots run out of change even before they get to my build. Why can't I have more than 30 layers of roboports".

Another aspect your observation is that the distance the bots will travel to get to a roboport with a smaller queue is based upon their empty travel speed, not their powered speed. This always means that the first layer will always be over-saturated before the second layer ever gets a single bot. Otherwise you would have bots traveling to the second layer even when they would be unable to reach the empty roboport before the first target had an empty charging queue.

If you can come up with a system that works in all situations for bot charging, such that it correctly deals with the cubing of bot quantities when at best you can only get a squared increase in numbers of roboports then that could be something that the developers could implement. Otherwise it's just a case that your bot based builds are too large. Bots are for short range/low quantity throughput for the above reasons. This build is showing you the upper range of that limit.

Edit:
Your statement that belt based builds takes twice the UPS is incorrect. Belts scale linearly while bots (as above) scale quadratically. Your statement of twice as much is only valid for a single size build. In all other cases one build will be more optimal than another build.

[zggz]

Thank you for yours post.

With this idea, lets look at your issue.
YES, you have unused roboports that are right next to used ones. BUT you will always get this. If the dev's "fixed" it for this size, then when you double the build size you would see it again but more so as you would expect to utilise not three layers of roboports, but 4 or 5 or 6. At what point does the issue then become "My bots run out of change even before they get to my build. Why can't I have more than 30 layers of roboports".

Thats depends of how this problem was fixed. In any case this don't work now even at the smallest design.

Another aspect your observation is that the distance the bots will travel to get to a roboport with a smaller queue is based upon their empty travel speed, not their powered speed. This always means that the first layer will always be over-saturated before the second layer ever gets a single bot. Otherwise you would have bots traveling to the second layer even when they would be unable to reach the empty roboport before the first target had an empty charging queue.

Bots going for charge at 300Mj energy. It's enought for travel between 3 roboports (at max distance). Any level available in this case.

If you can come up with a system that works in all situations for bot charging, such that it correctly deals with the cubing of bot quantities when at best you can only get a squared increase in numbers of roboports then that could be something that the developers could implement.

Easy: When time to charge coming bots must choose random roboport in radius (like 2 max distance between roboports) and in the same logic network. Now they take nearest.

Otherwise it's just a case that your bot based builds are too large. Bots are for short range/low quantity throughput for the above reasons. This build is showing you the upper range of that limit.

You are right. This design too big for this level of game mecanics. We need to change macanics because of this desing already really small. Just a train 3-5 side.

[Zavian]

Thank you for yours post.

If you can come up with a system that works in all situations for bot charging, such that it correctly deals with the cubing of bot quantities when at best you can only get a squared increase in numbers of roboports then that could be something that the developers could implement.

Easy: When time to charge coming bots must choose random roboport in radius (like 2 max distance between roboports) and in the same logic network. Now they take nearest.

But if you use a design like this, nearest is what you want.

27.9k Green Circuits per minute using about 650 bots. No charging issues.

BotBasedGreenCircuits.png (2.83 MiB) Viewed 2781 times

This design too big for this level of game mecanics. We need to change macanics because of this desing already really small. Just a train 3-5 side.

Or design something that works well with the existing mechanics?

[Engimage]

This design too big for this level of game mecanics. We need to change macanics because of this desing already really small. Just a train 3-5 side.

Or design something that works well with the existing mechanics?

^^ This is a great example of what I refered to. Copper wires are not transported by bots and use direct feed. Bot routes are optimized to be the shortest and always cross roboports.
You can just think and adopt to game mechanics other than trying to make game fit your vision of how it should work.