Belt Corner Speed or .12 got it wrong

[taiiat]

it's also nice to see the blue (yellow/red) line between the items to make it clearer which belt is underneath.

functionality is already present - you can clearly see the moving arrows on the Belt even if it's completely backed up. and that means you can see the color.
ergo, already present. you worded it like it would be a new feature.

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.

depending on what's being produced, many factories literally do exactly that.
the products sit on the belt, pushed against each other, as the belt continues to move under them. there isn't sufficient friction to cause the products to become damaged, but enough to make constant head pressure on the system so that everything always loads correctly.

in short - exactly that does happen in factories. just depends on if what's being made is durable enough to go that route.

[Blu3wolf]

Would be nice to see items on the outside of the belt move faster, as physics demands they should.

[Sean Mirrsen]

Would be nice to see items on the outside of the belt move faster, as physics demands they should.

We're making advanced robotic arms out of scrap metal, making less advanced robotic arms out of more advanced components, turning plain iron plates into bullets, and have water pumps and conveyor belts running on nothing at all.

Either all those things should be fixed as well, or physics should really mind its own business.

[Blu3wolf]

Id agree for the last two. The rest I dont see a physics issue with, although perhaps you are complaining about a gameplay issue rather than a physics one.

Physics should be as applicable as gameplay allows. As argued above, the lack of physics applied above inconveniences gameplay. Its not even a complex fix. In any event, if you take issue with my statement on how physics works, then I shall amend it just for you: Would be nice to see items on the outside of the belt move faster, as I demand they should.

[Sean Mirrsen]

Id agree for the last two. The rest I dont see a physics issue with, although perhaps you are complaining about a gameplay issue rather than a physics one.

It's a physics issue in a roundabout way. Physics demands, through its application in mechanics and electronics, that a robotic arm containing a compact powerplant and capable of more functions than its counterpart relying on external power, to be more complex in construction, instead of less.

Physics should be as applicable as gameplay allows. As argued above, the lack of physics applied above inconveniences gameplay. Its not even a complex fix. In any event, if you take issue with my statement on how physics works, then I shall amend it just for you: Would be nice to see items on the outside of the belt move faster, as I demand they should.

My problem with it is that gameplay does allow physics to apply, the game was just chosen to work this way. There are good ways of allowing the starter mining drills, inserters, water pumps, and even conveyor belts, to require electricity, but the game was set up with a particular progression in mind, and the game's design stuck to that progression instead of complying to conventional engineering wisdom. I'm not saying it's a bad progression - it does work, and is probably simpler for an average starting-out player to understand and get into - but it does make no sense if you look over it with a critical eye.

[siggboy]

the products sit on the belt, pushed against each other, as the belt continues to move under them. there isn't sufficient friction to cause the products to become damaged, but enough to make constant head pressure on the system so that everything always loads correctly.

Maybe, but in the real world, the items at the end of the belt would all get jumbled up and slowly fill both lanes of the belt (while the belt continues to back up).

In Factorio, the lanes are treated separately, and one lane can back up for hundreds of miles, but not a single item gets shoved into the neighboring lane. Just as if it was in fact a separate lane with a solid barrier running in the middle of the belt.

My suggestion was to illustrate this fact graphically, which would happen to also make the belt color a bit more prominent. The belt color is not the actual issue here, though.

[tobsimon]

I'm a little out of context but wanted to add my to cents on the claim that curves are slower than straights, which is wrong.

Test setup: Both belts cover same exact distance, one with 2 curves and the other with 20 curves.

end.png (640.84 KiB) Viewed 3815 times

The curvy track is significantly faster. The lead of 3.875 tiles makes curves 22% shorter or 27% faster than rectangular straights.

Is this illogical? No, it follows right from the premise.
Is it counter-intuitive? Well maybe a little.
Is it bad? No, quiet good actually. Why should the transport close to the beeline not be a little faster than the perpendicular alternative?

The curve speed affects the latency of the system, which is insignificant when transporting many items. Throughput would not be affected obviously since jamming on inner curves does not happen in 0.12 anymore. So, apart from it beeing easier to build, there is no gain in building perpendicular instead of curvy.

The decision to skew the item positioning was - I guess - of aesthetic nature. The problem here is, that the inner lane is not much of a curve at all, more like a corner. So there would either be heavy overlapping on the inner lane or the items on the outer lane would need to be whisked around in most implausible speeds. The skewed relative positioning probably simply didn't look that bad compared to the alternatives.

[Shokubai]

The previous post actually describes a funny thing about the .12 fix that causes the inside lane to move ahead a step. Stacking turns like you do there actually forces items ahead on track due to the shorter path idea. Those curves actually make a strait line...diagonally. As the crow flies and whatnot. You can easily see the jump by watching the arrows on the belt compared to items on the inside and outside lanes. Which still bugs the crap out of me because the arrows behave like I expect the items on top to.

the items on the outer lane would need to be whisked around in most implausible speeds.

Not at all like Blue belts.

[Bytenex]

it's also nice to see the blue (yellow/red) line between the items to make it clearer which belt is underneath.

functionality is already present - you can clearly see the moving arrows on the Belt even if it's completely backed up. and that means you can see the color.
ergo, already present. you worded it like it would be a new feature.

No, I never said it would be a new feature. I just like the idea and the better visiblity you get from this suggestion. That's all.

[taiiat]

My suggestion was to illustrate this fact graphically, which would happen to also make the belt color a bit more prominent. The belt color is not the actual issue here, though.

which would be great (if that fixes the 'issue' for people) as long as it's optional. something like a new menu that has some 1st party cosmetic options for a some slightly different but still same visually themed choices for parts that have conflicted cosmetic opinions.

if i have to have my Belts look that way, then no thanks.

[Sean Mirrsen]

Well, it's basically as easy as adding a mod. It's not like the belt graphics are that hard to edit, either.

[taiiat]

Well, it's basically as easy as adding a mod. It's not like the belt graphics are that hard to edit, either.

if people were more than fine with making a Mod to do this, they'd just make a Mod rather than ask for mechanics to change in vanilla :p
that's the way i see it that is.

unless 'it' is considered a bug or unintended result of some sort, and attempting to get it fixed.