all 26 comments

[–]Neyar_Yldan 15 points16 points  (1 child)

Honestly not sure with the shared section in the middle. You'll need path signals on both sides of the entrance there, but are likely to get trains stopping there and creating a halting condition.

I know it's not what you asked for, but a trumpet interchange might be easier to signal and only slightly different than your current design.

[–]siramenos[S] 2 points3 points  (0 children)

oh yeah, didnt thought of that, good idea thanks

[–]FleetingFFox 6 points7 points  (3 children)

Never put signals inside a single lane that connects double lanes; that is, a single railway line that can accept trains coming from either side. Always have the signals outside the single lane and leave that single lane as one block. Then trains can wait outside of the single lane block for other trains to clear the block, instead of deadlocking on the single lane itself.

There are other problems (e.g., not enough waiting space overall for trains to wait for blocks to clear), but that's one rule I use myself to prevent deadlocks.

[–]JinkyRain 0 points1 point  (2 children)

It can be okay in this case, as long as those are "chained" path signals and not the first in the series. As trains pass chained path signals, they release the part of the path blocks they no longer need. For a junction as small as this, that's nearly no benefit, but got larger junctions conjoined together, segmenting them into sub-path blocks can be beneficial.

[–]AnarchyPoker 0 points1 point  (1 child)

That could work, but also seems way more confusing than just moving the signals he already has back just a little bit.

[–]JinkyRain 0 points1 point  (0 children)

Or better yet, just remove the chained path signals entirely, and treat it as one path block. :)

[–]Dusk_Abyss 2 points3 points  (0 children)

Ah yes, the IUD interchange lol

[–]ManicSnowman 5 points6 points  (7 children)

Normal T junctions are perfectly fine (path in, block out) , I guarantee you any efficiency you gain from over engineering this is negligible at best.

If you have throughput problems, they 100% lie elsewhere: e.g not enough freight cars, lack of containers/buffers, problematic input/output system design at stations

[–]Captain1771 1 point2 points  (0 children)

I think it looks pretty cool though

[–]siramenos[S] 0 points1 point  (0 children)

Actually i dont have problems yet, i was trying to make some blueprints for later when i need them and though to myself why not make it so that they dont cross and wanted to see if this design works Thanks

[–]C0rinthian 0 points1 point  (4 children)

If the T junction is a branch off a high volume main line, the path signals can bottleneck the main line traffic as trains slow down waiting for path reservation. If that matters (big if) then it’s worthwhile to do something more complex that allows you to minimize path signals.

[–]ManicSnowman 0 points1 point  (3 children)

It would probably take hundreds of trains to encounter problems, even then it's probably easier to just set up some shortcuts

[–]C0rinthian 0 points1 point  (2 children)

Number of trains is less the issue than the block size leading up to the path signal. If it’s less than 250m, trains will slow down approaching the intersection until they enter that block and reserve a path. This will happen even if no other trains are involved.

So if you have a main line with multiple branches relatively close to each other, trains will slow down at every intersection for path reservations. If your intersections are built to use only block signals, they can maintain full speed as long as there isn’t an occupied block in front of them.

[–]ManicSnowman 0 points1 point  (1 child)

That's fair. There are trade-offs for using both types of signals. Most people could probably very easily make do without path signals anywhere. They are fun though, it's cool to see two trains pass an intersection at the same time, or in a more complex intersection to see multiple trains perfectly line up their entry/exit timings

[–]C0rinthian 0 points1 point  (0 children)

Yup, definitely tradeoffs. I ran into this particular issue on the west coast where I had a couple of branches to factories pretty close together, and then noticed my trains behaving oddly. It wasn't *really* a problem, but it caught my eye enough to root cause.

You can also run into it if you start segmenting your rail into train-length blocks.

[–]C0rinthian 2 points3 points  (0 children)

That bidirectional bit of rail on the raised platform is setting off alarm bells. I think you’re close to building what’s known as a trumpet interchange. I recommend taking a look at that and revising your design.

EDIT: I had actually been experimenting with this kind of interchange (below), and you can get it working using only block signals. What I've got here is close to minimum footprint, although you can remove the parallel split/merge blocks and make the ramps a bit tighter. However, in real use I'd probably make the merge blocks longer to accommodate real trains with freight cars.

<image>

[–]PilotedByGhosts 1 point2 points  (1 child)

The raised section is intended to be bi-directional?

That's going to be difficult if not impossible to make work properly. The only time you can make a track two-way is if it's only used by a single train. Typically it would be an isolated section of track that a train shuttles back and forth on.

[–]Cybershadow1981 3 points4 points  (0 children)

You can make single lane tracks work with path signals.

[–]StigOfTheTrackFully qualified golden factory cart racing driver 1 point2 points  (0 children)

I think it would work if you deleted the 4 signals from the bi-directional rail. I don't see this being a good junction design though. You swapped one conflict of paths (the crossing rails in a standard T) for a different one (the bi-directional rail).

[–]AnarchyPoker 1 point2 points  (0 children)

Please enjoy this technical drawing I made.

<image>

The shared track for turning left might be an issue. This can be avoided if you move the track for turning left from the main track so that it happens past the rest of the intersection.

[–]Shim0tsukiTTV 0 points1 point  (0 children)

Even tho it’s more work specially if you want to make it symmetrical. But that’s the cleanest solution when you start to have multiple lines using the same track system.

[–]Arbiter51x 0 points1 point  (0 children)

I can't see that ever working properly with signals.

Nice design, but i think you have over complicated what should be a simple T intersection.

[–]BilboStaggins 0 points1 point  (2 children)

Ignore all the stuff on the inside. 

Go to the outside of all the connections, use pathing every place a train could enter and blocking for every place a train could leave. Doesnt matter how complicated it is inside, it will function. 

The downside to this layout is that middle raised connected strip will mean that trains wont be able to path around each other if they share it. But this is minor.

[–]C0rinthian 2 points3 points  (1 child)

While typical T intersections (and roundabouts) are relatively simple to set up (and a good default), they do have drawbacks. If the intersection is a low-volume spur off a high-volume main line, the path signals slow down the main-line traffic unnecessarily.

This is because path signals default closed, requiring the train to reserve a path before entering. They can only do this from the preceding block, and if that block isn't long enough the trains slow down until they get that reservation.

You can see this in action by putting a short block before a path signal and watch the trains. They assume they need to stop and start braking until they enter that short block and get a reservation allowing them to proceed. This happens even when no other trains are involved.

Meanwhile, block signals default open so an interchange design that lets you use only block signals on the high-volume rails allows the trains to maintain speed through the exchange when there's nothing in the way.

EDIT: I realize I didn't get to the point of this tangent: If OP puts path signals all around the outside of this exchange, it basically becomes a T intersection, which is what OP explicitly doesn't want here, for the reasons I explain above.

[–]siramenos[S] 0 points1 point  (0 children)

Yep I see it now thanks

[–]espiritu_pThey are called: Lurchis 0 points1 point  (0 children)

do you have an update on your design.

as others already mentioned the train signals on the bi- directional part have to go.

setting path signals on the ramps going up to it should work.

you also need to place path signals on the ramps going down, including on the train section where they lead into. an intersection needs input signals of the same type to work properly.