Case Study #1 – Using Multitrack Portals

 

 

Building a multitrack portal

 

In the earlier tutorial section, Introduction to Portals, we discussed the characteristics of portals at some length.  If you’re new to portals, I suggest you check out that section first, then return here.

 

One of topics we looked in the earlier material was a portal’s ability to ‘turn around’ a train and send it back the way it came from.  One serious limitation to this function, however, is that if you opt to turn it on, then all trains return.  There’s no way to selectively have some trains return and others just exit the route.

 

This case study discusses my solution to the problem and offers some further ideas on portal use.  As always, there are additional portal solutions available on the Download Station.  Feel free to investigate them further if necessary.

 

My route, Midwest Central, is busy short line, featuring a double track between portals at each end.  I knew that I wanted to turn around some trains (passenger trains, for example), but I wanted others to just end at the portal.  Since the portal turnaround function can only be either on or off, it really didn’t do what I wanted.  My solution was to have two portals, one of which lets trains just exit the route and the other allows them to turn around and return.

 

Check out the following drawing.  In frame 1, we have two portals side by side.  In frame two, we’re dragging the portal on the left to overlap with the one on right.  In frame 3, the two portals completely overlap, looking very much like one dual-track portal.

 

 

 

Even though the portals overlap, they are still completely separate and must be programmed separately.  Now let’s look at the rest of the junction:

 

 

In the drawing above, we have two portals, A and B.  Portal A is set to accept all westbound trains.  Portal B is set to do several things:  It generates new eastbound trains, and in addition, it will accept westbound trains, turn them around, and send them back east fifteen minutes later.  So, when I have an AI train that I want to exit the route permanently, I let it continue to portal A.  If I want to turn the train, I send it through the C-D crossover to portal B.

 

(Some might point out that a portal has an option to have a train return through another portal.  We could, they suggest, just have the trains exit at A and return through B.  That would be fine, if we wanted all trains to return.  That’s not the case here, however, we only want some trains to return, not all of them.)

 

Here’s how we’d set up the portals:

 

 

Portal A is pretty simple.  It just accepts any train that enters it.

 

 

Portal B is set up to generate a new train every thirty minutes, but it can also accept any train that enters, unload it, and send it back fifteen minutes later.

 

This is a pretty good solution to the problem, but there are, however, some things we have to do to make the junction work.  First, we have to make the C-D crossover one-way, so trains emerging from portal B cannot accidentally get over to the westbound track.  We do that by placing a directional arrow on the crossover.

 

 

Once the arrow is placed, there’s another thing to consider.  With trains crossing from C through D to B, we have a potential head-on situation with trains emerging from the portal.  With that in mind, we have to guard the crossover with a signal at E, so that if an eastbound train is in portal B, or anywhere between B and D, we prevent a train at C from taking the crossover.  Conversely, once a westbound train at C takes the crossover, we cannot allow a new train to emerge from the portal.

 

 

Since the turnout at C is to the left, we must use a left-divergence signal, in this case a USA L02.  On the other side, at D, we use a USA 04, an absolute signal, since want trains to stop for certain on red.

 

With the junction signaled as above, the only time a train at C will get permission to take the crossover is when track from D into the portal is clear.  If there’s a train coming out of the portal, the crossover train is held at C.

 

Regulating crossover speed

 

It’s optional, but let’s also add our ISS, the Invisible Speed Signal we discussed earlier.

 

 

By linking the ISS to the XO-W1 switch and setting the left direction, we tell the control to set the speed limit to 25 for trains taking the crossover toward portal B.  Trains going straight through, to portal A, will not be affected by the speed restriction. 

 

The distance between the ISS and XO-W1 is determined by the mainline speed.  The higher the mainline speed, the further from the switch the ISS must be placed, so the train will have adequate time to slow down before taking the crossing.

 

Distance restrictions with signals and portals

 

In our example above, we placed the crossover and the signals placed near the portals to make it easy to see everything.  When we actually place them in a route, however, they have to be further away.

 

In the earlier article, An Introduction to Portals, we noted that when you have switches or signals near a portal, it’s critical that they be placed at least one train length from the portal.  Why?  Because the portal itself controls the train until it’s almost completely out of the portal.  Any signals you have near the portal will have no effect until the portal releases the train to the AI.  Here’s what can happen if a junction is placed too close to the portal.

 

In the drawings below, we have train on the right hand track, heading for the portal on the left track.  In frame 1, we see the train has stopped at the signal, waiting for clearance to the left track.  The switches are aligned for the crossover.

 

 

In frame 2 above, a new train has begun to emerge from the portal, but because the game AI does not yet have control of the train, the switch on the left track is still facing the crossover.  In frame 3 below, the train is almost to the switch, but the AI still does not have control of the train.  In frame 4, the train takes the crossover, in clear violation of the directional arrow, and heads toward the waiting train.  Notice in frame 4, that the switch for the left track is still facing the crossover.  (See the red arrow at the left of the frame?)

 

 

In frame 5 below, the train is about to collide with the waiting train, when suddenly the left switch changes, now facing the mainline instead of the crossover.  That, of course, derails the train.

 

 

Moral to the story:  Keep any switches or junctions at least one train length from your portal or you may have an accident.  :-)

 

Now here’s a real route example from Midwest Central, the East Shelton portals.

 

 

In the picture above, you can see the twin portals in the background.  The crossover is in the foreground and serves double duty in that it provides a way for eastbound trains to reach the Jackson Coal Mine, which branches off to the left just ahead.

 

The signal is from the Robert Nueman’s Northeast Corridor series, based on the USA east coast, a fine collection of mast and gantry signals.  They are available on the Download Station, search for ‘Northeast Corridor’ under trackside accessories.

 

Click here to return to the main menu

 

This tutorial is Copyright © 2006, Chuck Brite. The text and pictures presented may not be copied or posted elsewhere. You may link to this page, but posting elsewhere is prohibited.