Factorio Forums

https://forums.factorio.com/wiki/index.ph ... ts/Physics - Wiki Page
https://www.youtube.com/watch?v=_pTsp2B ... be&t=4m39s - Youtube video with different interpretation and https://forums.factorio.com/forum/vie ... 21&p=56806 - related post regarding different interpretation

Factorio Version 0.11.22

Question - Is the throughput of material on transport belts still consistent with the results documented on the wiki page from version 0.6?

Hypothesis - The throughput for the STD, FAST and XPRESS belts remain approximately 12, 20 and 30. The throughput can be determined by multiplying density with velocity.

Test - (for density only) count the number of items that exist on a fully compressed moving belt for a given length. Note - result chests are to the right. Do not count the items from the chests to the left. errors - there is a small leak of items from both sets of inserters. Although they counter each other, the amount of leakage from each set may not be the same.
- the 2 fast belts are mostly compressed but are not fully compressed since I used direct insertion to fill them. Although not apparent, the test belt may have had some small gaps in the item count.

Results -
Straight Dynamic
STD - Test 1 = 192 items, Test 2 = 192 items - 3.2 items per tile per side
FAST - Test 1 = 160 items, Test 2 = 160 items = 2.7 items per tile per side
XPRESS - Test 1 = 160 items, Test 2 = 160 items = 2.7 items per tile per side

Curve Dynamic
STD - 129 items - 2.2 items per tile per side
FAST - 120 items - 2 items per tile per side
XPRESS - 118 items - 2.0 items per tile per side

Interpretation
Using previously determined velocities of STD = 1.875 tiles/sec, FAST = 3.75 tiles/sec and XPRESS = 5.625 tiles/sec, we get the following throughputs:
STD throughput = 3.2 items/tile x 1.875 tiles/sec = 6 items/sec (same as previous)
FAST throughput = 2.7 items/tile x 3.75 tiles/sec = 10.1 items/sec (about the same)
XPRESS throughput = 2.7 items/tile x 5.625 tiles/sec = 15.2 items/sec (about the same)
CONCLUSION - Throughputs remain the same

Further thoughts
Since we are talking about computer basics, I expect to find integers as the foundation for this information. Consider the following:
1 Tile = 32 Pixels (I use pixel loosely here but it makes the most sense)
1 Second = 60 Ticks

STD Density = 3.2 items/tile x 1 tile/32 pixels = 0.1 items/pixel or 10 pixels/item (15 pixels/item after inside curves)
FAST Density and XPRESS density = 2.7 items/tile x 1 tile/32 pixels = 0.084 or 12 pixels/item

STD Velocity = 1.875 tiles/sec x 32 pixels/1 tile x 1 second/60 ticks = 1 pixel/tick
FAST velocity = 2 pixels/tick
XPRESS velocity = 3 pixels/tick

Using these densities and velocities we get
STD throughput = 1/10 items/pixel x 1 pixel/tick = 1/10 items/tick = 6 items per second
FAST throughput = 1/12 items/pixel x 2 pixels/tick = 1/6 items/tick = 10 items per second
XPRESS throughput = 1/12 items/pixel x 3 pixels/tick = 1/4 items/tick = 15 items per second

The standing density for the STD and XPRESS belts is 1/9 items/pixel (for some reason the FAST belt's standing density is 1/10 ?? - probably for optimizing but I don't like it)

Further tests are needed to corroborate the above as well as tests for checking velocities.

It will change in 0.12, where the movement on transport belts had been rewritten.

The curves don't slow things down. The movement is more smooth, so the ratios should get closer to 1:2:3

kovarex wrote:It will change in 0.12, where the movement on transport belts had been rewritten.

The curves don't slow things down. The movement is more smooth, so the ratios should get closer to 1:2:3

Nice to hear...

The tiles/sec values are going to stay the same? Basic=1.875, Fast=3.75, Express=5.625?

Would pretty much mean that the throughput would then be 12 Items/Sec, about 24 Items/Sec and almost 36 Items/Sec. That would be actually a vast improvement for Express Belts.

But even if the ratio would hold up to 1:2:3 I'll be still glad once the corners don't slow anything down anymore. I see myself running through the factories tearing down all the Corner-Splitters. xD

DerivePi wrote:https://forums.factorio.com/wiki/index.ph ... ts/Physics - Wiki Page
https://www.youtube.com/watch?v=_pTsp2B ... be&t=4m39s - Youtube video with different interpretation and https://forums.factorio.com/forum/vie ... 21&p=56806 - related post regarding different interpretation

Factorio Version 0.11.22

Question - Is the throughput of material on transport belts still consistent with the results documented on the wiki page from version 0.6?

Hypothesis - The throughput for the STD, FAST and XPRESS belts remain approximately 12, 20 and 30. The throughput can be determined by multiplying density with velocity.

Test - (for density only) count the number of items that exist on a fully compressed moving belt for a given length. Note - result chests are to the right. Do not count the items from the chests to the left.

BELT DENSITY TEST.gif

errors - there is a small leak of items from both sets of inserters. Although they counter each other, the amount of leakage from each set may not be the same.
- the 2 fast belts are mostly compressed but are not fully compressed since I used direct insertion to fill them. Although not apparent, the test belt may have had some small gaps in the item count.

Results -
Straight Dynamic
STD - Test 1 = 192 items, Test 2 = 192 items - 3.2 items per tile per side
FAST - Test 1 = 160 items, Test 2 = 160 items = 2.7 items per tile per side
XPRESS - Test 1 = 160 items, Test 2 = 160 items = 2.7 items per tile per side

Curve Dynamic
STD - 129 items - 2.2 items per tile per side
FAST - 120 items - 2 items per tile per side
XPRESS - 118 items - 2.0 items per tile per side

Interpretation
Using previously determined velocities of STD = 1.875 tiles/sec, FAST = 3.75 tiles/sec and XPRESS = 5.625 tiles/sec, we get the following throughputs:
STD throughput = 3.2 items/tile x 1.875 tiles/sec = 6 items/sec (same as previous)
FAST throughput = 2.7 items/tile x 3.75 tiles/sec = 10.1 items/sec (about the same)
XPRESS throughput = 2.7 items/tile x 5.625 tiles/sec = 15.2 items/sec (about the same)
CONCLUSION - Throughputs remain the same

Further thoughts
Since we are talking about computer basics, I expect to find integers as the foundation for this information. Consider the following:
1 Tile = 32 Pixels (I use pixel loosely here but it makes the most sense)
1 Second = 60 Ticks

STD Density = 3.2 items/tile x 1 tile/32 pixels = 0.1 items/pixel or 10 pixels/item (15 pixels/item after inside curves)
FAST Density and XPRESS density = 2.7 items/tile x 1 tile/32 pixels = 0.084 or 12 pixels/item

STD Velocity = 1.875 tiles/sec x 32 pixels/1 tile x 1 second/60 ticks = 1 pixel/tick
FAST velocity = 2 pixels/tick
XPRESS velocity = 3 pixels/tick

Using these densities and velocities we get
STD throughput = 1/10 items/pixel x 1 pixel/tick = 1/10 items/tick = 6 items per second
FAST throughput = 1/12 items/pixel x 2 pixels/tick = 1/6 items/tick = 10 items per second
XPRESS throughput = 1/12 items/pixel x 3 pixels/tick = 1/4 items/tick = 15 items per second

The standing density for the STD and XPRESS belts is 1/9 items/pixel (for some reason the FAST belt's standing density is 1/10 ?? - probably for optimizing but I don't like it)

Further tests are needed to corroborate the above as well as tests for checking velocities.

Maybe there are different questions being answered.

Are you able to get 2.7 items per tile while the items on the belt are in motion and have been the entire time?

The screenshot in the clip indicates express belts under those conditions have 2.3 items per tile not 2.7:
https://youtu.be/_pTsp2Bs-HQ?t=3m37s

I see your schematic shot in the first post, but do you have an in-game shot of express belts maintaining 2.7 items per tile?

Maybe with splitters and multiple source lines you can load the belt higher to 2.7? or record a higher density from starting from a stopped/compressed backlog?

I know an express belt saturates after 16 fast inserters, but even at 16 there are hitches where they can't place their item and must wait -- do these hitches accumulate to reduce the density to 2.3?

Maybe it is all moot with .12 changes.

kovarex wrote:The curves don't slow things down. The movement is more smooth, so the ratios should get closer to 1:2:3

Curves won't slow things down anymore? That seems like a very fundamental principal that will be removed. I'm not saying I'm disliking it. It just seems weird after I spend so much time avoiding curves and reinforcing corners.

I'm also still splitted. But the current way to move the items has some flaws: Stucked items, questionable game value of the curves, switching the belt types while building, only for speed reasons, players have problems to see, what the bottleneck really is and much more of those things.
And in the end it is so: It is much easier to speed up the curves, so that they work similar to everything else, AND THEN slow them to achieve the same behavior as before. But I'm sure, this will never happen.

If you want slow curves, you can put a yellow conveyor belt on an otherwise fast conveyor, to remind you of good old times

Yes!! now I understand how this mod becomes much more useful: https://forums.factorio.com/forum/vie ... 14&t=12177

qfeys wrote:

kovarex wrote:The curves don't slow things down. The movement is more smooth, so the ratios should get closer to 1:2:3

Curves won't slow things down anymore? That seems like a very fundamental principal that will be removed. I'm not saying I'm disliking it. It just seems weird after I spend so much time avoiding curves and reinforcing corners.

You mean a fundamental issue that will be fixed?

In order to have a 1:2:3 ratio of throughput for belts you need to have a constant density with the current velocities (1, 2 and 3 pixels per tick respectively) or vary the speed and densities to fit. Since we already have the simple 1, 2 and 3 velocities, I'm hoping that they will just adjust the densities to be constant. Further, I propose that the densities should be fixed at 12 pixels per item. This is the 9 pixels for the at rest bounding box for each item plus a gap of 3 pixels. For the XPRESS belt, this is simple - When there is a gap between items on an XPRESS belt, on the next tick the next item fills in that gap up to 3 ticks away. However, for the FAST and STD belts, additional rules are required. I would think those rules will be something like:

STD Belt - When gap is 3 or greater, item will move at 1 p/t on next tick. When gap is less than 3, item will only move 1 p after even numbered ticks.
FAST Belt - When gap is 3 or greater, item will move at 2 p/t on next tick. When gap is less than 3, item will move 1 p on next tick.
XPRESS Belt - When gap is 3 or greater, item will move at 3 p/t on next tick. When gap is less than 3, item will move the gap length on next tick.

With these densities and velocities, the max throughput will be 10, 20 and 30 respectively.

For the curves, the outer items will need to move 3 times as fast. To simplify, the outer and inner curves should have 12 locations (2 x PI x r / 4, where r = 8 pixels for the inside radius) for each item to path on The items can then follow the same rules as before, just on the curve.

Just thinking out loud.