Belts instead of trains

[gr0mpel]

the modules and new assembling machines are a great feature.
however since the productivity increases dramatically (dont know if thats spelled correct), i often have the feeling that even the express belts are too slow and cant handle enough items to support a big factory.
for instance copper cable on one end. at the other we take adv. curcuit or better: modules. the amount of cables needed is so high, that even with 2 express belts and more, the throughput isnt enough to have 2 AM3 for every module (therefore 6 AM3) at the end producing constantly.

i think this would greatly improve if those stupid items would just flow undisturbed around the corners

[kovarex]

The solution is to make the factory more integrated. When you have row of assembling machines making cables, make the machines making circuits just next o it.

[gr0mpel]

thats a good answer, but to a false question
i try to make my factories modulated. that means i produce item a at position a, and transfer it via a main belt network where EVERY item runs through to position b, c and d where its needed.
i like this design very much because its expandable...to the point where adding more belts becomes difficult and annoying because they cant handle the huge output at the beginning ( 30 belts wide "transport lanes" are normal in my designs).

on the other hand: thats the fun about factorio that (i think) makes all of us play it hours and hours and hours

edit:
nevertheless i would love to see the items go around corners without deacceleration (would be awesome!)

[ssilk]

Edit: Some calculations where wrong, corrected.

Thats exactly the problems you get confronted:

1. solar vs. stying at coal.

Pro staying at coal only:
This is not so easy to answer. depends. For example: I tried this time not to use solar and came now to a point, where I got 20 steam engines (about 10 kW), I could need a bit more, but it handles that (about 50 mines, about 30 factories, no lasers). This doesn't need that much coal, about 1-2 coal per second or so. My coal field is only 3/4 empty after 12 hours, I don't use lasers, only guns. So AFAIK no problem.
When going to solar you need time to place all the stuff. I found out a layout with one energy station in the center placed in long lines is most efficient to place, but even with that it takes some time to produce the panels and some to place it and in this time, I surely extended my cheap and easy to install engines for another line with 8 engines. And you are not finished with that - you will need about the same amount of accumulators and still need backup power for the case, that everything goes wrong. And backup can only be done with steam-engines. So, you need steam engines, no matter what and the question is just: How much coal should they use. And don't forget about the amount of resources to built a solar panel and a an accumulator.

Pro switching to solar:
With solar energy you can completly forget about coal. No need any more. This spares diging for one resource, which is 1/3. It's easy to build it so big in one flow, that you never need more. You can switch off the steam engines with some simple tricks and then you don't need to think about energy problems any more. Simple. If you make it big enough, you can make it big enough to be sure that you don't need any steam engines. The devs said, the want to have the creepers going against air-pollution. Clean, green energy is made like that!

[currently I think a compromise between steam and solar is a very, very fine idea! There are 2 reasons: You will not Steam-power for everything which needs a constant flow of energy. Depends on your priorities. But for example: Smelting during the day looks for me like a very clever idea and I'll try that out! The problem, which I see here is, that it is difficult to keep the different electric networks separated. I also would say, that using a radar or the research, cries for soloar enegry and accumulators, because they need very constant power and you don't need to regulate this very much (just enough panels to get the accumulators loaded and just enough accumulators to come over the night).]


2. Trains vs Belts

Pro belt
Usable in an area of about up to 500 tiles. (500 is very, very far! to compare: radar is 100 tiles). More is of course possible, but it takes 4-5 minutes, till the first resources are transported to you then! Use the car for that! Belt is much cheaper, the basic belt is unbeatable. even if you use 2 in parallel, which have the best price performance ratio. And think to the complicated train-stations and signals you need to built when you want to have some performance. It takes an hour to built all that, so that it is working well. And you need so many inserters, chests, and other stuff and trains are volunerable, so you need to protect them in the station, which will cost extra time to built.

Pro train
Trains make sense from about 200 tiles upward. Every wagon can transport 960 items of ore. A basic belt can transport only about 700 per minute. This means, that if you manage to bring one train per minute to your main-station and it has 1 wagon you have a bit more transported, than the belt in the same time. Of course you can built faster belts, or more belts in parallel, but the cost will then be equal or higher to the train-track. And this is only for one wagon. 4 wagons are good to handle and with that, the throughput is 4 times more with the track, just by adding some wagons. The same is with more trains. And not to forget: trains are so much faster than belts, 500 tiles is just half a minute or so... so you see the stuff earlier. And the last reason is: Per tile about 6 items are "stored" on a belt, so with 500 tiles of length you have a storage of 3000 items - half a chest! This is much and you can't use it in this moment and it takes minutes, until you can use it. The train doesn't need so much storage, or in other words, the "blind-capacity" is much lower. (BTW: It can be really handled like the electrical capacity of a wire!)

....
I currently think, that even the default sandbox-game has so much resources nearby this 200-500 tiles around the starting-point area, that trains are not needed. Otherwise it is difficult and take much, much longer! But still possible. On low resources, you need very much time to fetch all resources and don't have a chance to go without train.

What's here needed is the certainty, that there are some big resources anywhere around you and about the direction you need to search them. A resource-radar? Or some other device which helps you to expand the map for resources in an diameter of 1000 tiles or more.

Only in this mode the train is needed then. I currently think, that after exploring the surroundings it makes sense to built a train-track into that area, where are much resource. Everything in that area is transported via belts to this outpost-station and from there transported to your base. Once you created that line, it's easy to extend it and I think trains for such a long distance make really fun! (I recommend really to build such a long track, you will hate it, but when it is ready, everything works as planned and you ride on it it it's really nice!)

Some things are also needed: Some "Blue prints" for stations (or a special buildings), because the micro-management of building and placing all that stuff (and not to forget to transport that from your base to the outpost) is really, really hard and I think this isn't much fun either. Also some help to built tracks (I hate to built 45 degrees tracks!), building and placing the wagons, the programming of them, the signals etc.

PS: The productivity modules are really great. I haven't much experienced that yet, but it looks like they change the balancing completely; what's before that was bad is now good and vice versa. I currently think it is hard to change the factory layout so that you change from a "belt-based production" to a "logistic-bots-production", because you need so much stuff to research for that and then you don't know where to put all the old stuff in (I really want something like a recycler). But this is part of the game. But the next factory I would built differently from beginning, to avoid the problems with changing the production-layout.

[ssilk]

on the other hand: thats the fun about factorio that (i think) makes all of us play it hours and hours and hours

Hehe. this is it!

And I don't want to be a teacher, but like to tell: What you tried, I already tried many times (see for example this: https://forums.factorio.com/forum/vie ... ?f=8&t=918 ) and I made other hard and much more complicated efforts to keep the stream of items fast and constant and I didn't found no other solution than:

1. Making assembly-streets. This is what Kovarex meant and it means, that you don't have here the electric-circuit-factory and there the copper-wire-factory. [This is because you make for example two copper-wires out of one copper plate. So the items are doubled. What you transport before at one belt needs now 2! This is the reason, why you can't transport it, even with express belts, because express belts are not double as fast as basic belts, see this: https://forums.factorio.com/forum/vie ... t=10#p8361 ]

Instead you have an integrated and about rightly weighted "sub-factory" to get one target-product. For example producing the smart-inserter needs:
- about 4 or much more electric circuit assemblies (which are always pairs of copper-wire -> electric circuit).
- one steel-wheel (one is more than enough, you might use that production also for one missiles-assembly or so)
- one of basic-, fast-, filter- and smart-inserter factory which will each forward the produced inserter to the next inserter-assembly.
The thing works even better, with some upgrades for the inserters, when they are able to move 2 items per time from assembly to assembly.

2. using logistic bots. Like here: https://forums.factorio.com/forum/vie ... 1205#p8434
This changes the game completly in a different direction.

3. Of course something between that works too. A rule of thumb is: The slower a product is built, the more useful is producing it in an assembly-street. Best example is production blue potions out of the four ingredients, which works even with basic belts for very, very much blue-potion assemblies.

And to make belts evenly fast in the edges: I think this not, because this is part of the physics-simulation in this game and I swear this is, what it make not just a simple game! Just this "simple edges" have much more "game" in it, than some other games I know. They are not simple, they are great, one of the smartest ideas in this game.

[Grey]

Hi there,

i also had this kind of discussion with one of my friends. Just want to present my information:

Pro Belt: cheap, easy, reliable... Once it is setup you have no problems, now power cost, no interruption by enemys.

Pro Train: capacity. Yes nothing more. Capacity is the only advantage as you can build trains with xx waggons and transport thousands of goods, but the drawbacks are numerous:

The most annoying is enemy interruption. If you have a decent rail system you have wait time at the junctions between your main-track and the smaller tracks to the resource deposits. While waiting there the trains are vulnerable to creepers and you will soon start to look if every train is running .. as you cannot build laser turrets beside the tracks. (Idle power usage is to much). So you have to secure every waiting spot and every station like fort knox to withstand a full creeper attack.

I think the time it is needed to build up the system should not be stated as disadvantage, because the whole game is about spending time with fun. Next drawback, you will be hit by your own trains. If your not cautious you will be crashed by the trains.

Coal cost: Your trains need coal to run, you need power for the hundreds of extra inserters and turrets. So the running cost of a train in multiple times higher that a belt, which has none.

So all in all: train is much cooler and makes a lot of fun to tweak for perfection, but realiability and economy of a belt is unbeatable.

I think some of the drawback could "easily" be disabled. For example you can enhance the station with a "repair arm" which repairs damaged trains and waggons. Trains could also just hit creepers like players(didnt recognised if they currently do), but stay moving. And trains have to be "non focused" by creepers or at least non moving trains are not interesting for them. As players dont want to look for their stuff every 5 min and find out that they have to setup a new train to a 5 min distance station.

if trains would be as reliable as a belt, the extra capacity is worth the running cost in my eyes. So maybe the devs will have a look for it.

[kovarex]

Hi, thank you for the nice sum up.

Trains kill enemies on the way and it is actually quite deadly weapon.
We plan to add something like turret wagon, that would defend the train (but not in this update for sure ^^)
The trains are not primary target for creepers anymore, but they still can attack it in some cases, in the future we plan to add some kind of repair robots that would solve the problem.

[Grey]

Glad to hear that. Sounds promising. I think gun waggons will need to be refilled with magazins. What about "electrified" track, engines and laserturrets?

[grimdanfango]

I wasn't simple! Hard work until I build a reliable test-track.

First results for the max throughput of belt-constellations follows. All tests have been done between 3 and 5 times. A systematic measurement-error cannot be excluded yet! All numbers in tiles per minute if not other said!


Simple straight belt

Basic: 716-719 (that's 11.93-11.98 tiles per second, which is nearly the theoretical maximum)
Fast: 1182-1184 (this is NOT double as fast as basic! it's only 1,65 times faster)
Express: 1774-1775 (this about 2.5 times faster than basic)

Belt with 4 bends (2 left, 2 right)

Basic: 477-486
Fast: 786-792
Express: 1038-1042

Belt with 4 bends (2 left, 2 right) and faster belt at the edges:

Basic with fast edge-belts: 674-683
Fast with express edge-belts: 1058-1061 (The fast belt with express edge seems to be faster, than pure express belt!)


Some more stuff:
- Splitters have sometimes problems! They are some times slower than the appropriate belt.
- It is really difficult to measure the express-belts, because the throughput is so high.
- side-inserts, even for some items only slow the speed definitely down.


TODO

- rework my testdrive, because it is hard to make so much measurements and wait all the time
- more systematic protocol of the measurements
- documentation of the test-track, so that everybody can repeat the measurements.
- Rework the above documentation (pics and new text)

PS: Does anybody have a good idea, how I can bring the train to run when a test is ready and a new train drives in? Like the smart ìnserter? I ask, because I haven't build much with tracks yet, but I found the wagons extremley practicable for counting the transported items, because I can fill it with 6 inserters at the same time, which is not possible for chests - and as you can imagine, it is hard to look into 16 chests and add the inserted number of items, and then you need to empty the chests before you can make a new test.

Hm. I would need smart chests, which can be used like a deterninistic finite automata. Would be really cool, but with red and green wire only not possible yet.

Since the wiki links to this post regarding throughput, I thought I'd share my more recent observations - I did an approximate test of Express belt throughput using 0.12.6 (splitting one fully-packed belt down 32-ways, then counting items over a minute using a stopwatch, then multiplying back up by 32x), and I noticed that with the updated belt physics, throughput pretty much perfectly matches the theoretical/"awaited throughput" values from the wiki now - there's no 26% loss in measured throughput any more.

[ssilk]

Nice.
I'm currently working on a new belt-test-track, that measures everything automatically and super-correctly (initializing, left/right belt handling, and enabling also other measurements like number of items on one track or timer for first item and such).

I'm hanging currently on the "simple" problem to correctly implement a state-engine (something that can be seen in every washing machine) and simple "timers" (start timer with a signal and after x ticks stops and gives another signal so that the state-engine can advance to the next step).

The whole circuits needs a lot of time for such "old people like me" to come into, aka learning curve is steep.

[bigyihsuan]

I expected from the title something about using belts to move resources around long distances instead of trains.

I am disappoint.

[ssilk]

You need to see it from the sight of 2 years ago. There the game had a different dimension.
If you want to read more about that subject, I recommend this: https://forums.factorio.com/wiki/inde ... ch_case%3F
But keep in mind, that with the update to 0.12 the belts gain a bit of throughput and are now much less complex.
The devs have on their agenda, to make the building of train-tracks a lot easier than now.

[Aru]

How is your belt throughput test setup coming? And how does it work? Whenever I try, the biggest problem is that the game stutters so frequently and so consistently (very, very annoying and persistent bug) that it messes up my measurements. The second biggest problem, is that the best way I have to transition from 100% compressed flow to 0% flow immediately, so that I can stop my timer, is to remove a belt segment, and that requires a small time delay that I have to approximate. But roughly, I just measured 4168 items in 110.98s on blue belt, which is ~37.556 items/second. (I'm assuming turns don't affect throughput anymore.) The real number is probably a little higher, because the game drops framerate very low for no reason every now and then. (Which, from reading other threads, has been an issue for a long time, but for some reason they never fixed it. I suspect, that the multiplayer issues are connected to this, but they manifest differently because while the clients also stutter, they don't drop frame rate. So zooming is smooth, unlike single player, but everything else still stutters. This implies that it is not a graphical problem, in part because servers don't need graphics.)

I am very interested in numbers like this, because I like to design optimized builds and ratios that revolve around throughputs of belts, inserters, assemblers, drills, furnaces, etc. I do a lot of calculating and optimizing.... So far, all my stuff has revolved around compressed yellow belts as my basic 'unit of throughput'. But I want to move up. And I don't want to invest heavily in designs until I can get really accurate measurements.

edit: It just occurred to me, maybe I can use circuits to measure the time, because they're supposed to recalculate 60 times per second. And if everything else in the game slows down during stutters, the circuit networks should too.

[Aru]

I did just that, I used the circuit network to measure time, to rule out interference of stutter and other such issues. Good thing, because I measured 264 seconds, while the circuit measured 241s.

So, my test counted 9688 items in 14460 game ticks, or 241.0 seconds exactly (by pure coincidence), which is about 40.19917012 items per game second. Test started and ended with two saturated lanes, neither one ahead of the other.

I think I can just say, I measured blue belt throughput as 40.2 items per second in version 0.12.30. Now, I want to use this same setup for the other belts, and the splitters...

edit: As to the second problem, stopping the test, I just did it manually, though I'm sure there's still a better way. I added and removed a belt tile to start/stop the flow, and started/stopped the circuit timer when the front/back of the item line appeared to hit a threshold between two particular belt tiles. The real-life timer was less precise, and started/stopped when the belt was placed/removed. With an error margin of 1/10s in either direction, throughput is 40.1825 - 40.2159 items/s.

My rough testing here, at least verifies that ssilk's old (and presumably far more accurate) measurement of 40.17375 items/s is still correct.