Two-way-Belts

[djugei]

TL;DR

Add belts with lanes going opposite directions.

What

I order of my personal preference: replace green belts by that new belt type, add a new belt type or add a modding api to for users to create that new belt type.

There is actually less edge cases than you would expect at first thought and to the best of my understanding this would not be the biggest of code changes, as belts already have two mostly independent lanes.

Why

When the green belts were announced i found even faster belts to be a bit boring. What if instead the two lanes of the belt went opposite ways?
That would allow new and interesting builds, keep the same local throughput (you can just feed from both sides if you want to use both sides),
and automatically nerf long-range throughput, elegantly making trains more relevant there.



Now i do understand that it is unlikely to be added at this late point in the development cycle. I have checked out the mod-api and i don't think it is possible to add this idea as a mod (without re-implementing belts entirely). So it would be really cool to at least get engine-level support, even if it does not get added to the game, much like loaders and lane splitters.

visualization


side-note: viewtopic.php?t=4806 this is heavily outdated

[wobbycarly]

How would splitters work?

[djugei]

While they would visually not fit the current model, they could just work the same way, just with half the inputs and outputs on the other side.
filters though i am a bit unsure about, maybe they would need to take two filters?

[djugei]

i made a little visualization of how it would work.

alt is an alternative mode for open belt ends, where they connect to themselves, this is not a requirement though.

as mentioned there is way less edge cases than might be expected.

for splitters the filter should probably be by lane direction instead of by side as it currently is, that is probably the biggest change.

[boskid]

No, this does not feel interesting. There are a lot of edge cases like if the items should be moving closer to the left edge or to the right edge (provided graphics toggle between those two), it creates weird cases for T-junction which would need to be a 3 way connection, or even a cross and this would make each belt tile effectively have a dynamic amount of lines. There is also interoperability of this thing and normal belts.

[djugei]

Thanks for taking a look, but the reply is leaving me a bit confused

like if the items should be moving closer to the left edge or to the right edge (provided graphics toggle between those two),

i do not understand what this means

it creates weird cases for T-junction which would need to be a 3 way connection, or even a cross

i don't see this happening, the provided picture contains a t-section on the right side, it just behaves normally, a lot like side-loading an underground belt.
are you maybe thinking of offsetting the belt by half a tile or something like that? as long as you stay in grid the rules seem pretty straight forward

and this would make each belt tile effectively have a dynamic amount of lines.

i think the only place where this would be true is with the alternate idea for belt ends

There is also interoperability of this thing and normal belts.

aligned lines connect, others don't just like today if you have two belts facing each other.

will draw an additional graphic

[boskid]

From the pictures provided, it looks like the player could assume that this entity has no direction because a long straight section would have 2 sides with input and 2 sides with output, and as such it would be a direction-less entity that connects to all neighbours. This means a corner would be connecting to neighbours, but you could not have 2 belts in parallel. Even if there would be option to have 2 belts in parallel, that means the corners of a 2-belt wide section would be unintuitive because the direction would have to be present to disambiguate side the belt should connect. And as soon as direction is added into the mix without proper feedback through graphics, this just becomes a mess.

The "closer to left/right" thing is in case of a 1x1 standalone belt piece, if the items would be circling clockwise or counter-clockwise.

-- edit:

about the "closer to left/right", its about this:

05-31-2026, 14-35-07.png (81.5 KiB) Viewed 273 times

If the belts would be directional, connections would become non intuitive. In one situation you could have this:

05-31-2026, 14-37-20.png (151.25 KiB) Viewed 273 times

or have them not connect because of this:

05-31-2026, 14-38-21.png (154.99 KiB) Viewed 273 times

Without direction, if you would want to build this:

05-31-2026, 14-38-56.png (261.83 KiB) Viewed 273 times

you would instead get this:

05-31-2026, 14-39-29.png (303.53 KiB) Viewed 273 times

however without direction this would be possible:

05-31-2026, 14-40-20.png (233.94 KiB) Viewed 273 times

[djugei]

ok, so just to make sure we are talking about the same thing: this would be a 1x1 entity, same as existing belts

let's ignore the thing labeled "alt" that was just an additional idea, i think it is possible to do but i don't think it is necessary, or possibly even good.

your most recent reply made it click, i assume you mean the spot marked yellow in the drawing attached to this post?
i agree that this could be unintuive though to be clear this entity has 4 possible rotations (as drawn) so this could be resolved unambiguously.

in the graphics i drew it would connect if the outer loop was going the other way, if i am applying my rules consistently.

[djugei]

edit: i seem to have misunderstood your graphics. you used 4 belts to represent one belt, i did not catch that.

[boskid]

But that means you have 2 pieces that are CW and 2 pieces that are CCW and they cannot mix together. If you would want to build a 2 way squiggly, you would have only access to pieces B and D (for CW horizontal and CW vertical). Which pieces would be placed where and what rules would be used to decide which belt pieces would connect to what? Why would D connecting from side cause a straight section of B's to not connect?

05-31-2026, 14-54-16.png (499.74 KiB) Viewed 248 times

[djugei]

05-31-2026, 14-54-16.png

i think this would be built slightly different, see attachment, but that would still open the question why B over D would connect while B under D would not.

i think it is possible to have a simple consistent ruleset around that, but that might then exclude a 4x4 circle. you might be right this could use require 8 pieces instead of 4 (4 straights + 4 corners). i will think on that a bit more when i am less tired. one idea would be to have it be like pipes, where you can't have corners touching but straights (underground) is fine.

interesting to find a literal corner case, thanks for replying and explaining!

[boskid]

I think trying to resolve the shapes would be slightly more complicated and would have to resolve each connection if its a "strong connection" (where both entities want to connect to each other) or a "weak connection" (where only one entity wants to connect there.

This configuration would have to be built like this:

05-31-2026, 15-25-40.png (201.45 KiB) Viewed 192 times

then you could find where the "strong connections" are (places where 2 entities want to connect to each other)

05-31-2026, 15-25-33.png (202.11 KiB) Viewed 192 times

because of this, some pieces would have their shape locked (entity with 2 strong connections would have its sides locked, here represented with thick white lines)

05-31-2026, 15-27-22.png (201.41 KiB) Viewed 192 times

then you add the "weak connections" on top in places that are not locked:

05-31-2026, 15-28-22.png (201.68 KiB) Viewed 192 times

and based on this the belts pieces would adjust their shape.

But even with this set of rules, trying to resolve a 90deg bend with multiple belts would involve resolving the connections recursively because some connections would create opportunity for side loading that cannot be resolved in a simple way:

05-31-2026, 15-34-17.png (129.18 KiB) Viewed 192 times