even faster conveyor ?

[Hellatze]

do dev plan a new and fastest conveyor.

T3 still quite slow for me.

[Koub]

No.
For faster conveying you yave :
- Bots over short distances.
- trains over long distances.

[quinor]

Or... 16-wide belt arrays if you wanna have FUN.

[mrvn]

No.
For faster conveying you yave :
- Bots over short distances.
- trains over long distances.

Are they actually faster / better throughput?

Consider the amount of space needed for all the roboports to recharge the bots and then consider what throughput multiple belts using the same amount of space would have.

As for trains I managed to put a one wagon train on a track every 76 ticks by using 16 stations in parallel and times signals. Adding the time overhead for loading and unloading you probably need 32 or 64 stations. The size of that would be huge but in between the end points you would have a single 2 m wide track. So distance would quickly make up for the stations. But hey, for me all that distance the train covers is usually empty. Who cares if you put 64 parallel belts there? Much less fun though. We use trains for fun, not for practicality.

[Koub]

I made a quick and (very) dirty test and was able to move items around 2.5 times faster with bots than with belts within a short-ish distance.
I attached my shameful test setup (it's not OCD compliant, from time to time, I could see one compression defect on the blue belt, but it was to make a magnitude test).

Test triggered by plonking a tier 3 pole on the right, and unplonking it when the robots finished their job.

Concerning trains, it's common sense : make a track long enough, your train will have the time to load, get from station to station and unload before the first items on the belt arrive to destination. Trains have insane throughput over long distances.

I know tests have been made, but I'm too lazy (and hungry ^^) to look for them now

[Hannu]

Who cares if you put 64 parallel belts there? Much less fun though.

My processor would certainly care, even it is relatively powerful (3770K). He would also think that this is not fun.

We use trains for fun, not for practicality.

You and I have quite different definition for practical if you think 64 wide belt bus is more practical to build and maintain than a double track. But it is true that there is not much more than fun reasons to build trains if you are going to just launch couple of rockets.

Bob's mods have faster belts (4 and 5 times yellow belt speed). Unfortunately, inserters (even Bob's superfast express inserters) are not able to release items fast enough to fill them and I have to use splitter tricks to get full benefits of speed. They are the most practical to transport large volume products, like components, in tight bases. It is not the best way to build factory but I like to make separate production cells and belts between them instead of chained assemblers.

Maybe the speed steps could increase exponentially, like 1,2 and 4 units (and 8 and maybe higher with mods). It could be reasonable because building of wider than 4 lines does not give much more than annoyance to game and belts are also significant load for CPU.

[mrvn]

I made a quick and (very) dirty test and was able to move items around 2.5 times faster with bots than with belts within a short-ish distance.
I attached my shameful test setup (it's not OCD compliant, from time to time, I could see one compression defect on the blue belt, but it was to make a magnitude test).

Test triggered by plonking a tier 3 pole on the right, and unplonking it when the robots finished their job.

How long did you run it? From my experience bots start of great with 1000 bots all carrying items. But after a while you have 1000 bots wanting to recharge at a roboport. The recharge rate is what limits bots and you need a fixed number of roboports per item and distance traveled. Not to mention the amount of resources that go into creating the bots and roboports and the energy needed to keep them flying.

Concerning trains, it's common sense : make a track long enough, your train will have the time to load, get from station to station and unload before the first items on the belt arrive to destination. Trains have insane throughput over long distances.

I know tests have been made, but I'm too lazy (and hungry ^^) to look for them now

You are talking about speed. Trains are really fast. But speed is generally unimportant. What is important is the bandwidth. The train might arrive before the first item on the belt arrives. But once they do arrive on the belt they just keep on coming. The train on the other hand has to go all the way back, reload, drive and unload. The bandwidth of ONE train actually decreases with distance. That's why you need multiple trains.

Loading and unloading is also a factor. A train stop can load/unload a car maybe every 8 seconds. That would limit the bandwidth to 250 coal/s or 2 blue belts. And a train track is 2 m wide and you need a double track. So for a single station belts are twice as fast. You need to do much better than 8 seconds to put a train on the track.

My test have shown that I can put one single car train on a single track every 76 ticks. That is 1579 ore, 3167 plates or 6315 electronic circuits per second. With belts that would be 40, 79 or 158 blue belts in parallel. The loading and unloading station required for this speed though are more than 400 m wide and more than 100 m long each. So for ore you need over 2000 m distance for trains to be better than ore belts. 1000 m for plates and 500 m for electronic circuits.

I haven't tested multi-car trains. They accelerate slower and at some point multiple engines makes sense. Since they are longer you have to space them further apart. But on the other hand you have less distance per car. So the number of cars per second should go up. And the length of the loading/unloading station only goes up by the length of a car train (plus 1 for the gap). Width might be more affected to get all the items in or out of the station.


Overall doing all this math makes me realize how much better it is to smelt in place. Transporting coal to the mine is basically free, the train has to go there anyway and you need very little. But transporting iron/copper plates back you get twice the amount per car due to the larger stack size. 4 times for iron gear wheels because they take 2 ores each. 10 times for electronic circuits, if you have a spot with iron and copper near each other. I really need to spread out my industry to refine goods from the outside in more.

[mrvn]

Hannu: Placing the 64 wide belt is not the problem. That's just a blueprint you put down and let the bots handle it.

But building the assemblers to consume 64 belts of something that is something. And you have to do that with trains to. You have to feed 64 belts into the train stations at one end and get 64 belts out of them at the other end. If you think about it then building the loading and unloading stations is actually harder than just putting in a 64 wide belt from A to B.

[Delwack]

The true advantage of trains and centralized smelting and production is quite simple, and has nothing at all to do with total bandwidth of train vs belt in a given space: trains are plug and play. One mine runs out? plug another one into the train network with minimal track and station laying (2 tracks, to and fro your new distance mines), and magically everything works.

You really want to run 64 (or how many ever) blue belts wide out every time you run a patch of ore out? Not to mention having to constantly balance the belt lines as mines and maintain saturation on all of them as individual miners in a patch run dry? No thanks. Good standardized loading train designs with smaller, simpler local belt balances solve a lot of these problems, makes the system plug and play, and allows better scaling without having to fiddle with the specifics of individual belts. You've sourced your load balancing and splitting in belt-design to your unloading station, and if you assume always full trains, there is no need to worry about maintaining or tweaking for a constantly shifting origin-point balance (Which would be the mines).

[Hannu]

Hannu: Placing the 64 wide belt is not the problem. That's just a blueprint you put down and let the bots handle it.

In my opinion it is a problem. If I build 2000 units long 64 wide belt, my bots have to place 128000 entities, which takes several hours. I have to also go to my base and take more belts tens of times and I need enormous assembly line to produce belts in sane time period. If I build normal 2 rails with power poles between 30 units and signals between 90 units, my robots have to place only 2112 entities, which takes few minutes and I can hold everything in my inventory.

I do not say that it is not possible, but it is far too laborious and impractical to be entertaining gaming for me (and I believe that for most of others too).

But building the assemblers to consume 64 belts of something that is something. And you have to do that with trains to. You have to feed 64 belts into the train stations at one end and get 64 belts out of them at the other end. If you think about it then building the loading and unloading stations is actually harder than just putting in a 64 wide belt from A to B.

It is relatively easy to get 2 belts from one car. It is certainly more easy to build for example 3 unload platforms for 16 wagon trains. By combining those 96 lines to 64 wide bus I could ensure that the bus would stay full during train changes and possible short delays in train traffic. Such stations would be huge but doable by copying smaller units by bots and would need only small fraction of entities needed in long 64 wide belt.

[Syrchalis]

I think all that's needed is roboport upgrade research.

Faster recharging and more recharge spots.

[Koub]

According to this topic on reddit you can get a throughput equivalent to that of 70 (for items that stack to 50) or 35 (for items that stack to 100) blue belts. On a single rail track. Only thing that needs space is making several train stops for the unloading.
And that was 6 months ago, so it was before the braking upgrades, that make your trains stop faster, so brake later.

You do have beter throughput with trains than with belts.

[Nich]

I am working on a prof of concept but using 4 LCCCC trains feeding 32 yellow belts and 800 logistics bots I have been able to support about 7-8 minute rockets (15 minutes while the mall is working) while doing infinite research. I vastly underestimated the steel requirements so I have to do a little revamping and will probably have to add a 5th train for just steel smelting but once I do I hope to get down to 5 minute rockets. Then I need to setup stone and coal to be supplied by train rather then belt and the entire thing will be tileable.

Basically copper flows in from the north and iron from the south. Then in the middle is a compact speed/prod bot based factory. It looks like things are randomly spread around but what I tried to do is minimize distances. So blue chips are surrounded by red and green. Red have green and copper dotted in between. Unfortunately science and rocket parts did not get as much consideration. If I break out the spreadsheets and reconfigure the layouts I could probably get it down to only 400 bots. Originally I wanted everything to flow from the south but I ran into the issue of surface area for train unloading

[iceman_1212]

For large bases (200k+ plate per min / 1.5k+ science per min), centralized smelting is impractical for similar reasons as a main bus, from a UPS standpoint. It results in a lot of inserters shuffling ore from chest to trains and vice versa. (Similar to how main bus results in a lot of belt entities.)

On-site production of green circuits and red circuits (with coal and petroleum transported to the latter) is extremely UPS friendly as mrvn mentions.

Construction bots benefit greatly from robot speed upgrades (much moreso than logistic bots imo) which makes it trivial to set up large outposts.

[mrvn]

Hannu: Placing the 64 wide belt is not the problem. That's just a blueprint you put down and let the bots handle it.

In my opinion it is a problem. If I build 2000 units long 64 wide belt, my bots have to place 128000 entities, which takes several hours. I have to also go to my base and take more belts tens of times and I need enormous assembly line to produce belts in sane time period. If I build normal 2 rails with power poles between 30 units and signals between 90 units, my robots have to place only 2112 entities, which takes few minutes and I can hold everything in my inventory.

I do not say that it is not possible, but it is far too laborious and impractical to be entertaining gaming for me (and I believe that for most of others too).

But building the assemblers to consume 64 belts of something that is something. And you have to do that with trains to. You have to feed 64 belts into the train stations at one end and get 64 belts out of them at the other end. If you think about it then building the loading and unloading stations is actually harder than just putting in a 64 wide belt from A to B.

It is relatively easy to get 2 belts from one car. It is certainly more easy to build for example 3 unload platforms for 16 wagon trains. By combining those 96 lines to 64 wide bus I could ensure that the bus would stay full during train changes and possible short delays in train traffic. Such stations would be huge but doable by copying smaller units by bots and would need only small fraction of entities needed in long 64 wide belt.

And you have the setup to smelt those 64 full belts and use all those iron or copper plates? A factory that consumes 64 full blue belts must be gigantic. How many rockets per minute would that equal?

[mrvn]

For large bases (200k+ plate per min / 1.5k+ science per min), centralized smelting is impractical for similar reasons as a main bus, from a UPS standpoint. It results in a lot of inserters shuffling ore from chest to trains and vice versa. (Similar to how main bus results in a lot of belt entities.)

On-site production of green circuits and red circuits (with coal and petroleum transported to the latter) is extremely UPS friendly as mrvn mentions.

Construction bots benefit greatly from robot speed upgrades (much moreso than logistic bots imo) which makes it trivial to set up large outposts.

I think so too. Even going the insane route of 64 parallel belts for an outpost, or 128000 belts as mentioned above, is not really a problem. In one larger game I had >8000 construction robots. So each robot has to place 16 belts. It would probably also help to put in a 65th belt, going the other way, and place belts, roboports, power poles, provider chests and inserters in it and make your blueprint so it places and fills a provider chests every now and then.

Or hey, build a train )))) to bring in supplies. Here's an idea for a mod: Passive provider train car.

[Hannu]

And you have the setup to smelt those 64 full belts and use all those iron or copper plates? A factory that consumes 64 full blue belts must be gigantic. How many rockets per minute would that equal?

No, I do not have. It was just an extreme example someone suggested. I have not build extreme megabases because I think that copying of endless rows of assemblers and miners are boring after some limit. My largest base used little more than 1M iron ore per hour and produced about 20 rockets per hour. I used modules but not beacons.

64 full blue belts could handle about 9M items per hour. It would be about 3 rockets per minute, if it was 64 belts for iron ore and corresponding (insane) amount of other resources in addition to that. It would need huge mines and oil fields too, if settings were even near normal. I think that my computer would not be able to handle it with tolerable UPS. I am not sure if any computer could handle such a massive belt based factory.

But you are right. Probably building of belts would be only small part of building the base which can use all that materials. But also in that almost impossible case trains were much easier to build and maintain in a long run and it would be better to distribute smelting and circuit production to smaller more manageable units (as I did in my large base save).