Belt Corner Speed or .12 got it wrong

[Shokubai]

I've been giving some thought to this recently and I feel I am at odds with the mechanics of the game. Now before you turn on the flames...Hear me out.

Current Mechanic
Factorio treats belt speed as a function of how far an item travels. Items travel at a constant speed depending on the belt type they are on and do no speed up (or slow down) around corners. The best real world example of this mechanic would be a roller style belt like this.
.
Because of the constant speed of the rollers and difference in distance between the inner and outer corners items on the inside would indeed travel faster than items on the outside. It's simply a shorter path at a constant speed. A good real world reference would be running track. At the same speed, the guy on the inside has an advantage due to having a shorter distance vs a runner of similar speed. Ever wonder why they don't start in a line for longer sprints? And remember the track isn't moving...just the runner.

Implied Mechanic
I call this Implied mechanic because of the visuals implied by the graphics in the game. The look of the belts imply a chain like system where each segment is pulled along by the one in front of it. Items do not MOVE on the belt they simply ride on top of it. In the image below that is a reasonable reference for a Factorio belt...Do you think an item on any segment of that chain would reach its destination any faster or slower based on which side it's on?

The obvious answer is no. Items on the inside would actually slow down due to compression while items on the outside would move FASTER due to centrifugal force. Items would enter and leave the corner at exactly the same time. No compression loss and no difference over a strait belt. This is no different than measuring the swing speed of a baseball bat or golf club. The speed at the end of the bat/club will be greater than the speed of your shoulders due to the greater distance traveled in the same amount of time.

Maybe I'm crazy...No wait...Right or wrong I'm probably still crazy but if you are still not convinced that the current game mechanics are simply wrong(at least based on the current belt graphics) enjoy some cookies on a conveyor going around corners.
https://youtu.be/fd4iWWAVbMo?t=1m34s
or if you prefer Dem Shoes Do.
https://www.youtube.com/watch?v=sh20T7bWlXQ

[Koub]

In fact what you're suggesting is to revert to the original mechanism of Factorio. An original mechanism that was indeed more realistic but was abandonned, iirc, because :
- It was unanimously (or close to) wanted by the community
- It allowed some performance optimization for belts, giving back tens of ups on megafactories.

If you search older design posts, you'll find a ton of designs with "no compression loss" turns, based on splitters. At that time, every time you had a belt, you had to make the turns be the upper tier of belts to keep compression - and throughput.

It was a huge headache, and I'm so happy realism has lost against gameplay value this time.

[Shokubai]

*EDIT* See my next posts for clarification between the .11 and .12 belts and what I'm suggesting.

At that time, every time you had a belt, you had to make the turns be the upper tier of belts to keep compression - and throughput.

THIS is the current mechanic. I am not sure exactly what you are saying since this agrees with my post that without putting fast corners on a belt you have compression loss.

- It allowed some performance optimization for belts, giving back tens of ups on megafactories.

I think you have mistaken my post. What I suggest is to KEEP compression across the length of the belt regardless of turns. We are talking about a gain of ups for any belt with any number of turns as outside corners would not decompress.

If you search older design posts, you'll find a ton of designs with "no compression loss" turns, based on splitters.

I can imagine this would be a headache but IS THE CURRENT GAME MECHANIC as compression is lost on corners.
I give you bullets on a belt loosing compression in .12.



I feel you failed to read or I fail to understand what you are trying to say.

[Shokubai]

I decided to dig in a bit deeper and it sounds as if maybe we are both right a little. Ill explain.
What I am referring to as compression is really about speed loss for the outer turn of an item on belt. Bad terminology maybe on my part but my point stands. In this videp https://youtu.be/_pTsp2Bs-HQ?t=9m28s from .11 there is an excellent explanation of how density is being lost on corners. The funny thing is that this actually looks more visually correct with the exception of items coming out with slight spacing after the turn. This BUG was indeed fixed in .12 but I believe it was fixed in the most economical way(meaning cpu clock cycles) without regard for realism. My Suggestion is definitely not to revert this change but instead to fix the fix.

Here is a simple graphic I had my 4 year old make (OK it was me) that explains then and now.
Here is the old system. Items were simply not transferred around the corner accurately creating spacing.


Here is the .12 system which does help with compression over the old version but at the cost of the outer corner keeping up with the inner.


My idea is simply this...All items come out of the corner compressed and AT THE SAME TIME REGARDLESS of side of the belt. This should give the IDENTICAL throughput of a strait belt.



A linked belt system at a constant speed should maintain the same density throughout it's entire length regardless of corners. Now, whats the cost in performance to create this? I'm not sure but the level of realism as well as SIMPLER belt logic within your factory has to account for something.

[daniel34]

Note: This post was largely made before Shokubai made the post with the nice white/red drawings.

You have a different understanding of the word compression than we (Factorio players) do.

From the gif in your previous post I gather that for you compression means items on both sides of the belt stay next to each other after taking a turn and no side falls behind.
For us, compression means that the belt is completely saturated and transports items at the highest possible throughput (fully compressed belt).

In Factorio 0.11 items lost compression at corners, which was changed for Factorio 0.12.

Factorio 0.11 (compression loss at the corner):

belt-0.11.gif (2.64 MiB) Viewed 13040 times

Factorio 0.12 (belt stays fully compressed):

belt-0.12.gif (1.67 MiB) Viewed 13040 times

In 0.11 the items on a belt were actual entities in the world, and had to be checked for collisions at each corner which took a lot of performance. Now in 0.12 the belts are split into two lines with virtual items that do not directly interfere with other entities/items unless required to do so (e.g. inserters), which doesn't require collision checks.
More information: Friday Facts #82 - Optimisations (scroll down)

The reason why items on the inner side of the corner are faster than on the outer side is that the way is shorter, and the belt line doesn't know/care internally if it is at a corner or not (imagine the belt was rolled out to a straight line, the inner line would be shorter).

[Shokubai]

Bad terminology gets ya every time.

[daniel34]

I see what you mean, but I think the current state in 0.12 would more accurately look like this:

Belts-02-new.png (30.05 KiB) Viewed 13024 times

The reason this problem occurs is that the items travelling on the outer side have a longer way, that's why the items "misalign" after the corner.

You'd need to slow down the items on the inside or speed up the ones on the outside (or some of both, so it is less noticeable) to get to your desired outcome (both items staying next to each other).

I think from a graphical standpoint the current implementation makes a lot of sense and would look weird when done otherwise. Besides it looking odd to you how the mechanic currently is, do you have any gameplay reason to change it?
In reference to the youtube videos you linked: In Factorio the belts move a lot faster, so the effect would be a lot more noticeable.

[Shokubai]

In reference to the youtube videos you linked: In Factorio the belts move a lot faster, so the effect would be a lot more noticeable.

The only thing wrong with this is that the items themselves have no speed and are stationary on a belt . You could draw a horizontal line at any point on that belt and it would ALWAYS ALWAYS ALWAYS complete the corner strait. Hell...Watch the arrows...They complete the corner the way the items on top of them should.

do you have any gameplay reason to change it?

I feel there should be no difference between the throughput of a curved and strait belt based on current graphics.

Here is a real world example of how I feel it should work. No speed loss, no compression loss.

https://youtu.be/7CGNVI5DSjY?t=41s

[Blurb]

I feel there should be no difference between the throughput of a curved and strait belt based on current graphics.

Here is a real world example of how I feel it should work. No speed loss, no compression loss.

That is the current state of the game.
Firsly, the throughput of a Factorio belt is unaffected by the amount of turns present.
For a circle belt, the outer lane poses a longer distance to travel, but travel time here is longer exactly because there is no change in speed.
Because speed stays constant, no compression loss occurs.

It might make more sense to you, if you were to consider each belt lane independent of the other.

[Kewlhotrod]

It was a huge headache, and I'm so happy realism has lost against gameplay value this time.

[againey]

I think what Shokubai essentially wants is that items on the inside turn do slow down as they used to do, but that they ignore collisions with each other and are therefore allowed to overlap while going around the tight turn, so that when they emerge out of the turn, they're still at the exact same compression as when then entered the turn, and they're still aligned with the items on the outer side of the belt.

It swaps out one unrealistic behavior (inner and outer turns moving items at same speed) for another (items can become packed more densely than is realistic while they're going around a turn), and increases gameplay value (no obnoxious decompression, no obnoxious misalignment between the two belt sides). The previous change in contrast went from realistic behavior to unrealistic behavior, and gained one gameplay value (no obnoxious decompression) at the loss of another (belt sides lose alignment with each other).

If their existence and collision has been abstracted away while they're on the belt, then I would image this wouldn't be too hard to enable for basic cases, while not impacting the performance gain at all (as it in fact takes advantage of that change).

Alternatively, instead of slowing down the inner turn and allowing momentary overlap, one could set the inner turn's speed just high enough so that compression wouldn't be lost, and then scale up the outer turn's speed to keep items lined up on both sides of the belt. But that might result in unrealistically high speeds that look odd even if it behaves just fine mechanically.

[Shokubai]

againey thank you for the nice sum up. Graphically I agree it poses a challenge. The reality is the real world you would have a corner more like train tracks in Factorio (Sweeping) and not a 90% belt but nobody here wants that.

I feel there should be no difference between the throughput of a curved and strait belt based on current graphics.

Here is a real world example of how I feel it should work. No speed loss, no compression loss.

That is the current state of the game.
Firsly, the throughput of a Factorio belt is unaffected by the amount of turns present.
For a circle belt, the outer lane poses a longer distance to travel, but travel time here is longer exactly because there is no change in speed.
Because speed stays constant, no compression loss occurs.

It might make more sense to you, if you were to consider each belt lane independent of the other.

Actually, Lets imagine a scenario where we want some number of units...say 100, as fast as a belt can deliver them. We will pretend that those 100 items exist in a nice even two lane row on a strait peice of belt somewhere. Path one is a belt of some length with a left turn somewhere in the middle. Path 2 is a belt of the same length but is strait.

Now since the belts are the same speed and length and we are assuming the destination can absorb the items as fast as they arrive, lets play this out.

Path One.
Because of the speed loss on the outside of the single turn the inner lane will arrive first with one item followed by 98 items simultaneously (in 2s) followed by one item from the outside lane due to slow down. If we think of this in delivery ticks it took 1 + 49(2s) + 1 = 51 ticks to receive all items.

Path Two
Since the path is strait no speed is changed for any item. Items are absorbed in 2s taking exactly 50 ticks to complete.

In the REAL WORLD that longer distance is traveled at a faster speed due to the physics of sitting still on a moving object and arrives at its destination at the same time as the inside item.

Now I'm no math wiz but 50 is less than 51.

[Peppe]

againey thank you for the nice sum up. Graphically I agree it poses a challenge. The reality is the real world you would have a corner more like train tracks in Factorio (Sweeping) and not a 90% belt but nobody here wants that.

I feel there should be no difference between the throughput of a curved and strait belt based on current graphics.

Here is a real world example of how I feel it should work. No speed loss, no compression loss.

That is the current state of the game.
Firsly, the throughput of a Factorio belt is unaffected by the amount of turns present.
For a circle belt, the outer lane poses a longer distance to travel, but travel time here is longer exactly because there is no change in speed.
Because speed stays constant, no compression loss occurs.

It might make more sense to you, if you were to consider each belt lane independent of the other.

Actually, Lets imagine a scenario where we want some number of units...say 100, as fast as a belt can deliver them. We will pretend that those 100 items exist in a nice even two lane row on a strait peice of belt somewhere. Path one is a belt of some length with a left turn somewhere in the middle. Path 2 is a belt of the same length but is strait.

Now since the belts are the same speed and length and we are assuming the destination can absorb the items as fast as they arrive, lets play this out.

Path One.
Because of the speed loss on the outside of the single turn the inner lane will arrive first with one item followed by 98 items simultaneously (in 2s) followed by one item from the outside lane due to slow down. If we think of this in delivery ticks it took 1 + 49(2s) + 1 = 51 ticks to receive all items.

Path Two
Since the path is strait no speed is changed for any item. Items are absorbed in 2s taking exactly 50 ticks to complete.

In the REAL WORLD that longer distance is traveled at a faster speed due to the physics of sitting still on a moving object and arrives at its destination at the same time as the inside item.

Now I'm no math wiz but 50 is less than 51.

Do you know it 50 and 51? What if it is 2 items from the inner lane first, and 48 even and 2 items on the outerlane to finish at the same time as straight?

A straight fully compressed belt of 8 items clears out in this many ticks:
yellow 36 ticks, red 18 ticks, and blue 12 ticks.


Edit:
200 sent starting on the same tick:
Top path is all straight, bottom path has one turn. Same number of belts travelled.


So while the inner path is shorter -- there is no loss in compression or throughput.

Full setup:

[Shokubai]

Your photo clearly shows one additional tile that must clear to complete the delivery.

What if it is 2 items from the inner lane first, and 48 even and 2 items on the outerlane to finish at the same time as straight?

2+48+2 = 52 ticks. You are costing the delivery with every turn.

[Peppe]

Your photo clearly shows one additional tile that must clear to complete the delivery.

What if it is 2 items from the inner lane first, and 48 even and 2 items on the outerlane to finish at the same time as straight?

2+48+2 = 52 ticks. You are costing the delivery with every turn.

The extra tile arrives ahead of the straight path, why is that bad? At every point in the test items have traveled across the same number of belts.

I clearly showed in the shot that the turn does not delay any items. It actually delivers the inner items ahead of schedule and completes the outer items in same tick as the straight path. Net, no loss in throughput or delivery time.

[Shokubai]

Lets try and explain this visually because, while your points are mostly valid, they are off the mark on my chief complaint which is that the curved belt should deliver items exactly like the strait belt and deliver items simultaneously.

For my test I created two belts of 15 tiles. One belt has a single turn. The other is strait. To ensure that input and output were the same I used fast at both ends. 25 items were added to each of 4 boxes. When power is applied, here is what happens.

Here is my test setup for reference.


Both belts begin even (as they should).


The turn with the expected existing mechanics.


That one extra?


SO CLOSE...and yet so far.


I did multiple repeats of this test. Always the same result. Full video is here if you would like to study it but I think the frame by frame is pretty obvious and needs no interpretation. That corner is costing you throughput.
https://youtu.be/hO7uv4rMpn0

[Peppe]

Don't inserters facing north run slower than other directions? I think that is what you are seeing as it looks the last single items arrives the same time as the straight set but an inserter is not available to pick it up.

Maybe do two turns and have all inserters face east/West.

[joon]

About inserters facing north, check viewtopic.php?f=48&t=9141

[Shokubai]

Don't inserters facing north run slower than other directions? I think that is what you are seeing as it looks the last single items arrives the same time as the straight set but an inserter is not available to pick it up.

Maybe do two turns and have all inserters face east/West.

I tried it both directions and I verified that the insertion was even at the start. Adding more turns in the same direction only exacerbates the issue.


It's worth noting that when having the same number of left and right turns the throughput was identical. This has to be due to the "shorter path" mechanic on the inside lanes. Something Ill have to remember.

[BlakeMW]

I did multiple repeats of this test. Always the same result. Full video is here if you would like to study it but I think the frame by frame is pretty obvious and needs no interpretation. That corner is costing you throughput.

It increases latency, it doesn't change throughput. Latency is one of those things which hardly ever matters unless it is either extreme or also reduces throughput, i.e. with logistic bots and trains latency has a direct effect on throughput, but with belts and pipes it does not.