3 and 4 way intersections

[mmmPI]

So my question is: Which measurement is correct, and why?

I thought too that the small signals differences and maybe the rotation between your picture and the original could explain the differences, i think the signal spacing can have a big impact, rotation i'm less certain, it shouldn't be the case, but also the junction is very asymetric. As mentionned you don't need to apply the rule of leaving 1 train length of distance for the block following the junction, it is visible the right turn toward the north, when train come from east/right.

If you feel cheated, you can try to test another junction, maybe both of them will be overated given your testing rules/setup, or the same junction with a little different signaling, the denser the better , some shorter test to choose the best signaling could help too .

Also, it kind of bothers me that the 2-lane unbuffered 4-way intersection with the highest score is so asymmetrical. Additionally, I think Symmetrical Cross should be listed above Symmetrical, as it scores slightly higher for some spacings, but this is less important.

Symmetrical Cross is versatile for spacing, has good throughput, has many symmetry and exist LHT RHT but is also the most boring looking junction

[Yodo]

They should be placed as close as possible.

So the safe exit block length is measured from the first rail signal that the train passes after the last chain signal it passes when going through the junction (Edit: except when the train would not pass any chain signals, in which case it would be measured from the first rail signal it passes that is part of the intersection)? I've done the test again, this time using that rule, and got a score of 45.4±0.5 with the same settings.

view image of setup

Result of measurement run for Delta with the safe exit blocks closer to the junction

delta_test_closer_safe_output.png (601.29 KiB) Viewed 5021 times

As mentionned you don't need to apply the rule of leaving 1 train length of distance for the block following the junction, it is visible the right turn toward the north, when train come from east/right.

I don't quite understand, but maybe it leads to the same as what I wrote above.

I also made a version of the Symmetrical Cross where the safe exit blocks are further away from the center of the junction, and the lines have rail signals placed on them regularly, kind of like with the right turns on Delta, but then also for when a train goes straight through. Though it could be argued that this means the junction has buffers. (I think Delta might be kind of in-between having buffers, and not having buffers.) This design gives a score of 49.0±0.5

Results and setup for extended Symmetrical Cross

Result of measurement run for extended Symmetrical Cross

symmetrical_cross_extended_output.png (233.7 KiB) Viewed 5021 times

[hansjoachim]

They should be placed as close as possible.

So the safe exit block length is measured from the first rail signal that the train passes after the last chain signal it passes when going through the junction? I've done the test again, this time using that rule, and got a score of 45.4±0.5 with the same settings.

view image of setup

delta_test_closer_safe_output.png

As mentionned you don't need to apply the rule of leaving 1 train length of distance for the block following the junction, it is visible the right turn toward the north, when train come from east/right.

I don't quite understand, but maybe it leads to the same as what I wrote above.

I also made a version of the Symmetrical Cross where the safe exit blocks are further away from the center of the junction, and the lines have rail signals placed on them regularly, kind of like with the right turns on Delta, but then also for when a train goes straight through. Though it could be argued that this means the junction has buffers. (I think Delta might be kind of in-between having buffers, and not having buffers.) This design gives a score of 49.0±0.5

Results and setup for extended Symmetrical Cross

symmetrical_cross_extended_output.png

Some slight adjustments to the placements of rail signals do impact the performance also the orignal test with 15min had a terrible margin of error.
The intersection you posted is interesting, but those aren't safe as you don't know if the trains line up avoid a deadlock. Also yeah its considered buffered.
Regardless the point of the new testbench was to make testing more accurate and helps us being able to understand the impact of minor changes.
The plan was to restest all intersections and make a new ranking with much better margin of error.
All those plans are out the window because of ramps.
Ramps will make intersections no longer be the bottleneck in your network and intersection optimization isn't necessary anymore, making, in my mind, this thread obsolete. Sure you might want to look how to get 115 instead of 100 throughput just for fun, but really it doesn't matter since if intersection throughput is the issue with 100 tpm then you probably need more lanes or to spread the traffic more out.
If ramps had a speed reduction, highscore intersections would have a combination of buffers and ramps like in OpenTTD. And it would be more complicated to get 100tpm. That would be interesting.
But looks like ramps will be like curved rails with basically zero speed reduction. Which in my mind makes intersections optimization too easy.

[Yodo]

Yeah ramps will make other intersections basically obsolete. (Maybe in very high throughput areas where the upper level also has a full intersection they won't be used. (And with buildings all around, so the intersections can't be expanded.)) But only if you buy the Space Age expansion, which I don't yet have plans for. I still have enough things to do in vanilla. People could also choose to play without the Elevated Rails mod, but I'm not sure how common this will be.
I also think ramps should have a speed reduction (when going up).
Edit: the current curved rail pieces will also be phased out when Factorio 2.0 releases, so then none of this intersections can be used anymore.

I also realized that the extended Symmetrical Cross contains its own safe exit blocks, so the ones I added won't be necessary, and might also influence the result.

and maybe the rotation between your picture and the original could explain the differences,

I tested Delta again, this time rotated in the same way as the image in the first post (is there a better way to link to specific posts?) and got a score of 45.8±0.5 which is within the measurement uncertainty.

Edit:

The intersection you posted is interesting, but those aren't safe as you don't know if the trains line up avoid a deadlock.

I don't see how it is different to your Delta in this, as I added exit blocks that can fit a full train after each output (the ones I called unnecessary in my previous post). And in the Testbench map, I think such deadlocks will not happen (at least for this intersection, but maybe for high-throughput buffered intersections), as the trains are always deleted quickly enough in my experience.

[hansjoachim]

The difference from delta is that delta won't deadlock. The safe outputs needs to be after crossings, not mergers.

[Avona]

I tested Delta again ... and got a score of 45.8±0.5 which is within the measurement uncertainty.

When I tested Delta back in the day, I got scores in the 45-46 tpm range. I brought this up to Hans, but differed to Hans' testing. I forget what he said. Perhaps he optimized something.

[hansjoachim]

Think i moved the signals 1 tile closer. Regardless if we did that for all intersections the difference would be smaller.

[Yodo]

The difference from delta is that delta won't deadlock. The safe outputs needs to be after crossings, not mergers.

The extended Symmetrical Cross will only deadlock if one of the outputs becomes blocked while a train is on the junction, pathing there, and unable to repath. This can happen with basically any intersection, but with the extended Symmetrical Cross the weird buffers at the outputs increase this chance a lot (though the output still needs to become blocked). This doesn't mean that it is unimportant, as changing the rail network in your base can cause this.

A similar situation can happen if the output is not blocked, but in this case the train that occupies the intersection will be able to leave after a while (even without the repathing that also occurs after a while), and the junction will be normal again. I wouldn't call this a deadlock, and "temporary deadlock" sounds like a contradiction to me.

[mmmPI]

There are ramps, but to me what risk making those junctions obsolete is the new curves. More directions and differents curves means those rails pieces won't carry over 2.0 past the compatibility period, eventually, even without ramps, those junctions would need to be adapted.

Ramps have big impact on what the adaptation will look like, the newer junctions will be "interchange" without crossing i think , there won't be much need for buffered junctions because those are for throughput 'only', but the compact junctions i think could still find some uses in places where you don't want to commit to a full interchange due to low traffic or remote place, thought they would have to be remade.

This thread is called 3 and 4 way intersections, i think people will still be looking for this even with ramps searching for "a 3 or 4 way intersection with ramps". I think also the distance between merge area will be a source of optimization, and their spatial disposition, you could just stack 2 junctions on top of each other but that would be missing some opportunity too.

I tested Delta again, this time rotated in the same way as the image in the first post (is there a better way to link to specific posts?) and got a score of 45.8±0.5 which is within the measurement uncertainty.

you can't link a part inside a specific post when that post is nearly a book itself, it was enough though i got the reference, i wasn't sure the rotation could matter, in a way it make sense that some 4 junction could have 1 "worst" direction, if you have a circular perimeter, it makes the inner rail clockwise or counter clockwise, which means sometimes the right turn gets you inside the perimeter sometimes the left turn, it is better to give priority to train exiting such circular perimeter, given that the outside is infinite it is always favoring a more balanced density rather than having a tendancy to "trap" train inside. The other thing i could think of to justify the asymetry, is that the very center of the junction is occupied, this makes for the smallest possible area where train could have conflict, but this very area cannot be occupied efficiently is using symetric rails because they would then create a crossing without room for signaling, the only way to have the maximum density in the very center is to have some rails and some signals, but this then means there is no center of symetry. junctions are mysterious though i'm not certain of the explanations

[hansjoachim]

The difference from delta is that delta won't deadlock. The safe outputs needs to be after crossings, not mergers.

The extended Symmetrical Cross will only deadlock if one of the outputs becomes blocked while a train is on the junction, pathing there, and unable to repath. This can happen with basically any intersection, but with the extended Symmetrical Cross the weird buffers at the outputs increase this chance a lot (though the output still needs to become blocked). This doesn't mean that it is unimportant, as changing the rail network in your base can cause this.

A similar situation can happen if the output is not blocked, but in this case the train that occupies the intersection will be able to leave after a while (even without the repathing that also occurs after a while), and the junction will be normal again. I wouldn't call this a deadlock, and "temporary deadlock" sounds like a contradiction to me.

The difference to properly signaled intersections and yours is that if one output is blocked trains can still use the intersection to other directions. While in yours if one output is blocked it can block the intersection for all trains.
The difference from what you are doing and just not using safe outputs are the same.

[Tallywort]

I don't think ramps will necessarily make this thread obsolete. Even with them there will still be size vs throughput optimisation to be had. Though perhaps not as many ways to really push throughput alone.

Maybe a throughput / tiles used metric could be useful?

If only you could floodfill landfill, then getting the amount of tiles within the intersections boundary would be easier.

[mrvn]

I don't think ramps will necessarily make this thread obsolete. Even with them there will still be size vs throughput optimisation to be had. Though perhaps not as many ways to really push throughput alone.

Maybe a throughput / tiles used metric could be useful?

If only you could floodfill landfill, then getting the amount of tiles within the intersections boundary would be easier.

Ramps only allow rails to cross over each other. If you want left/right turns you still need an intersection and have interference from one track to the other as trains take a turn. I think ramps will revamp this thread with a whole lot of new intersection designs where ramps are used to minimize intersections of individual tracks.

[MeduSalem]

I don't think ramps will necessarily make this thread obsolete. Even with them there will still be size vs throughput optimisation to be had. Though perhaps not as many ways to really push throughput alone.

Maybe a throughput / tiles used metric could be useful?

If only you could floodfill landfill, then getting the amount of tiles within the intersections boundary would be easier.

Ramps only allow rails to cross over each other. If you want left/right turns you still need an intersection and have interference from one track to the other as trains take a turn. I think ramps will revamp this thread with a whole lot of new intersection designs where ramps are used to minimize intersections of individual tracks.

Not necessarily. You can build windmills or clover-leaf designs such that you don't even have interference from "weaving". It is completely interesection-free. ^^

example

De Nul 201210102413 Lummen.jpg (2.18 MiB) Viewed 4140 times

Untitled.jpeg (87.9 KiB) Viewed 4142 times

There are other designs that achieve it in a similar way if you don't have more than 1 level of crossing.

So it is entirely possible with 2.0 to build crossings that have no interference... except for the delays caused by "merging".

Except if you meant the problem of "merging" in particular, because that obviously can be solved if you just don't merge the traffic and keep the tracks separated. And allow a track change only at specific points.

That said nothing really beats a point-to-point connection; where each connection is its own separate train network. And that is kinda more viable with 2.0 as well since you can cross over anything you want if you have enough space to build all the ramps. ^^


Anyway I agree. the thread will still be valuable because there will still be lots of ways to increase throughput people haven't thought about... yet.

[hansjoachim]

I don't think ramps will necessarily make this thread obsolete. Even with them there will still be size vs throughput optimisation to be had. Though perhaps not as many ways to really push throughput alone.

Maybe a throughput / tiles used metric could be useful?

If only you could floodfill landfill, then getting the amount of tiles within the intersections boundary would be easier.

Ramps only allow rails to cross over each other. If you want left/right turns you still need an intersection and have interference from one track to the other as trains take a turn. I think ramps will revamp this thread with a whole lot of new intersection designs where ramps are used to minimize intersections of individual tracks.

Not necessarily. You can build windmills or clover-leaf designs such that you don't even have interference from "weaving". It is completely interesection-free. ^^

example

De Nul 201210102413 Lummen.jpg
Untitled.jpeg

There are other designs that achieve it in a similar way if you don't have more than 1 level of crossing.

So it is entirely possible with 2.0 to build crossings that have no interference... except for the delays caused by "merging".

Except if you meant the problem of "merging" in particular, because that obviously can be solved if you just don't merge the traffic and keep the tracks separated. And allow a track change only at specific points.

That said nothing really beats a point-to-point connection; where each connection is its own separate train network. And that is kinda more viable with 2.0 as well since you can cross over anything you want if you have enough space to build all the ramps. ^^


Anyway I agree. the thread will still be valuable because there will still be lots of ways to increase throughput people haven't thought about... yet.

Atm we can already achieve max throughput. There is no more throughput to gain. But instead of making loops or buffered intersections people wants smaller intersections which are heavily throughput limited. With ramps you don't need to make those unbuffered intersections and you can just ramp over everything, basically the same as just using loops. With loops I mean not having a trains cross other train, only merging.
Ramps add nothing new to achieving higher throughput, it just makes things easier, smaller. Therefore I wish there was a downside to throughput for ramps, like reduction in train speed pushing people to mix it up.

[mrvn]

I don't think ramps will necessarily make this thread obsolete. Even with them there will still be size vs throughput optimisation to be had. Though perhaps not as many ways to really push throughput alone.

Maybe a throughput / tiles used metric could be useful?

If only you could floodfill landfill, then getting the amount of tiles within the intersections boundary would be easier.

Ramps only allow rails to cross over each other. If you want left/right turns you still need an intersection and have interference from one track to the other as trains take a turn. I think ramps will revamp this thread with a whole lot of new intersection designs where ramps are used to minimize intersections of individual tracks.

Not necessarily. You can build windmills or clover-leaf designs such that you don't even have interference from "weaving". It is completely interesection-free. ^^

First: Those examples use ramps. And making this kind of example is what I'm revering too as "a whole lot of new intersection designs".

Secondly: The examples have lots of intersections. Every time one of the curvy bits merges back to the straight that is a point where traffic from one direction will interfere with traffic from the perpendicular direction. Also if you build the same with rail tracks then you need explicit lane changes, more intersections where interference happens.

So you might want to first split all lanes, then raise them with a ramp and then cross over the straight tacks instead of having lane changes.

Ramps might be interesting for train stops too. You could have raised tracks and then ramps down to train stops.

[PavelH]

While waiting for 2.0, I've been trying to adapt 'Parallel multicross 4lane' into a T junction.

The result is a bit smaller than 'Multifork' while getting a slightly better score (127 total - set1 146, set2 108).

https://factoriobin.com/post/MkKtJJXI


Is there any obvious issue with this design? Any easy improvements?

[hansjoachim]

While waiting for 2.0, I've been trying to adapt 'Parallel multicross 4lane' into a T junction.

The result is a bit smaller than 'Multifork' while getting a slightly better score (127 total - set1 146, set2 108).

https://factoriobin.com/post/MkKtJJXI


Is there any obvious issue with this design? Any easy improvements?

If you could add a high quality picture I could check it out with my phone. The Factoriobin picture isnt good enough, I can't see the difference between chain and rails. Overall looks good though, should probably cut some signals on input lanes and you can cut quite a few without losing much tpm.

[Avona]

Is there any obvious issue with this design? Any easy improvements?

First of all, well done. Your adaptation is well thought out.

I haven't been playing too much Factorio lately and your intersection tickled my fancy, so I rebuilt it from scratch to see if I would do anything differently within the boundaries set by your intersection, which is to say, same spacing, same size, and parallelized. Some of my goals were to get as many tpm as possible, remove excess signals, and remove the curvy bits on the west and east branches.

The main way I saw to increase the tpm was by adding more space to the central diagonal crossing rails. Your design had nearly exactly 6 train cars of length, which means that trains will be braking in the way of other trains as they cross paths.

Buffer Lengths

Your current intersection:

My modified version:

You also didn't use all of the rail space which may have affected throughput:

Image of Extra Utilizable Space

It's there... why not use it? Also if you make the branches more symmetrical, some would consider it to be more aesthetic.

I also noticed that you have a lot of signals in general. Hans already pointed out the excess rail signals. I'll just point out the useless chain signals.

Chain Signals

Multiple chain signals in a row without any junction between them (such as a crossing) do absolutely nothing. In the picture, the green circled signals are great. The red circled signals can be deconstructed.

Contrary to popular belief, chain signals before splits do nearly nothing. As trains brake, they repath, so the effect of chains that they force the train to choose an empty path isn't so useful in an intersection. If both paths are backed up, a chain signal isn't going to help. More generally, the chain signals will cause incoming trains to wait slightly longer before crossing their blocks. They reduce tpm by a tiny bit. Chains before a split are mostly useful for stackers, btw.

As far as the curvy rails, I didn't have any issues getting the rails to cross. They're offset from the other rails a bit, but that's alright.
My version: https://factoriobin.com/post/MO4eAHP9

Picture of Modified Version

At the start, I retested your version to get the baseline. It was the same as you stated, which is good. I tested my modified version, which got a score of 139.43, set 1 of 151.93, and a set 2 of 126.93. Set 1 was a modest 4.3% increase to throughput, so you did very well with your design. My set 2 mostly synchronized, so I got a 17.2% increase to tpm there, which accounts for most of the overall score increase. However, most traffic won't be crossing traffic and synchronize like my version does, so I wouldn't worry about it. I was honestly surprised since I haven't seen trains synch in awhile, lol.

Test Results

Your intersection:

My version:

And looking at the time stamps, it seems I took two hours to build my version lol...

Anyhow, if you want to submit your intersection for the forum post, feel free (of any version). I'd like to encourage you to make the right handed traffic version as well but it's not required if you don't want to. We're kinda winding down on submissions for this post as 2.0 slowly approaches and makes these intersections obsolete.

[mrvn]

Multiple chain signals in a row without any junction between them (such as a crossing) do absolutely nothing. In the picture, the green circled signals are great. The red circled signals can be deconstructed.

I think the earlier a chain signal is in a series is the better. The game will reserve a stretch of chain signals in it's entirety so for reserving it doesn't matter where the middle chain signals are. But when the train crosses it frees segments as it leaves them. So the earlier the chain signal the earlier the previous segment gets freed for a crossing train, right?

[Avona]

I think the earlier a chain signal is in a series is the better. The game will reserve a stretch of chain signals in it's entirety so for reserving it doesn't matter where the middle chain signals are. But when the train crosses it frees segments as it leaves them. So the earlier the chain signal the earlier the previous segment gets freed for a crossing train, right?

Yes, you want to put the chain signals as early as possible unless they're the entry chains. Since chains through blocks with no crossing rails will not release a crossing train sooner, the later chains are effectively doing nothing.