Is it possible to make a factory without belts?

[Redstone_Tesla]

On my map I have the idea of ​​a relatively large factory for military production. I decided to build almost without the use of belts. I have a conciderable amount of roboports scattered and more than 5000 logistical robots, with 3k to 4k in constant use.
The problem is that many are standing in queues to reload and this delays the delivery of resources. If the solution is more roboports then the whole plan seems to me unfeasible.

I want to know if it is really possible for a whole factory to run only with robots or if they should only be used in isolated situations (like unloading items from the train, or making items for my personal inventory). I think it's strange because I've already noticed discussions in this forum (FFF224 and FFF225) about whether it is true to have logistical robots in the game, as they "remove" the need for belts in late game.

So, is it possible? Is there any tutorial that I can inspire? I misunderstood the use of robots?

Note: Sorry if the text is not clear, I translated it in google.

[jcranmer]

You have too few roboports almost certainly.

I started collating numbers on the throughput of different systems. Robots are challenging because the throughput of robots are highly dependent on distance, and the distance is challenging to reason about when you have multiple sources and sinks in the same network. I also did the calculation assuming the robot had to travel no distance to reach a roboport, which is approximately true for the high-throughput train load/unload arrangement.

Without going into the math, a logistic's network capacity is basically determined by the fraction of the time a robot is spent carrying an item rather than charging or deadheading. Reducing charging time is possible by ensuring that there's sufficient charging spots, and that no robot is ever too far from a roboport. Reducing deadheading means either ensuring constant two-way traffic, or letting robots sleep near sources.

Robots are very efficient when you're in a high-throughput bridge system. A standard robot-driven train system is basically a train unloading into providers, a bank of roboports, and then the requester chests with minimal open space in between them. All isolated from any other network. You actually don't need that many robots: unloading a train station that can feed 25 blue belts of items requires just 500-600 robots in this dense kind of network. What you do need are roboports; for the numbers I chose, a roboport could support only about 75 robots, and you definitely want to err on the side of too many roboports. I would tend to go with about 50 robots per roboport.

I've not done the simulation to confirm this, but I suspect that the throughput of the logistics network crashes if you pass the threshold of too many robots. The intuition is that when a large supply comes in (i.e., a train), all the bots rush in to fulfill the requests and then get stuck in charging queues as they all run out of charge at the same time, instead of keeping a continuous belt of robots serving requests and keeping the charging spots full but without queues. Thus it's better to have slightly too few robots than slightly too many, which is contrary to the usual mindset of overprovisioning.

[Redstone_Tesla]

You have too few roboports almost certainly.

I started collating numbers on the throughput of different systems. Robots are challenging because the throughput of robots are highly dependent on distance, and the distance is challenging to reason about when you have multiple sources and sinks in the same network. I also did the calculation assuming the robot had to travel no distance to reach a roboport, which is approximately true for the high-throughput train load/unload arrangement.

Without going into the math, a logistic's network capacity is basically determined by the fraction of the time a robot is spent carrying an item rather than charging or deadheading. Reducing charging time is possible by ensuring that there's sufficient charging spots, and that no robot is ever too far from a roboport. Reducing deadheading means either ensuring constant two-way traffic, or letting robots sleep near sources.

Robots are very efficient when you're in a high-throughput bridge system. A standard robot-driven train system is basically a train unloading into providers, a bank of roboports, and then the requester chests with minimal open space in between them. All isolated from any other network. You actually don't need that many robots: unloading a train station that can feed 25 blue belts of items requires just 500-600 robots in this dense kind of network. What you do need are roboports; for the numbers I chose, a roboport could support only about 75 robots, and you definitely want to err on the side of too many roboports. I would tend to go with about 50 robots per roboport.

I've not done the simulation to confirm this, but I suspect that the throughput of the logistics network crashes if you pass the threshold of too many robots. The intuition is that when a large supply comes in (i.e., a train), all the bots rush in to fulfill the requests and then get stuck in charging queues as they all run out of charge at the same time, instead of keeping a continuous belt of robots serving requests and keeping the charging spots full but without queues. Thus it's better to have slightly too few robots than slightly too many, which is contrary to the usual mindset of overprovisioning.

I understand what you tell me and I get frustrated because I believe that more roboports in my current layout will be bad.

Claramento my main bottleneck is in iron and copper. I have increased the amount of roboports in these areas and it seems to have helped. The problem is that according to your calculation, I need 600 roboports (I have ~ 190).

I hope I'm not asking too much. But can you analyze my factory?
I'm attaching my salve. The factory in question is to the northeast of the larger factory.

If you can not or you do not want, that's okay.

[Redstone_Tesla]

Can not upload file through forum. I'm attaching it to the drive.

https://drive.google.com/file/d/1xMl4A0 ... sp=sharing

[Oktokolo]

If bots are too difficult, try doing train-based logistics only. It is possible - just a lot of handplaced (well, 0.17 will fix that) wagons and a shit-ton inserters...

[Redstone_Tesla]

If bots are too difficult, try doing train-based logistics only. It is possible - just a lot of handplaced (well, 0.17 will fix that) wagons and a shit-ton inserters...

I'm already using the trains to search for minerals and oil. The factory in question is too small to use trains. And I'm also finding the idea of robots an interesting challenge.

[quyxkh]

Belts are almost completely insensitive to distance and bots aren't, they don't do well as drop-in replacements. You can arrange your factory so all your deliveries are the kinds bots and trains are good at, then it'll do well with just bots and trains.

[jcranmer]

So your biggest problem here isn't a lack of roboports. It's that your roboports are poorly positioned. (Your estimate is also off by a factor of 10, you only need about 120 roboports to service 6k robots).

In your factory, essentially all the roboports are lined in a vertical line. However, your factory is arranged so that most robots have to travel vertically, which means they're not crossing the roboports to recharge. So despite having sufficient roboports, most of those roboports aren't providing effective charging. The robots delivering stone to the wall production have it the worst, since they fly over the entire oil production and only have one or two roboports waiting to refill them when they need it. There's also issue with the copper delivery to the circuits and ammo production: the bots aren't crossing over rows of roboports.

This is a build test I did of my robot unloading attachment:

20181101223717_1.jpg (800.94 KiB) Viewed 5755 times

That's the equivalent of 22 blue belts of ore being unloaded by 600 robots. (It's being unloaded onto 24 blue belts, but since this is supposed to feed 24 columns of productivity'd smelting, I don't need full belts.) If you look, you can see that a fair many of those robots are actually queued up for charging slots. But a) they're empty, so it doesn't matter and b) the slots are on their way to pick up more of them. No matter where the robots go, their path is covered by that solid line of roboports. This sort of design is why bots are considered so overpowered compared to belts.

What you want in your factory are lines like that (maybe not quite so densely packed, but again, better to be too dense than too sparse) that cross more or less perpendicularly to the lines of robot travel.

[Redstone_Tesla]

So your biggest problem here isn't a lack of roboports. It's that your roboports are poorly positioned. (Your estimate is also off by a factor of 10, you only need about 120 roboports to service 6k robots).

In your factory, essentially all the roboports are lined in a vertical line. However, your factory is arranged so that most robots have to travel vertically, which means they're not crossing the roboports to recharge. So despite having sufficient roboports, most of those roboports aren't providing effective charging. The robots delivering stone to the wall production have it the worst, since they fly over the entire oil production and only have one or two roboports waiting to refill them when they need it. There's also issue with the copper delivery to the circuits and ammo production: the bots aren't crossing over rows of roboports.

This is a build test I did of my robot unloading attachment:
20181101223717_1.jpg

That's the equivalent of 22 blue belts of ore being unloaded by 600 robots. (It's being unloaded onto 24 blue belts, but since this is supposed to feed 24 columns of productivity'd smelting, I don't need full belts.) If you look, you can see that a fair many of those robots are actually queued up for charging slots. But a) they're empty, so it doesn't matter and b) the slots are on their way to pick up more of them. No matter where the robots go, their path is covered by that solid line of roboports. This sort of design is why bots are considered so overpowered compared to belts.

What you want in your factory are lines like that (maybe not quite so densely packed, but again, better to be too dense than too sparse) that cross more or less perpendicularly to the lines of robot travel.

I understood. Thanks for the feedback!

I'll rethink my layout.

[Zavian]

If I am doing bot based production I typically design something like

BotBasedGreenCircuits.jpg (865.48 KiB) Viewed 5727 times

Note the short bot travel distances, and the plentiful roboports, the fact that bots can recharge near where they drop off and pick up items. This design can also be adapted for shorter trains, but if I was using shorter trains, then I would also reduce the number of green circuit assemblers as well. eg for 1-4 trains I would probably go with 20 copper wire assemblers and 20 green circuit assemblers. Also this logistic network should be separate from other logistic networks.

Keeping average bot travel distance as short as possible helps with throughput, as does letting bots charge near pickup and drop off locations. (Bot speed research, and bot carrying capacity research also helps).

I would never bother with using bots to unload onto belts. There are a lot of ways other ways of doing that. Here is a simple setup that scales to 32 blue belts.

32BeltUnload.jpg (869.49 KiB) Viewed 5727 times

[Redstone_Tesla]

If I am doing bot based production I typically design something like BotBasedGreenCircuits.jpg
Note the short bot travel distances, and the plentiful roboports, the fact that bots can recharge near where they drop off and pick up items. This design can also be adapted for shorter trains, but if I was using shorter trains, then I would also reduce the number of green circuit assemblers as well. eg for 1-4 trains I would probably go with 20 copper wire assemblers and 20 green circuit assemblers. Also this logistic network should be separate from other logistic networks.

Keeping average bot travel distance as short as possible helps with throughput, as does letting bots charge near pickup and drop off locations. (Bot speed research, and bot carrying capacity research also helps).

I would never bother with using bots to unload onto belts. There are a lot of ways other ways of doing that. Here is a simple setup that scales to 32 blue belts. 32BeltUnload.jpg

The problem is that my factory does not use train in this way (they only bring ore). I built a factory operated by robots, but with layout of "main-bus". Then the robot that take iron plate has to go through the entire factory to supply the manufacturers of ammunition, for example.

[Trebor]

Could you use buffer chests as waypoints for the bots to store their load?

[eradicator]

You can bridge two unconnected logistic networks with chests. Makes the flight times much shorter because the networks are smaller.

logibridge.png (92.6 KiB) Viewed 5655 times

[Redstone_Tesla]

Could you use buffer chests as waypoints for the bots to store their load?

I came to this thinking today and it is working.

You can bridge two unconnected logistic networks with chests. Makes the flight times much shorter because the networks are smaller

I also thought about that. I have to study my current layout.

[Oktokolo]

If bots are too difficult, try doing train-based logistics only. It is possible - just a lot of handplaced (well, 0.17 will fix that) wagons and a shit-ton inserters...

I'm already using the trains to search for minerals and oil. The factory in question is too small to use trains. And I'm also finding the idea of robots an interesting challenge.

I meant using trains only. No belts, no bots - just trains and wagons.

[Greybeard_LXI]

I meant using trains only. No belts, no bots - just trains and wagons.

Theoretically yes.

You start by running around like a maniac feeding stone furnaces and taking the copper/iron to assemblers to make components you can take to more assemblers so you can (repeat as necessary) carry them to research labs and research the three railroad techs. Oh, and don't forget to keep feeding the boilers.

As soon as you have the trains you can drive a train with iron plate to the gear wheel assembler and have the gear wheels put into a train on the other side. Then have the gear wheel train carry the wheels to the red science assembler for drop off. After the gear wheel train delivers the wheels have a copper plate train deliver copper. Then you can output the red packs to a train on the other side.

When the train with the red packs is full enough you can use another station to deliver all the science packs to the labs.

It could work, but that is going to require more trains and stations and scheduling than I think I could handle.

You will also have lots of problems with the raw ore. You can output the ore to boxes from each miner and then load to a train. That is no problem. The problem comes when some miners run out of ore first, slowing down production. Then you will have to rebuild the ore load station and tracks when all those miners are empty.

Good luck!

[dog80]

no in order to make a science-lab which is required to build a rocket you need belts cheers!

[Greybeard_LXI]

I think I misread the comment on using trains. I responded to one of the other people trying to help and not the OP.

Pure trains with no belts would be a monster. I tried setting up a small train based red science production. It was ugly. One thing I learned is that you can only put two factories or electric smelters for each cargo wagon. This would make things real tricky to balance (set up six stations for the plate train to allow loading more than 100 plate per trip ... Set up multiple delivery where the mining drills from one assembler (2 sec each) can be used by six blue science assemblers (12 sec each), or maybe one delivery using three cargo wagons from three underused mining drill assembler.)