4-way intersections: Throughput and deadlocks [image heavy]

[aaargha]

welp. here we go again.

I don't know what to think of this. half of me wants to say this is the ugliest fix I've ever done lol

now every intersection is in its own block. 2 can go straight, 2 can turn left, 4 can turn right, and 1 can do a U turn

I could have just gone with other intersections, but this is the first (and only) track design I've made. I at least want to make it work right.

for the record, this uses: 416 straight rails, 64 chain signals, 5 big electric poles, and 4 rail signals. this thing is signal-hungry lol

Added as "Improved-er reverse roundabout". Deadlock rating is the same but performance is much better. It looks like a total hack, I love it

Which would that be? And how?

The problem is that a train can not cross a block that is already reserved/taken (by itself). This happens in a round about when the train takes a 270° turn. For short trains this would be fine but for long trains the train would hit itself.

Most round abouts are designed so a 270° turn has a shortcut, turning it into a 90° turn the other way. But when the train has already entered the round about and then re-paths to a 270° turn then it deadlocks. Afaik the only way to fix this is to have full signals inside the round about, which means 1) making it big enough to hold full train between signals and 2) has other deadlock issues.

Yep, that sounds like the common roundabout deadlock which often features in the deadlock examples in the OP.

There are a few designs that are resistant (be sure to read the included caveats) to this however: the simplest A rated is "Roundabout safe" which, while safe, is pretty shit performance wise; a better alternative is "Buffered roundabout MK2" (see the thread linked as original for more details on the design) which is an improved version of the B rated "Buffered roundabout".

[mrvn]

Which would that be? And how?

The problem is that a train can not cross a block that is already reserved/taken (by itself). This happens in a round about when the train takes a 270° turn. For short trains this would be fine but for long trains the train would hit itself.

Most round abouts are designed so a 270° turn has a shortcut, turning it into a 90° turn the other way. But when the train has already entered the round about and then re-paths to a 270° turn then it deadlocks. Afaik the only way to fix this is to have full signals inside the round about, which means 1) making it big enough to hold full train between signals and 2) has other deadlock issues.

Yep, that sounds like the common roundabout deadlock which often features in the deadlock examples in the OP.

There are a few designs that are resistant (be sure to read the included caveats) to this however: the simplest A rated is "Roundabout safe" which, while safe, is pretty shit performance wise; a better alternative is "Buffered roundabout MK2" (see the thread linked as original for more details on the design) which is an improved version of the B rated "Buffered roundabout".

Resistant just means Murphy will wait for a moment that causes greater harm. "Roundabout safe" is the one without any signals inside. So it's all one big block. Afaik that is the only way to prevent the re-path deadlock. But then long trains crash into them self.

So until that bug is fixed in the game for me roundabouts are out.

[aaargha]

Resistant just means Murphy will wait for a moment that causes greater harm. "Roundabout safe" is the one without any signals inside. So it's all one big block. Afaik that is the only way to prevent the re-path deadlock. But then long trains crash into them self.

So until that bug is fixed in the game for me roundabouts are out.

In a very narrow meaning of the word, sure. I was leaning more towards "not affected or harmed by something".

The single block crash is usually easily avoided by making the circle longer, it is also one of the earlier mentioned caveats.

I encourage you to take a closer look at, and try to break, "Buffered roundabout MK2". So far it has justified its A deadlock rating so you and/or I will likely learn some new tricks. If you manage to deadlock it, please share how you do it and I'll gladly do a re-evaluation.

[mrvn]

Resistant just means Murphy will wait for a moment that causes greater harm. "Roundabout safe" is the one without any signals inside. So it's all one big block. Afaik that is the only way to prevent the re-path deadlock. But then long trains crash into them self.

So until that bug is fixed in the game for me roundabouts are out.

In a very narrow meaning of the word, sure. I was leaning more towards "not affected or harmed by something".

The single block crash is usually easily avoided by making the circle longer, it is also one of the earlier mentioned caveats.

I encourage you to take a closer look at, and try to break, "Buffered roundabout MK2". So far it has justified its A deadlock rating so you and/or I will likely learn some new tricks. If you manage to deadlock it, please share how you do it and I'll gladly do a re-evaluation.

"Buffered roundabout MK2" is so large and signaled such that I basically consider it 4 separate junctions and that is how it behaves. The full signals on the inside split the whole thing in 4 parts that can be viewed separately and are I think deadlock free.

[aaargha]

"Buffered roundabout MK2" is so large and signaled such that I basically consider it 4 separate junctions and that is how it behaves. The full signals on the inside split the whole thing in 4 parts that can be viewed separately and are I think deadlock free.

Hmm, I'm not really sure that kind of analysis is entirely valid. Consider the intersection below, it is based on a standard merge/split and can fit 6-car trains between each corner.

Image

deadlockable.jpg (300.75 KiB) Viewed 10517 times

Blueprint

0eNqVnd1uXDcMhN9lr51Coqg/v0oRFGmyaBdINoHtFA0Cv3vt7DnbtcOT/eaqSFtP5oikSFEj+vvuz49f91/uDseH3e333eH95+P97vb377v7w1/Hdx+f/93Dty/73e3u8LD/tLvZHd99ev7T3bvDx93jze5w/LD/d3ebH9/e7PbHh8PDYX/6+R9/+PbH8eunP/d3T//D+SfvH55+9q+/H978gLjZffl8//RTn4/Pf9UT0htrN7tvT/+s9vh48xOOnXHef737Z/9hCyXPE4rPJ5IfDnf796f/6gFm0bmliJvLOD4inPpild8slghQ/Le64PTf6vXvbDq/FvHrGCf/j/OCXQ1QB7VsWTDLS8weYE79iz364pygSXI/m8RfmyQimPW48DAuMg2MlV5+Sa5FmDwwxpnbC1SLUHmYNAG1YlQXUIWQEVA7s1WJTVUiyEGJJoEnDh/h4y1RUMFOhsNIcCmDIfUcw9ROpucaD3ONuRqbZVzfjuxV6nn/97vDcXu3G+fNLr3e7KL9xJpopdeUcwTa2dbcRK44oLILZPWEVMISoSSeg5eIL+26/UvWYcd1ry8mudXZVGW8NlVUOJTCPMC3YcO1wBG2EWAh16qCtuteVXBc5SZQ7TIq4Tr0CAiL0MJDKS/pqfh1q3vSYdv1CHAcWFvhGpnITUb16yZynKPyELi6jEq4Vt2dwgrfeaV33vANuFPXYR24E89OG74fmmjKqHbdRBVHlCXOtWYZlXClp6jnquMZ1CagWuTzcknXXau6DmvXXatWufAxsAZNRk3AXDi6zASuQ0YlXIV8tWyABir2lmTY12wjL2hZTv7p+so2U1ENFNUNx5e5wNXZVnDeCTowlpCtll3LQNXemg4LqvbW1YxtoKxsQ0YFZWXj0VXWJQDVYE86LKgGu9D1M4Gt6bCEbVFTrYF6sLuMCurBjiOsbKxA1AnqOMCKC6g4vkoTUHF8lSGg4vjyxFEH7wUK1ho4ulyw1sDB5YK1Bo4tF6w1cGxVxVo8e52DCxyRRtNhwRFp8JPXWhYgtkOHJWynWnMaOCTNJKOCQ9LMsN9W14abOWm5Tp6+ztssOCfNosOCc9LUb3sRW72hgdg2tUY2cFKaXUYFJ6XJQ2xNjBmclOaUYQ2clHLiNaINTjenLOMyvjjMtvy2hrBFhc3gbJcTPIb5cgzLE9xrJyGTrSZrxGRNxx3EZF0+hjC+Q8dFfHk221iG0MVykmHB0TFnuV5Ei5sNpklb02T+ScUT8y2wSenLxXQuBNXlMiw7WQa9aszgUJq5NGMrJGIf6zKsk9WF6ibNZFOubDIocbMlHRfUuJmrNLY8LDSZmQwLqtwsSDXOZUgiq+s6rpHVrWqTIhtZXbn3kRNZ3S6nSlI02dAzMCmauHBjyxfCxeUyjhWW1EwXKg6WIEjWKfx0tjZrQuVKpnKNH0KdBYioW3OBpWKZ61eHKJIEqoxLjiFeUztnG8vW5fVvMdCA6///tzUiw8kXigyycm0TPYxsLsxY1zH+fK7EOK9jLAkWxBfr4Zd8ZlE/c4Ody58Z64oFhUULPzP0FUFucUIlOYWLLRb9AknXutSCJGvX++mhdS7EFWirL2AfrXKEpJgbFVPMiFpoDEFK4ZGFQ1+sTl8ecJ74CceyCf6kSQ295kJF8UumPSIaq+a7smePLbZhOHIdxaJOI4XYhYyCJPkC7N/UzBK7e5PDJg7pZrQ+Wqxhr60Rv2QoiqVz0sBdXMKNT6/qEsbJ70IQQfTG50LHURS2Lm5CTlZwiC9NEOjUXoUQTC6J4Dy5HoIvKBdDNI5ZNPU2wnRxl0SgFT5dOfk98fre2LZ0rusdJQkugvD0i4jnqod154hPB32q/QPSVBxJ2o/OB9+Gzr1c77ByJk0ErndYWhOkPcPlDgso6QRfqB1+7ZnjYllDoCr6YuxDo9Ga/PTAL2fiQl3tGpIblSFftaLmHlczLD1D1DjlaoYFlVxVzSzVk8hWupABNQt1IQPqc3Mhw9I+R3cIUxXioTbslLVCqMc9uwxLLn24kGG5S0IXalzHsKKChoQl3EhYAqGTp77CkaiFKxBzNfXamtwjWSoyLLhetuTirTW5XTYuYVhR0co2MT8zrqrQlXGlfWxfD8q5kj62pakKb8jNsmVZJ0QEMsbVC4vuhoiPLKsiIXJnb3ygxJrAEFdXURFXWYhHNCyW5SEsRDJnWVXiES2i8akSFtsrXtkplgaIKxctrCmccLWsyn2JWM7MZFhQyhmXLCx6X6J4Ni5YsNhe8cpWsYxhXFVVEOPaaapZx/8Y6puaIFfYsFjsXlOGBfWsFfUlL3m0ZEV9yUv0zsblCkuyZVyLioq48rvaGpsrdC4+a+JNTQIsz2A+BNiunhUYrNAYdAF2ypc9BFaYPuGCyVzuEDJYU7tHDFbuczBYes1rpxOuga64ufyil7zbMZdf9JJHsubqi17y+thcfdFLHkSZw4teWxJuB99fk1x8kyOYIJjYWNfQCarJsIhtER/hGxoc5ioqOYTVKtfJ5BBWmwpLJjxYlQdjMrZDhWVsp6hfI0NJjIspcmyw0A+a/GCejHiwJj+YJ0NkrBV16A9j6zIsYltFgRuZe2R8JkWODRb7QVfzIhn4Yor4YoEl56UmjyhDbLs8ogyx7eqIMjJOzbo6oozMKLKujnwp8TDp7mqKJbOpjE+hOMOS8q03dTojY9tlWMR2aGIZMp/SuD4jNlfoTXwMxepNoQjFBCHGmqhJHThMm4xdJljIoc52ZlRdmkLNmFIt7So8Ko3I+IzKNOJFDY+YQ1LT+ibfMJ64ViP2rXgRpur6oebFJh2Qvmpwfp7BGq7o61kTv17RJoKb+vEj/ng1ljwRduqcdIaqzklnqOqcdIbaRfkqAh2ifhWBTlHACkALHyzRBNAsDTUnM81LUuMoHmleuABjOd84qGtLgvLAvI6rcSP5owgKjIWtxV8N81A+verwHqOoF8DxL7ooVFVh68uV5yk/MZKaWuJfNlKyWp3Fv1SlCEKJE87zL3l5e3P6vTe3F78m52b3z/7u/jRdxP3ppNst23x8/A+C9KbG

To me it sounds like you'd rate this one somewhere in the A-C range, determined by the properties of the corners?

The problem this design has is that, even if the corners themselves are not really that problematic, it is possible to fully saturate the loop. As soon as 4 trains turning right gets on the loop it'll deadlock, no path-changing needed. I may be reading it wrong but it really does not sound like your method would catch this type of deadlocks.

[mrvn]

"Buffered roundabout MK2" is so large and signaled such that I basically consider it 4 separate junctions and that is how it behaves. The full signals on the inside split the whole thing in 4 parts that can be viewed separately and are I think deadlock free.

Hmm, I'm not really sure that kind of analysis is entirely valid. Consider the intersection below, it is based on a standard merge/split and can fit 6-car trains between each corner.

To me it sounds like you'd rate this one somewhere in the A-C range, determined by the properties of the corners?

The problem this design has is that, even if the corners themselves are not really that problematic, it is possible to fully saturate the loop. As soon as 4 trains turning right gets on the loop it'll deadlock, no path-changing needed. I may be reading it wrong but it really does not sound like your method would catch this type of deadlocks.

Yeah, you can't just look at a network one part at a time and decide the overall behaviour from that alone. I was only talking about the repath issue. The buffered roundabout mk2 is so large that trains never corss their own path. There are multiple full signals in a 270° turn.

The problem (or one of them) here is that you signaled it wrong I think. You have a small loop (4 trains long) with the entries and exits into the loop using full signals. You have to prioritize trains leaving the loop. And then still you could potentially get 4 trains into the loop turning right. But I think that then is a theoretical problem. I think you would have to send 4 trains all turning right at an empty junction all at the same time. As soon as one train is already moving inside the junction it will reserve blocks and usualy prevent a 4th train from entering the loop. But that's just a stab in the dark. Haven't tested it.

[aaargha]

Yeah, you can't just look at a network one part at a time and decide the overall behaviour from that alone. I was only talking about the repath issue. The buffered roundabout mk2 is so large that trains never corss their own path. There are multiple full signals in a 270° turn.

I'll just go ahead an be obnoxiously pedantic about this: the trains can cross their own path, but as you say, full signals make sure that it's not an issue. End result is about the same, I'm just splitting hairs.

The problem (or one of them) here is that you signaled it wrong I think. You have a small loop (4 trains long) with the entries and exits into the loop using full signals. You have to prioritize trains leaving the loop. And then still you could potentially get 4 trains into the loop turning right. But I think that then is a theoretical problem. I think you would have to send 4 trains all turning right at an empty junction all at the same time. As soon as one train is already moving inside the junction it will reserve blocks and usualy prevent a 4th train from entering the loop. But that's just a stab in the dark. Haven't tested it.

Nah, for its intended use it looks just right

As for the deadlock risk, so far no submitted design that can be saturated with just 4 trains has survived throughput testing for more than one or two minutes. For less extreme conditions it'll be mostly fine, probably.

[mrvn]

As for the deadlock risk, so far no submitted design that can be saturated with just 4 trains has survived throughput testing for more than one or two minutes. For less extreme conditions it'll be mostly fine, probably.

Maybe signals without circuit connection should raise a warning when they have a train sitting there for more than 5 minutes. A deadlock is really bad and usually cascades. When you finally notice you have 50 trains blocked and no idea where the faulty one is. Would be nice to get a pointer to the first one stuck before it gets to that point.

[ridesdragons]

that's actually entirely possible.

hook a signal up to a circuit, output a signal (D for deadlock, I guess) if the light is red (train's in it). it gets outputted to a clock, which checks to see if the signal's still red, and, if so, add 1 to the signal. once D gains a value of over some arbitrary number (let's say 30k, since ticks are very fast), it finally outputs a signal to a broadcaster, which sends out a noise and a message to the player letting them know that there's a deadlock, and which intersection it started at

though I don't think this would be very update friendly, as any train that passes through will start up the clock only for it to reset because there was no deadlock. honestly, I'd just deal with an ever-present but extremely low chance or deadlocks happening (unless you use circuits to shut off outposts and you're unlucky with where the train is at the time of shutting off)

[mrvn]

It would also be a lot of circuits to build and you don't always have the space for them.

I mend that signals should do that internally on their own. Should be more UPS friendly to start a timer when they turn red and cancle the timer when they turn green.

[db48x]

It would also be a lot of circuits to build and you don't always have the space for them.

I mend that signals should do that internally on their own. Should be more UPS friendly to start a timer when they turn red and cancle the timer when they turn green.

TheFatController mod does this for you.

[Zijkhal]

At the risk of being called out for necro, I'd like to thank OP for the amazing work, it helped my understanding of rail intersections a lot.

I've just created a new 2-lane intersection I dont see in this post (no guarantees I'm the first one with this though), after taking a look at these intersections and improving upon my prototype based on the principles I could make out from the well-performing ones (train should not be able to change course after entering the intersection, buffers on entry and exit, and seperating the left turns (I use RHD) so two left turns can potentially be performed at the same time).
I'd now like to submit the result for testing (so others can use it if they so please). I've sized the buffers for 2-6 trains.

Image: https://imgur.com/xoc93wd
BP: https://pastebin.com/CZsLdhU9

There are a couple more signals than are strictly necessary, the idea is to make the blocks that contain rail crossings as small as possible, so a train leaving said block is registered as soon as possible, opening up the route for other trains that little bit sooner. Also, at the entrance / exit buffers, I used normal signals, as it does not really matter if a train waits in its designated area, or creeps forward a little, no trains will be moving either way.
Also, I dont expect it to get anywhere near the top two in throughput, you cant really get any better than a buffer after each crossing of rails... Also, unless I've screwed something up it should be deadlock-free, as trains can not change their exit path once they entered the intersection (buffers)

[aaargha]

@Zijkhal: Cheers! I wouldn't worry about any necromancy shaming here, what better place to practice the dark arts than a thread for 4-way intersections?

On a more serious note, I'll still be looking at any submissions/questions/whatever made here for a good while so keep 'em coming.

On to your design: I think you're right in saying that it won't beat the top two, but it should perform pretty much the same as the current third, "Cross". As they're pretty much equivalent I don't really see them differing that much with regards to performance, yours will probably just score a little bit worse as it is sized for trains longer than the 2-4 I'm testing with.

As far as I can see deadlock rating should be A, there are no errors in the signalling. That being said you do have a few redundant chain signals in the middle part, you can take a look here if you want to see which. Alternatively you're missing a few (3 I think) chain signals if you want to make the middle symmetrical.

Over all it's a solid design and you've done a good job of identifying what makes a design perform well. I'm looking forward to any future designs you want to share.

Also, I've added a link to your post from the "Cross" entry as an 8-car variant.

[Zijkhal]

Missing rail signals? Ohh, that... I found that just before I posted, corrected it, even got a shiny new pic from the reddit blueprint mod, and then gone ahead and attached the pic with the missing signals...
At least the BP has all the signals.
Speaking of signals, the extra ones are intentional, it is in an effort to make sure a train will clear the block with a rail crossing faster, freeing up the route for other trains that would use that crossing. But most probably I could take away the ones at the entry without limiting the throughput...
One other little thing I've done in the hopes of achieving better throughput is make sure I use as few crossings as possible, thus the 3-way crossing of rails on the squares rather than having 3 seperate 2-way crossings. But you're right in that it is very similar to the Cross.
Having said that, it just occured to me that I could implement a feature from the Windmill Mk2 that may give it better throughput without increasing its size.

Also, how do you set up the deleting stations? I've done some testing with your mod and the train counter, and it seems the bottleneck is not actually the intersection, but the deleting station itself, rather that trains will slow down right at the exit of the intersection... I've managed to set up a system that spawns new trains as soon as the previous cleared the station (so two trains wont auto-connect), so that part is good.

[aaargha]

That's what I get for being lazy and only looking at the picture, eh?

I think you have the right idea with wanting to free up the crossings as soon as possible. What I mean with redundant signals is like so:

Marked signal is redundant for most cases

redundant.png (63.51 KiB) Viewed 10149 times

The marked signal will not make any difference in "normal" use-cases. The only times it makes a difference, as far as I can tell at least, is if a train would run out of fuel/have all its destinations disabled while the front of the train is between the middle chain signals.

You're probably right that your crossing design should be a bit more efficient than the one used in "Cross", though the difference is likely too small to accurately measure in my setup. It'll be interesting to see how your next version performs.

As for the deletion stations I'm using a bit of circuitry to make "instant stop" stations which helps a bunch. A (hopefully up to date) save with the setup I'm using is attached in the OP, it's just above the results section. It'll probably be easier to see how it works in there than reading an explanation of it

[Zijkhal]

Ahh, thanks, I missed the map download!

You're right about the extra signals not making a difference. But since they dont really hurt it, I wont go back and remove them

I was curious and measured the performance, I averaged the throughput over 5 minutes, and I got 63.4 trains in Set 1, and 65.4 in Set 2, so a slight improvement, nothing groundbreaking. Although, our testing setups may differ, so my numbers may be different than yours if you run the test.
But now that I think of it, it may be beneficial that it is sized for 2-6 trains, and is tested with 2-4, because when these shorter train pull into the buffers, they will brake later, so they will clear the intersection faster. So most of these improvements in throughput may actually be just because of the slightly oversized buffer area.

As for the next one, here it is: https://pastebin.com/BRHSuF6P
And pic: https://imgur.com/5BHdBON

In my testing it did 68.5 in Set 1, and 64 in Set 2, it looks like it likes if all its buffers are used. Although, one problem was clear: at the output buffers, the left turning lane gets the lowest priority, so if other trains keep coming, the train that just completed the left turn will not clear the buffer, resulting in a backing up of trains on the entry side.

I've also tried adding extra signals in the buffers in the hopes of registering if a train starts leaving the buffer area earlier, but, contrary to my expectations, that only reduced throughput...

Ps.: This time I dont have those extra signals

[TRUEpicness]

is it ok that i have changed the 4 lane multicross intersection into a 2 lane (by removing the outer rail) or should have kept it 4 lane (as in prep for 4 lane system)?
just wondering

[aaargha]

is it ok that i have changed the 4 lane multicross intersection into a 2 lane (by removing the outer rail) or should have kept it 4 lane (as in prep for 4 lane system)?
just wondering

I don't really think there is a solid answer to that one, it will change from case to case and player to player.

It's probably a good idea to leave enough room between the intersections so that you can fit the 4-lane version if you plan to eventually upgrade to 4-lane and want to keep the current network. If you're planning on a redesign anyway it won't really matter either way. It mostly comes down to when/if you want to spend the resources to upgrade it.

As for the next one, here it is: https://pastebin.com/BRHSuF6P
And pic: https://imgur.com/5BHdBON

In my testing it did 68.5 in Set 1, and 64 in Set 2, it looks like it likes if all its buffers are used. Although, one problem was clear: at the output buffers, the left turning lane gets the lowest priority, so if other trains keep coming, the train that just completed the left turn will not clear the buffer, resulting in a backing up of trains on the entry side.

I've also tried adding extra signals in the buffers in the hopes of registering if a train starts leaving the buffer area earlier, but, contrary to my expectations, that only reduced throughput...

Ps.: This time I dont have those extra signals

Added a tweaked version as "Windcross". Here are the results for some of the tweaks I tested, edit3 includes changes made in edit2 etc.

Code: Select all

orig  57.9  59.9
edit1 58.5  60.1 fix merge imbalance
edit2 61.9  60.2 increase buffer signalling
edit3 62.6  59.4 shorten to 6-car

It's interesting that we get such different results, especially with regards to adding more signals to the buffers. One would think that, even if we do something that makes the absolute values differ, relative changes would trend in the same direction.

[Zijkhal]

Hmm, interesting... I did my testing manually, I got the train counters, add the results onto the power poles, start the spawners (via changing all 4 triggerers to automatic), wait till all input lanes are backed up (so I have trains that already have crossed the intersection but not yet counted when I start the timer), start the timer on my phone, and write down the number of trains passed, allocate 2-4 seconds for the autosaves at the end, and the (end-start) / 5 is my number over a 5 min test... Not the best, but it seems consistent enough to me...

Here is my setup if you want to take a look at it: https://pastebin.com/graNQFwY

I tested your version, and I got 59.2 in set 1 and 54 in set 2...
Removing the buffer signals lowers the throughput.
Then I retested the one I posted, set 2 only, and got 62 per min...

I have no idea why are we seeing these differences, it may have been me screwing something up with the test setup, I'll make an automated setup that I just trigger a constant combinator, and it starts counting, and stops after x mins and displays the rate of trains directly, and then if the results are similar to yours, then its very likely it was my error that caused the differences.

[Zijkhal]

Allright, I've completed the automated setup, and run some tests on the Windcross version. Six tests to be precise, all the same (set 1), each averaged over the course of 5 minutes.
My numbers: 57.6, 57.6, 60, 61.6, 58.8 and 56.6
There is a difference of 5 trains a minute between the highest and lowest measurements, which imo is pretty big.

Then I did a 30 minute test, and got 57 trains a minute...
Could it be that all these variations are caused by the randomness of train destinations, so a lucky set will have better use of the buffers, and trains will arrive in a pattern so they can always make use of the maximum number of available turns? This may be made even worse by the seemingly random way trains get priority? I know it is deterministic, but I think it is so sensitive to small details, and has very little consideration of giving priority in a way that allows for maximal throughput, it is virtually random.

So this made me curious. I set out to eliminate the random factor from the tests. There are two setups I came up with, one where I seperated the input buffers, each having its own train generator and a single destinaction. The throughput bottleneck this way is pretty much how many trains a single line (the output line) can carry. This way it achieved around 93 trains a minute.
Then I hooked up the three train generators to merge into a single line, and controlled which one is released via circuits, I set them into a repeating pattern of left -> straight -> right, so at any time, four trains arrived at the junction, each doing the same turn (all left / straight / right). I only did one such test, as I dont think the throughput will be any different due to the highly controlled nature of this test and that the intesection never backed up. The throughput was 91.2 trains a minute.

Watching the trains in this second test reassured my suspicion that this intersection actually likes left turns over trains going straight, as it can let four left turns happen in parralel, while only two trains can go straight at any time. Most probably that is why this intersection (and some other) report a higher score in set1 than in set2. The take from this is that the general assumption that left turns (in RHD systems, or, right turns in LHD systems) are bad for throughput is false. It seems, it mostly depends on the type of intersection used.

Armed with this knowledge I started building intersections... The entire day passed, and I did not even get to benchmarking the 8-car Windcross which was the whole point, but at least I got three designs, each sort of iterating on the other. A day wasted well spent.
Here is the BP book: https://pastebin.com/e46k2Ncn
And the pics: https://imgur.com/a/qxpaT

The first one I call Braid, because that is what the lines going straight remind me in the middle, also, that one has pretty bad performance (I dont think its worth benchmarking in its current form), it is more of a proof of concept. I may try improving on it tomorrow.

The second one kinda reminds me of a boat prop... I have not tested it, but it ought to be better than the Braid Mostly due to more buffers. But I'm curious wether the left turning lane cutting straight across two other lanes will work out or not.

Speaking of more buffers, the third one is full of them. The only thing that is not fully buffered is the left turning lane, but that worked out pretty well for the Windcross. On the straight lines, there are two buffer zones where two 2-4 trains can fit... Although, it would be a real pain to extend the buffers that need extending... I have high hopes for this one. And the best thing is, all those buffers barely increased its size.

Ps.: feel free to change the names