Reduce item spacing on transport lines to fit 8 items/tile

[Therax]

Currently items on belts are placed every 9 pixels, with map tiles being 32 pixels wide. I propose reducing this spacing to 8 pixels, leaving belt speeds the same, which would have the following desirable effects.

1. It's a 12.5% buff to belt throughput overall. I think this would be welcome in the great belt/bot debate, without being such a large buff that it substantially affects game balance.
2. Makes belt throughput numbers more user friendly. 13.333333... becomes 15, 26.66666666 becomes 30.
3. Ensures that every tile on a compressed belt has exactly 8 items in it, 4 per side. This makes estimating the amount of items buffered on belts much easier to calculate, but more importantly:
4. Makes certain circuit network constructs simpler and easier to reason about. Instead the current situation where a compressed belt set to Read contents/Hold changes between 6 and 8 at unpredictable times based on how the belt is flowing.

Note this isn't something that can be done in a mod, although Bob's Logistic has changed belt speeds to make throughput be multiples of 10.

Thoughts?

[Zavian]

All your arguments make sense, and I wouldn't object if the devs wanted to change this, but I think changing this in stock is unlikely at this point in development.

So +1 one to concept, and a big +1 to whatever change is needed to allow mods to changing the spacing for items (assuming that is an easy change for the devs to make).

[darkfrei]

Makes certain circuit network constructs simpler and easier to reason about. Instead the current situation where a compressed belt set to Read contents/Hold changes between 6 and 8 at unpredictable times based on how the belt is flowing.

Right now you are need 9 content readers, so 9 tiles x 32 pixels/tile and you always get 32 items in this 9 tiles.

[eradicator]

Sounds reasonable. Circuits are really annoying with the "6 or 8" system.

+10

[Optera]

+1

Sounds like a way to get even number belt throughput and items/tile without introducing stroboscope effects like most belt speed changing mods do.

[Jap2.0]

+1 for circuit simplicity

[Therax]

FYI there's a very robust discussion happening on my Reddit thread which is probably being seen by a larger proportion of the player base.

[Klonan]

So, the reason for the current spacing is all to do with the circuit network:

The distance between items is:
- 9 ticks for transport belt
- 6 ticks for fast belt
- 3 ticks for express belt

If we were to increase the density of the belts to 8/tile, that would change to:
- 8 ticks for transport belt
- 4 ticks for fast belt,
- 2.66 ticks for express belt

The non-integer tick distances between items would cause a lot of headache for circuit network usages.

[eradicator]

So, the reason for the current spacing is all to do with the circuit network:

The distance between items is:
- 9 ticks for transport belt
- 6 ticks for fast belt
- 3 ticks for express belt

If we were to increase the density of the belts to 8/tile, that would change to:
- 8 ticks for transport belt
- 4 ticks for fast belt,
- 2.66 ticks for express belt

The non-integer tick distances between items would cause a lot of headache for circuit network usages.

Couldn't that be countered by additionally increasing blue belts speed to 2*red? [Short of adding a fourth tier to cover both 3-tick and 2-tick...] Sure that's a quite significant bandwidth boost (+50% compared to current), but having a ratio of 4 yellow = 2 red = 1 blue is something many people have wanted for a long time, and it would still solve the "6 or 8" problem, which is also quite headache-inducing for circuits. (Although i'm not sure how well inserters can keep up at that speed. And if the bot fractions gets angry about belt boosting you just give then one additional cargo capacity research, making it a nice round 5 )

[Klonan]

Couldn't that be countered by additionally increasing blue belts speed to 2*red? [Short of adding a fourth tier to cover both 3-tick and 2-tick...] Sure that's a quite significant bandwidth boost (+50% compared to current), but having a ratio of 4 yellow = 2 red = 1 blue is something many people have wanted for a long time, and it would still solve the "6 or 8" problem, which is also quite headache-inducing for circuits. (Although i'm not sure how well inserters can keep up at that speed. And if the bot fractions gets angry about belt boosting you just give then one additional cargo capacity research, making it a nice round 5 )

There is a visual problem with anything faster than 3 frames/tick.
If express belts was 2x as fast as red, the animation would move 4 frames each tick. However because of the way the sprites are currently, there is a repeating part of the sprite every 8 frames, so you get a really jarring effect.

I am not saying it is not possible, it could be solved by making express belts 2x faster than red, but that leads to more problems too.

[Zavian]

How easy would it be to allow mods to adjust the spacing? That way people who want to try a spacing of 8 pixels between items, (possibly also with blue belts being twice the speed of red belts), would have that option.

[Therax]

The non-integer tick distances between items would cause a lot of headache for circuit network usages.

I'm not sure this would be quite the huge headache you present. Off the top of my head I can see two places where this would matter, 1) measuring belt flow with Pulse mode, and 2) using fixed stride counters to clock inserters to perfectly fill or pick up from belts.

Designs working around 1) usually have to be able to deal with non-full belts to begin with, so they can't rely on fixed intervals between pulses anyway.

Designs with 2) are working with inserters, and inserter stack size bonus tops out at 3 for fast inserters and 12 for stack inserters, which conveniently cancels out the awkward denominator of 3. With an express belt, you would be rarely dealing with 2.66 ticks per item, but 8 ticks per fast inserter swing, or 32 ticks per stack inserter swing.

There is a visual problem with anything faster than 3 frames/tick.
If express belts was 2x as fast as red, the animation would move 4 frames each tick. However because of the way the sprites are currently, there is a repeating part of the sprite every 8 frames, so you get a really jarring effect.

I am not saying it is not possible, it could be solved by making express belts 2x faster than red, but that leads to more problems too.

This sounds like a temporal aliasing problem, where the belt "links" are every 8 pixels, and arrows are every 16 pixels.
So currently, on express belts items positions repeat every 3 frames and belt link positions repeat every 8 frames, giving a total cycle length of 24 frames.
If item positions repeat every 2 frames (in the proposed 8/4/2 scheme), then we're looking at LCM(2,8) = 8 frame cycle length. I can see how that would look really bad.

This seems like something that could be fixed by making the length of belt "links" relatively prime to the item position cycle length. For example, if belt links were 11 pixels long, then you would have LCM(11,2) = 22 frames for express, LCM(11,4) = 44 frames for fast, and LCM(11,8) = 88 frames for regular transport belts.

You'd lose the convenient fact that LCM(8,32) = 32, so the actual transport belt animation would have to be much longer (LCM(11,32)=352), which hits VRAM. Unfortunately, we can't have both frames/item and frames/animation be a convenient power of 2 without hitting aliasing issues.

Even if periodic realignment with the belt animation weren't a problem, repeating item positions every two frames looks bad because there's no way to tell that items aren't jittering between two positions or even moving backwards. You really need a cycle of at least 3 frames to get a good-looking sense of motion. (For completeness, with my proposal, you get a cycle length of 24 frames on express belts, 4 frames on fast belts, and 8 frames for regular belts before items repeat their positions within a tile.)

On the third hand, given the popularity of mods that change belt speeds, I have my doubts that players care all that much about aliasing issues with belt animations.

[epr]

@Therax
Just let it go man, it's obviously not worth the issues it causes for the small increase in belt throughput.
Your conviction that you came up with some genius idea the devs hadn't considered before is just wrong.
There is even a bots vs. belts fff where they touch briefly on it.

[Jap2.0]

Belts don't look amazing at high zoom levels already (which might have something to do with my monitor resolution - 1280x1024), but if you're worried about graphical issues, what else were you planning on having the graphics team do after everything's in high resolution? Be able to have vacation ?

[Therax]

@Therax
Just let it go man, it's obviously not worth the issues it causes for the small increase in belt throughput.
Your conviction that you came up with some genius idea the devs hadn't considered before is just wrong.
There is even a bots vs. belts fff where they touch briefly on it.

At this point I'm not wedded to the idea. But I would like the understand the reasoning for keeping the current system. Klonan has been nice enough to give us some insight into the design decision, and I'm still exploring that space. I always like learning more about my favorite game, and as an aspiring game developer it's enlightening to see behind the curtain from time to time.

[bobingabout]

The initial argument makes sense to me, 8 pixels per item would be best.

However, Klonan also has a valid point.

I guess my faster belts would break these rules anyway then, because my T4 is 4x the speed of yellow belts, and T5 is 5x. And that's before you take into account the overhaul that adds basic (T0 grey) belts, and changes the speeds to 10, 20, 30, 40, 50 and 60 items per second.

[darkfrei]

So we have two issues:
1. Geometry: one tile has length 32 pixels, one item has length 8 pixels, so exactly 4 items on the tile length without gap on full compressed transport belt.
2. Speed: one pixel/tick makes 60 pixels/second and it is not good for one or two tiles with lengths 32 or 64 pixels.

[Therax]

So, the reason for the current spacing is all to do with the circuit network:

The distance between items is:
- 9 ticks for transport belt
- 6 ticks for fast belt
- 3 ticks for express belt

It was pointed out to me that fast belt actually has 4.5 ticks between items (2x transport belt speed). So is having integer tick gaps between belts really so critical?

[Optera]

It was pointed out to me that fast belt actually has 4.5 ticks between items (2x transport belt speed). So is having integer tick gaps between belts really so critical?

The way I read it having fractions of ticks between items on belts would require all belt interactions from inserters tracking items on belts to splitters and circuit connected belts to be checked and possibly rewritten.
Not saying it'd be unsolvable, just quite painful to break open a system like belts.

[Therax]

The way I read it having fractions of ticks between items on belts would require all belt interactions from inserters tracking items on belts to splitters and circuit connected belts to be checked and possibly rewritten.
Not saying it'd be unsolvable, just quite painful to break open a system like belts.

Nah, every mod that changes belt speeds changes the tick interval between items. For that matter, vanilla red belts have 4.5 ticks between items (9 pixels/item / 2 pixels/tick).