Factorio Forums

Shokubai wrote:

Bytenex wrote: If it is an on-demand production there is still no difference

Compared to a strait belt of the same number of sections the U shape you tested is indeed slower(both lanes total Items per second) in an on demand setting. Having said that, the slow down may be due (in part) to a function of how inserters work.

I don't really know what you mean by slow down? The outer belt just has to be seen as a second belt (1 section longer/corner than the inner one). So the outer belt could be considered 2 sections longer than the inner one in my example. This means there is no difference for the throughput but only a delayed arrival due to the longer lane.

Bytenex wrote:I don't really know what you mean by slow down? The outer belt just has to be seen as a second belt (1 section longer/corner than the inner one). So the outer belt could be considered 2 sections longer than the inner one in my example. This means there is no difference for the throughput but only a delayed arrival due to the longer lane.

Throughput
This is speed * density. It describes how many items pass by in a given time.

In terms of of an On Demand system a "Delayed Arrival" is exactly the same thing as lower throughput since you are creating areas of lower density at the front and end of the line (2 down to 1).

I totally get that this is meaningless on a compressed belt.

Shokubai wrote:

Bytenex wrote:I don't really know what you mean by slow down? The outer belt just has to be seen as a second belt (1 section longer/corner than the inner one). So the outer belt could be considered 2 sections longer than the inner one in my example. This means there is no difference for the throughput but only a delayed arrival due to the longer lane.

Throughput
This is speed * density. It describes how many items pass by in a given time.

In terms of of an On Demand system a "Delayed Arrival" is exactly the same thing as lower throughput since you are creating areas of lower density at the front and end of the line (2 down to 1).

I totally get that this is meaningless on a compressed belt.

If you want to get technical, "throughput" is the amount of items passing through the belt per unit time. And since items on the outside of the curve spend roughly as much time as items on a straight belt section, then for belts of equal length, one with a turn one without, the belt with a turn will have momentarily higher throughput, because items on the inside of the curve get to the destination faster. It's not delayed arrival, it's accelerated arrival.

Sean Mirrsen wrote: If you want to get technical, "throughput" is the amount of items passing through the belt per unit time. .

Exactly what I said. This entire argument is moot in a compressed belt with Adequate supply that will never fall behind. Hence the On Demand conversation.

Sean Mirrsen wrote: And since items on the outside of the curve spend roughly as much time as items on a straight belt section, then for belts of equal length, one with a turn one without, the belt with a turn will have momentarily higher throughput, because items on the inside of the curve get to the destination faster. It's not delayed arrival, it's accelerated arrival.

I agree that the corner accelerates the inner lane but the additional tick that the outer lane passes compared to strait belt is your throughput loss. So while it does get one item Faster than normal, it gets 1 item slower than normal.

Accelerate the inner lane to infinity...put 10 items on it. Run the outer lane at the normal speed...put 10 items on it. It will ALWAYS ALWAYS ALWAYS take longer to deliver 20 items on that belt. THIS IS A THROUGHPUT LOSS as it takes more TIME to pass the same number of items in an on demand system. https://www.youtube.com/watch?v=ppdWPdw ... tu.be&hd=1 Easier to watch at .5 speed.

I also fully agree that there is may not really be a solution here that is simple. Fixing the graphic would potentially change functionality in an undesirable way. Still, I think there is a happy medium here somewhere where Radial velocity is applied accurately to items moving around the corner in both lanes.

Shokubai wrote:

Sean Mirrsen wrote: If you want to get technical, "throughput" is the amount of items passing through the belt per unit time. .

Exactly what I said. This entire argument is moot in a compressed belt with Adequate supply that will never fall behind. Hence the On Demand conversation.

Sean Mirrsen wrote: And since items on the outside of the curve spend roughly as much time as items on a straight belt section, then for belts of equal length, one with a turn one without, the belt with a turn will have momentarily higher throughput, because items on the inside of the curve get to the destination faster. It's not delayed arrival, it's accelerated arrival.

I agree that the corner accelerates the inner lane but the additional tick that the outer lane passes compared to strait belt is your throughput loss. So while it does get one item Faster than normal, it gets 1 item slower than normal.

Accelerate the inner lane to infinity...put 10 items on it. Run the outer lane at the normal speed...put 10 items on it. It will ALWAYS ALWAYS ALWAYS take longer to deliver 20 items on that belt. THIS IS A THROUGHPUT LOSS as it takes more TIME to pass the same number of items in an on demand system.

2016-05-20 08_45_21-Recording #1 - YouTube.png

giphy.gif

https://www.youtube.com/watch?v=ppdWPdw ... tu.be&hd=1 Easier to watch at .5 speed.

I also fully agree that there is may not really be a solution here that is simple. Fixing the graphic would potentially change functionality in an undesirable way. Still, I think there is a happy medium here somewhere where Radial velocity is applied accurately to items moving around the corner in both lanes.

Isn't the difference on this one where the item is placed on the first belt? Placing from the side places the item closer to the center of the belt. Placing from the edge places at the end of the first belt.

Yes Peppe it does, but not enough to change the results.
And before you say it, that's a SOUTH facing inserter.
Or if you prefer it this way...

So we all agree that this is a rather minor problem due to the fact that there is no difference between outer and inner lane, except in an on demand system. The only question left: is it really a good idea to use belts like in my example for an on demand system. The overhead produced due to the belt "lag" is not acceptable. I think most of the time either trains, robots or chests/inserter will be more suitable for on demand production than conveyor belts.

Lol! This all started as a very minor thing really pertaining more to the graphics used than the functionality. I would rather have a graphic of two separate belts to represent it's current functionality than the current single belt graphic or fix the animation to match the current belt graphic.

I certainly learned a lot along the way and the On Demand piece was the outcome of a lot of debate about throughput.

All I really wanted was this at high speed!

This GIF above is a very good example, why the belts are working as they work now.

Just imagine each item is a double-six-pack. We just call this item "double-six-pack".

Then - logically - this belt works only as it works, cause there is a distance between the double-six-packs.
The outer lane is faster. The distance between the items on the outer lane is longer, than on the inner.

Now imagine, that the distance between the items would get smaller and smaller. If the distance would be zero, that belt wouldn't work anymore like so! Then the speed on the outer lane needs to be the exact same then on the inner.

ssilk wrote:This GIF above is a very good example, why the belts are working as they work now.

Just imagine each item is a double-six-pack. We just call this item "double-six-pack".

Then - logically - this belt works only as it works, cause there is a distance between the double-six-packs.
The outer lane is faster. The distance between the items on the outer lane is longer, than on the inner.

Now imagine, that the distance between the items would get smaller and smaller. If the distance would be zero, that belt wouldn't work anymore like so! Then the speed on the outer lane needs to be the exact same then on the inner.

This is false.

If the distance was 0 they would be one item ...one item on this belt would arrive in no more or no less time. The BELT has speed...not the item. We are not driving on a racetrack where two cars are going the same speed. By the laws of Radial Velocity an item on the outside travels faster than an item on the inside. But funny how that package isn't spinning in circles due to the speed difference or distance traveled?

If you are suggesting that compression would cause a backlog down the previous length of belt then the issue is that the corner is slower than it's incoming belt. The corner needs sufficient speed to prevent this. As long as the corner can handle the volume this is never an issue.

Hold up your hand...Spread your fingers...That's how the corner should look coming off a compressed belt. Compressed on the inside, spread on the outside. Both items entering and exiting simultaneously.

YES I KNOW this is how it used to look. The issue at the time was that collision caused items to bump into each-other on the inside corner causing gaps. That belt design WORKs with fast corners(albeit not quite right). It doesn't work at a slower speed than the ingoing and outgoing belt. The real world example of this in my video shows this process exactly. The corner is designed faster than the belt in and belt out. I love the fix they made. I really do. But, it could have also been fixed by making corners naturally faster as is necessary in the real world.

The real issue as it relates to my issue with the graphics is the 90 degree corner that doesn't allow radial tansfer. Factorio belts work more like this...
https://www.youtube.com/watch?v=oGqV-v2cL6I

Shokubai wrote:

ssilk wrote:This GIF above is a very good example, why the belts are working as they work now.

Just imagine each item is a double-six-pack. We just call this item "double-six-pack".

Then - logically - this belt works only as it works, cause there is a distance between the double-six-packs.
The outer lane is faster. The distance between the items on the outer lane is longer, than on the inner.

Now imagine, that the distance between the items would get smaller and smaller. If the distance would be zero, that belt wouldn't work anymore like so! Then the speed on the outer lane needs to be the exact same then on the inner.

This is false.

Hm. Dunno, why this is false, cause this is a correct analysis of the above GIF.

But to go deeper into this subject: As you also analyzed, there are only these two extremes:

Corners with similar belt speed for inner and outer lane (as it is now)
- The outer lane has the same speed as the inner lane.
- The distance between items on the outer lane is the same as on the inner.
- The outer lane is longer, which means, the items take a longer way, then the inner.
- With full compression AND in average there are more items on the outer lane, then on the inner lane.
- There is no "state change", no matter, if the belt is "stopped state" (fully compressed) or in "full throughput state" (running).
- The belts behave equal, no matter if there is a curve or a straight belt.

Corners with radial belt
- The outer lane has a faster speed.
- The radial speed of the belt is equal for the inner and outer lane.
- The outer lane is not fully compressed, even if the incoming straight belt is compressed.
- In "full throughput state", the outer lane has (in average) the same number of items on as the inner lane.
- In "stopped state" (fully compressed), the outer lane has some more items on, compared to the inner lane.

The behavior will change then like so (compared to now):
- If the belt stocks, the items in the curves need to compress first. And if the belt will work again it takes some time, until the items in the curves will decompress. (*)
- Even on a fully compressed belt I can insert items in a curve on the outer lane.
- If you have a curvy belt, it may take some seconds, before taking out one item at the end of the belt can be seen as reaction at the beginning. (**)

TL;DR: The behavior of corners with similar belt speed for inner and outer lane has much less "surprises", than for corners with radial belt. Cause the belts are already quite complex, it is the best decision to reduce belt complexity as far as possible, which means same speed for outer and inner lane.


Not so important side arguments (see the stars in brackets above):

(*) Which means in consequence, that belts cannot be handled as two long lanes anymore. This is currently the case: A belt - no matter how much curves are on it - is handled as two long lanes. An internal data-structure. This is done mainly for CPU-speed reasons: The belt lane knows only, at which time an item was inserted and can now calculate, where this item is now. It's not longer needed, that each item is moved a bit in every frame. Items don't needed to be moved anymore (till v0.11), which means: That saves a lot of CPU-time.

With this change this is not longer possible: A belt-lane ends then at ann outer corner, then the corner itself and then the next lane, until the next outer corner.

(**) This is a bigger problem than you might think. If you play with v0.11 you can see, that it can take many seconds, until the standing wave of a missing item at the end of a belt is flooded back to the source.

Now, to make long stories short: This means in consequence, that the throughput of a factory is slower with v0.11 compared with v0.12 if you use lots of belts to transport items.

Which means: If this is changed like so, and you use lots of curves, the throughput of any factory will go a bit down.

There are several points in there where you state things as they are...not how they could be to solve the problem. With that in mind there is no reason for

- If the belt stocks, the items in the curves need to compress first. And if the belt will work again it takes some time, until the items in the curves will decompress. (*)
- Even on a fully compressed belt I can insert items in a curve on the outer lane.
- If you have a curvy belt, it may take some seconds, before taking out one item at the end of the belt can be seen as reaction at the beginning. (**)

Which means: If this is changed like so, and you use lots of curves, the throughput of any factory will go a bit down.

All of these negatives are made moot with some simple code. For instance...Why would i be allowed to insert an item on a curve that is compressed already coming out of a compressed strait line. Remember the finger spread? No inserting things between fingers unless a finger is missing.

(*) Which means in consequence, that belts cannot be handled as two long lanes anymore. This is currently the case: A belt - no matter how much curves are on it - is handled as two long lanes. An internal data-structure. This is done mainly for CPU-speed reasons: The belt lane knows only, at which time an item was inserted and can now calculate, where this item is now. It's not longer needed, that each item is moved a bit in every frame. Items don't needed to be moved anymore (till v0.11), which means: That saves a lot of CPU-time.

Then make the graphic TWO BELTS! The existing graphic doesn't match the item movement. WHICH IS FUNNY because the arrows move PERFECTLY.

Shokubai wrote:There are several points in there where you state things as they are...

Yes, I wrote it: "(as it is now)".

not how they could be to solve the problem.

That's, cause the things are as they are and are by definition wanted to work so.
And nothing has to be solved. It can be changed. Sorry for riding around at this point, there is an important difference for me.

With that in mind there is no reason for

I can use the same argument: "There is no problem, that needs to be solved".
But the whole discussion would make no sense then.

Why would i be allowed to insert an item on a curve that is compressed already coming out of a compressed strait line.

Cause it is not compressed in the curves. Cause it would look wrong, if not. The player will see "There is space for an item", so logically he thinks he can insert an item. If not the users would make bug reports. One every week, until this is "fixed".

Then make the graphic TWO BELTS! The existing graphic doesn't match the item movement. WHICH IS FUNNY because the arrows move PERFECTLY.

Hm. This is indeed the right solution to this "not-problem".

ssilk wrote:

Then make the graphic TWO BELTS! The existing graphic doesn't match the item movement. WHICH IS FUNNY because the arrows move PERFECTLY.

Hm. This is indeed the right solution to this "not-problem".

Indeed.

I've actually skimmed the entire thread in order to see if somebody mentions the elephant in the room: a "belt" is actually "two belts" (we call them "lanes") that move at the same speed, but completely independently. (One lane can be backed up while the other one moves items at normal speed.)

The graphics in the game do not indicate that, and that's confusing. The graphics make it seem as if it's actually one belt, like in the OP where the Dell logistics center is shown.

If you acknowledge that you have two completely independent belt lanes, and accept the fact that the inner corner is "temporarily compressed" (unrealistic), then there is NO PROBLEM at all and the belt behaves exactly as it should be, including the fact that items on the outer lane arrive later (go figure, they've covered a longer distance).

(Well, the post just above this agrees with me, but boy there was a lot of moot discussion in pages 1 through 5 of the thread.)

I think there should be a visual indication that the belt is made of two separate, and different, lanes. It would also make it easier to see which color the belt is when it's packed with items.
(This is not really good artwork but it illustrates the idea.)

that alternate belt look sounds like the perfect thing to have in a 1st party Mod for those that need things to look that way.
i don't want the Arrow sides to become misaligned though, THAT would bother me.

the looks of Belts as it stands is basically perfect. the space in the center lets you see the Arrows regardless of what is on the Belt, so even if a Belt is backed up, i know which direction it's facing. a solid line down the center wouldn't help with that.

The belts don't work like so.



Belts can transport the character. Or cars, see pic. The difference between the lanes is only visible for items and only in curves.

ssilk wrote:Belts can transport the character. Or cars, see pic. The difference between the lanes is only visible for items and only in curves.

The difference between the lanes is especially visible if only one lane of the belt is backed up, and the other one is free. Then one lane will move, while the other one won't (as far as the items on the belt are concerned, ignoring the visual effect). No corners/curves are necessary to display this aspect of the belt.

The car will be on either of the two "virtual" lanes, and that will be the one carrying the car. I'm guessing that each object in the game has a "center of gravity" which will be used to determine what part of the belt is carrying it.

That the difference is not visible in some cases does not mean that it doesn't exist.

But there is another way to think about the two-lane belt if you want to pretend it's a one-lane belt: when the belt is backed up, it will continue to slide underneath the items on the belt, indefinitely. If only one lane of the belt is backed up, the other lane will get transported unhindered.

I think this is less intuitive for the player than having a clear visual indication that the belt is split into two lanes, that are for all intents and purposes independent belts.

It's really not an important issue in Factorio at all.

If there would be a visual change to the belts I would vote for the suggestion of siggyboy.It doesn't solve the problem of the belts consisting of two seperate lanes but it would be a nice adjustment and it's also nice to see the blue (yellow/red) line between the items to make it clearer which belt is underneath.

There will be no real solution with the current graphics (for the non existing problem ) as the belts are not comparable to anything in real life because there is no real belt system that keeps running underneath the loaded items, even if they stack back. This would cause friction in real life and therefore ruin items on the belt.

siggboy wrote:The difference between the lanes is especially visible if only one lane of the belt is backed up, and the other one is free. Then one lane will move, while the other one won't (as far as the items on the belt are concerned, ignoring the visual effect).

Sorry, I need to reply again.
With "difference" I meant "different behavior". Sorry, difference alone is misleading; perhaps I thought it was clear, that I mean the behavior.

Watching it into that light means: That there are two lanes on the belts is a concept, not a difference.

Also that one lane will move, while the other not belongs to this concept. That is still no difference between lanes, because the behavior of the two lanes is equal. (You can replace "behavior" also with "rules", that makes it eventually more clear, what I mean).

No corners/curves are necessary to display this aspect of the belt.

The different behavior can be seen only there; in other words: the rules for their behavior change.
For the rules see my post above: posting.php?mode=quote&f=5&p=161261#pr160983

The car will be on either of the two "virtual" lanes,

No, the car is in this case "on the belt", and not on one of the lanes. For (mobile) entities like the car or the character there are different rules than for items. (Belts are much more complex than one might think )

I'm guessing that each object in the game has a "center of gravity" which will be used to determine what part of the belt is carrying it.

No, entities have a size and if one part of that lays on the belts it will move.

That the difference is not visible in some cases does not mean that it doesn't exist.

I never said, that the difference is not visible. Indeed I mean, that it is a very important aspect of the belts (and Factorio in whole), that you can see, how they behave just by watching them.

It's really not an important issue in Factorio at all.

Indeed.