Belt Corner Speed or .12 got it wrong

[Shokubai]

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.

Actually that's false. Any latency in a network is inherently a reducer of throughput. A slow signal to trigger a thing causes the thing to trigger more slowly. Don't you play internet games?

But I want to be clear. My complaint isn't really about throughput specifically. It's about the graphical representation of the linked conveyor belt and items that do not transition corners like they would on a real belt.

[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.

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.

There is still an inserter facing north in that test, so the inserter loading the inside lane will fall behind all on it's own -- indeed you show it having two items on the belt at the end, when there should only be one. Try your test length/size with all straight track one east/west one north/south and you should see the east/west belt with inserters north/south will fall behind. I don't recall the exact number, but it may be one full item every 15-20.

North facing inserters move like 2.2 items a second instead of 2.3. So you put 25 items in and the north facing one will fall behind even on straight track.

[Sean Mirrsen]

Would it not be much easier to slightly change the graphic of the belts to resemble roller belts? I.e. a series of rollers with a simple stripe and arrow image on each, so all of them rotating together creates the illusion of a moving image. It'd just be a slight shading change. Then items taking longer to travel on the outside of turns will not conflict with the visuals.

[BlakeMW]

Actually that's false. Any latency in a network is inherently a reducer of throughput. A slow signal to trigger a thing causes the thing to trigger more slowly. Don't you play internet games?

I've used satellite internet, it has like a 700ms ping due to speed of light limitations. Bandwidth can be excellent though. If you're going to spend say, 2 hours downloading 60GB, it doesn't matter if the connection takes 700ms to establish itself. That's like a belt in factorio, usually they'll be delivering stuff for hours and you don't make one-off deliveries along a belt.

[ssilk]

Wiki helps with terminology also:
https://wiki.factorio.com/index.php?tit ... ottlenecks

Throughput for belts = Speed * Density

And the different measured times for each lane can be interpreted so, that the longer time comes from a longer lane (Time = Length of Lane * Speed) and so the longer lane can hold more items.

#items on a belt-lane = Density * Length

This is interesting, cause it is useful, if you use belt as storage: Theoretically (when I interpret everything correctly) a S-formed belt (left, right, right, left, left...) can hold much more items, than two in parallel.


PS: For me it is logical, that the outer side of a belt is longer, otherwise it would look ugly. Really, I think that's the reason, why it is, as it is.

[Shokubai]

Actually that's false. Any latency in a network is inherently a reducer of throughput. A slow signal to trigger a thing causes the thing to trigger more slowly. Don't you play internet games?

I've used satellite internet, it has like a 700ms ping due to speed of light limitations. Bandwidth can be excellent though. If you're going to spend say, 2 hours downloading 60GB, it doesn't matter if the connection takes 700ms to establish itself. That's like a belt in factorio, usually they'll be delivering stuff for hours and you don't make one-off deliveries along a belt.

You illuminate an excellent point. Assuming you don't need to to absorb data as fast as you transmit requests for it then your thought process is correct. The data in this case can be transmitted and re-transmitted faster than it plays back so you perceive no lag. Stretch that bandwidth thin and you are familiar with the problems.

In Factorio terms this would look like your producing more copper than you are using and therefore sitting on full density belt. Taking the North Facing Inserter as an example...Lets call that latency...it wouldnt matter that it's slower. It would never be noticed because the material is not being used as fast as it's produced.

Lets apply this principle to a FPS game. Lets pretend two people aim at each-other and pull the trigger at the same moment. The guy with the lower latency wins...Clearly. What about shots per second? Maybe those same two people are capable of hitting the shoot button 20 times per second. Lets pretend we can give a 0 latency 3-2-1 go...We will run the clock for each shooter until 100 shots are fired in game. Obviously again, the guy with the lower latency has a higher throughput or Shots per second because he will undoubtedly fire his 100 shots quicker than the other guy.

Remember part of my argument was about a balanced input and output or at the very least a higher demand than production where this might be noticed.

[Shokubai]

There is still an inserter facing north in that test, so the inserter loading the inside lane will fall behind all on it's own -- indeed you show it having two items on the belt at the end, when there should only be one. Try your test length/size with all straight track one east/west one north/south and you should see the east/west belt with inserters north/south will fall behind. I don't recall the exact number, but it may be one full item every 15-20.

North facing inserters move like 2.2 items a second instead of 2.3. So you put 25 items in and the north facing one will fall behind even on straight track.

But it did not fall behind in my tests. Further...That south facing inserters stack is still behind.

[Shokubai]

PS: For me it is logical, that the outer side of a belt is longer, otherwise it would look ugly. Really, I think that's the reason, why it is, as it is.

But it is illogical in real world applications on a similar mechanism. AND IT DRIVES ME NUTS! But I said at the beginning I'm probably crazy.

[Shokubai]

All I want for Christmas is the .11 graphics of a corner without the introduced spacing that was caused by item collision.

[Peppe]

There is still an inserter facing north in that test, so the inserter loading the inside lane will fall behind all on it's own -- indeed you show it having two items on the belt at the end, when there should only be one. Try your test length/size with all straight track one east/west one north/south and you should see the east/west belt with inserters north/south will fall behind. I don't recall the exact number, but it may be one full item every 15-20.

North facing inserters move like 2.2 items a second instead of 2.3. So you put 25 items in and the north facing one will fall behind even on straight track.

But it did not fall behind in my tests. Further...That south facing inserters stack is still behind.

What do you mean it did not fall behind? You attribute it not finishing at the same time to the belt turn, when it is the inserter facing. As I showed earlier the contents after passing through a turn have only the inner lane shifted forward, so if you have enough unloading capacity they will finish at the same time.

Are you not understanding the north facing inserter problem? If i do a simple test the north inserter is a full item behind at ~27 items:

After 50 items:

There are not turns here to blame the horizontal line finishing after the vertical line.

So your claim that the belt with the turn loses throughput because the items don't finish at the same time is wrong if the reason they don't finish at the same time is because one of your unload inserters is facing north and can only move 27 items in the time an inserter facing any other direction moves 28.

[Shokubai]

Make it a U. All inserters face EW. I did this test as well which also failed.

I fear this has devolved into an argument outside the bounds of my original goal which is simply to fix the graphics and allow the corner to function more realistically while maintaining the same throughput as a strait belt.

[DerivePi]

Consider your conveyor picture in your first post except there are 2 lines of boxes being conveyed and all of the boxes have a very small space between items (fully compressed).

Under .11 mechanics, those 2-dimensional boxes arrive at the corner but the inside line of boxes smash up against each other and are momentarily halted while going around corners (the conveyor under those boxes is moving faster than the obstructed boxes). Meanwhile the outer line of boxes are free to travel at the rotational speed of the conveyor (picture at any moment in time, you can only have 2 boxes on the inside track and 7 on the outside track).

Under .12 mechanics, those boxes, like your OP picture, are well spaced apart (graphically the icon shown is much bigger than the actual item on the conveyor)and the items do not smash up against each other on the corners. Both inside and outside lines travel at the same radial velocity and enter and exit the curve at the same time.

Under 0.11 the density of items on belts changed based on the speed of the belts. At rest there were 32/9 items per tile (each item took 9 pixel unit and each tile is 32 pixel units). In motion, the yellow belt moved at a rate of 1 pixel unit/tick and didn't move the next unit on the belt until after 1 tick. The red and blue belts were similar with 2 and 3 units per tick. So density on the belt for yellow was 32/(9+1) = 3.2 items/tile. Red and Blue were 32/11 and 32/12, respectively. Maximum 1-sided throughput on unimpeded belts were (items/pixel unit x pixel units/tick x 60 ticks/sec) 1/10 x 1 x 60 = 6 units/sec, 1/11 x 2 x 60 = 120/11 or about 11 items per second and 1/12 x 3 x 60 = 15 items per second for yellow, red and blue belts. However, after a corner, the inside lane's density due to the obstruction of the boxes, was reduced to approximately 3.75, 7.5 and 11.25.

Edit - Nope, my bad. Under 0.12, the items move around the bend at different radial velocities. I agree, that is a bit gamey. Graphically, it should be two belts in parallel to mimic that behavior in the real world ... on a foreign planet ... with alien monsters ... and a dude with a locomotive in his pocket.

[Shokubai]

Edit - Nope, my bad. Under 0.12, the items move around the bend at different radial velocities. I agree, that is a bit gamey. Graphically, it should be two belts in parallel to mimic that behavior in the real world ... on a foreign planet ... with alien monsters ... and a dude with a locomotive in his pocket.

Funny story. Wife saw me playing Factorio and was like "what is that"? I replied "I dunno but I've got a locomotive in my pocket. Wanna see?"

[DerivePi]

Now if only you can get her to play too. Going to bed after 12 wouldn't be so awkward.

[Shokubai]

Now if only you can get her to play too. Going to bed after 12 wouldn't be so awkward.

I gotta go find this spy cam you have in my house...its like you know my life!

[taiiat]

Lets apply this principle to a FPS game. Lets pretend two people aim at each-other and pull the trigger at the same moment. The guy with the lower latency wins...Clearly.

it actually heavily depends on how Latency Compensation is handled in said theoretical game. there's ways to handle it (that some games employ) where higher Latency causes you to not get hit, while still being able to hit the other guy, Et Cetera.

more importantly - Shooters have been using Client side Detection for many years (or some being a mix of Client side with Server approval). what this means is that if you aim at where the dude is on your screen and shoot, you hit him, even if when the other Player sees himself get hit, he's moved behind a wall. it's shitty but it's also generally better than fully Server side Detection where the Shooter would have his shot miss for no visual reason, even though his projectile clipped into the Enemy.
and the mixture being Client side Detection with the Server keeping loose tabs on the session, to audit every single shot call to determine whether it's within probable bounds or not. but that's basically just to make cheating harder, nothing to do with Latency Compensation directly.

inversely, complete Server side Detection often actually rewards better results to whom has higher Latency, as the Shooter will find himself having a very hard time actually hitting the other Player, while the Shootee is free to bumble around and shoot as he pleases and hit the Shooter just fine because the Shooter isn't 'lagging'.

Networking is complicated.

What do you mean it did not fall behind? You attribute it not finishing at the same time to the belt turn, when it is the inserter facing. As I showed earlier the contents after passing through a turn have only the inner lane shifted forward, so if you have enough unloading capacity they will finish at the same time.

hang on - you're both right, calm down. yes, the North facing Inserter is causing a slowdown, but that doesn't change that there was an item on both sides of the belt there - which if the belt theoretically moved all items regardless of turn side at the same 'speed' (you know what i mean, don't complain), then only the North facing side would have an item on it at the end.
but both sides do, which means that there's multiple 'issues' present.

- - - - -

the way the belts look currently, is probably the best choice visually for how they could look. it's uniform, and blah blah. changing the way the belt looks wouldn't help the game.

conceptually i get the point here, and if it doesn't look noticably weird (preferably as little as possible), speeding up the outside of the belt and slowing down the inside enough to get them to be together again, without causing any actual backlog problems like was fixed in 0.12, sounds fine to me.

but only if it can be done to where it doesn't look weird. where it doesn't look like items are sliding on the belt, or having sudden changes in velocity for no practical reason, Et Cetera.

[Peppe]

To add to the variables. If you use blue belt the route with turns in it finishes first...

Red/Yellow belt and this item spacing has the inserter on the turn route idle during the offset item portion, so it delays the finish.

With blue even through the offset an item arrives in time for inserter two on the turn path to take an action.


And if you add just one more inserter to increase belt density and the yellow belt now finishes at the same time straight vs turn.

So the difference in finish time in your original test case is largely due the second inserter on the turn path being idle for more frames as it half starts and fails to grab items in a race with it's counterpart. No throughput loss with enough density/unloader capacity.

[Linosaurus]

Edit - Nope, my bad. Under 0.12, the items move around the bend at different radial velocities. I agree, that is a bit gamey. Graphically, it should be two belts in parallel to mimic that behavior in the real world ... on a foreign planet ... with alien monsters ... and a dude with a locomotive in his pocket.

Yeah. Factorio belts behave like two separate belts, but look like a single belt made of separate segments. It is almost like the outer item sits on the belt properly, but the inner item is pushed ahead because 3-4 segments are stacked on top of each other. Personally it doesn't bother me at all.

There are two solutions, both pretty bad imo.
1. Slow down inner corner. You'll have several items occupying the same spot, as was mentioned on page two in this thread.
2. Speed up outer corner. You'll have items look like they are moving super fast around the the curve, and the graphic needs to be change so that only ~1 instead of ~4 segments are in the curve at the same time.

I think either would look weird, and the the current look of the belts is a very iconic part of factorio and should be kept.

[Bytenex]

Hi,

the whole problem with this is only that the belts are moving at constant speed (even in corners) where they would normally speed up (radial movement). So the outer lane is longer than the inner one. This has already been stated. And yes: that is unrealistic because belts don't work this way.

BUT:
Even if the outer lane is longer there is no loss in throughput.

E.g.: There are 20 items moving with 1m/s. There is no difference if they need 3 or 4 seconds to get to their destination. It's still the same amount of items in the same time (because you mustn't meassure the whole 4s for the throughput but only the time from first item arriving to last item arriving and this will be 3s.)

This will only have an effect when you are working on demand. Yes it will make a difference if you are sending items on the inner or the outer lane, but if the lanes are loaded constantly during the whole time there will be no difference with the number of items transported. It will only be significant when you load e.g. 1 item and want to transport that to another factory. It will take longer (delaying the production) if it is sent on the outer lane.

Conclusion:
I think what the OP wanted to say is that this behavior is okay but as you can see in the GIFs: The belt seems to be moving faster than the actual item and this is a bit weird. Still only a cosmetic problem.

P.S.:
Latency:
The two examples mentioned don't go together. It's like you are comparing TCP to UDP. TCP is sending packets and wants a confirmation that every packet was received (FPS Game: Sending that you shot. Other recognizing that he get's hit. Sending back that he got hit). This will take longer (lower throughput) if the latency is high, because the sender will wait for the confirmation before sending new packets. UDP is a constant stream of data like a download. You are not sending any response to the server but only getting the datastream (and yes I know that it's only a simplified version of what really happens). There is no need for an answer so it won't slow down even if 50% of the packets get lost.

Transposed to Factorio:
-> You can test this behaviour if you build a lane with smart inserters. The input is only sending items when there are less than a specific amount in the output box. This will give you a lag like behavior like in video games. (There will actually be more items transported than really needed because of the latency caused by the belt)
-> If you do the same setup with fast inserters there will be no real lag because the inserters keep sending items till they run out. (Constant stream)

See the following setup for "lag" and throughput testing:

lag_throughput.gif (5.33 MiB) Viewed 6159 times

All inserters place/take as long as there are less than 5 items in the output chests. You can see the "lag" that is produced by the belt. The throughput is the same at all times for both lanes. The only difference ist the delay after two corners. As I already said: If this is a constant production there is no difference between inner and outer lane. If it is an on-demand production there is still no difference (testet with multiple values). The quantity of both lanes still on the belt is 17 (inner) and 18 (outer). So the difference between both is 1 (even for longer placing). The only thing that could influence this further would be to insert more corners, but I think there are very few examples where you would build a belt with 3+ corners in the same direction.

[Shokubai]

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.