Second, I have a weird observation to throw out there, and a couple ideas on how it could be handled. Intersection relevant. The core concept is, I don't know how "realistic" having trains coming in as fast as they are, is. Packing trains that tightly is honestly not so bad to do in a factory, it's the little loops that get two trains packing the rails. I'm 100% sure they could be used more effectively than I did here, I just got proof of concept with this. So it is possible to have the test conditions, in a real factory. It's effort but not that much effort.
I also observed some weird behavior regarding braking distance, where trains who could split (as these can) will accelerate past the tail of the train in front of them to block the intersection. In s2, if you add in enough rail signals just prior to the first split so they aren't getting that little speed check, "tap the brakes" or speed bump, I call it, they'll actually block three other lanes most of the time! I'll have a video about this soon, and I feel like this is kindof an extraordinary datapoint, because adding three extra rail signals to just one entrance, turns an s113 intersection into an s80, absolutely tanking the s2 score to the 40's. It does not similarly tank s1 or s3!
So, is the test scenario realistic? Yes. Did this intersection (with the extra signals) totally bomb to those testing conditions, testing conditions which it can create itself? Yes. However, I learned something, and maybe it'll be of use to y'all some way, maybe just slap a warning sticker on the hood or something. The testing conditions, if you have a branched input path as shown, could allow some inputs to block others because of braking distance and their speed. The braking distance of the second train gets through the intersection, before the tail of the first train clears. Because the trains are launched and packed as they are, attempting to branch and then cross is what triggers this behavior it seems.
It's hard for me to actually recommend any kind of change, except possibly a toggle for "Packed rail" versus "0 speed packed rail accelerating behind an unblock." Maybe a rate change in the advanced settings? It might be possible to adjust the rate of incoming trains based on the measured rate of train output, see how the intersection responds to its own traffic. The problem is that it's so much easier to say "if you see this, the easy fix is to give them a speed bump." It's not really an intersection problem, the intersection is s113, and by that same token it's not even really a rate problem. It was a speed problem, which only happened because they were packed close enough to accelerate beyond the next train when they could, and this is already an edge case and a half.
It's possible for 4 lane intersections to see this behavior rectified with speed bumps too, I haven't done any testing but if you see intersections where fast trains will blow through a crossing rather than letting a bunch of stopped trains cross, speed bumps seem to be a way to fix the core issue I had without affecting throughput too badly. Particularly because they're coming in too fast and their braking distance is too long, in cases where they split for parallel crossing, a speed bump has a markedly positive effect by slowing the trains down, decreasing braking distance just enough so cross traffic can go. This seems like it could be a useful concept maybe somehow to someone?
Michigan Left, Single Buffer per Crossing, Single Split per Lane
RHD, Size: 499x535, spacing: Weird/adjustable?, Train length: 6 cars
Set1: 127, Set2: 114, Set3: 97
Designed by ichaleynbin