by scobos

Overview

Yield Lines are temporary extra tracks than run parallel to a ML or SL. The idea is force slow(er) trains to move to the side and allow fast(er) trains to pass.

Development

Any help is welcome on the idea or the write-up. There is a sample save game of both Fail Safe and non-Fail Safe varieties: File:Yield FS.sav or File:Yield non-FS.sav

The Concept

Yield Line Concept

Often a ML or SL can become slightly jammed by the presence of slower trains. This can happen when trains are out of date and haven't replaced yet, or simply when they are carrying full loads back to a drop on the same line as empty trains. Ideally, we would be able to separate trains to different tracks based on speed. Since currently this is not possible, a theoretical work-around is to separate trains based on Gap Distance.

As a slower train continue down a ML or SL, traffic builds up behind them, but a Gap opens in front of them (as faster trains move ahead). Therefore, we can assume that if there is a large Gap in front of a train, and no Gap behind it, it is probably a slow train. Now the only question is how to sort it.

The Logic

Yield Line Logic

Q is the Entry Combo Signal that determines whether a train can continue on the ML or must go to the Yield Line (YL). Note the penalty on the YL.

Using Osai's definition of 0 for Green and 1 for Red:

Why These Inputs Matter

X: If there is a train behind us, we might be slow and should consider yielding. If there is no train behind us, we probably aren't slow and can continue.

B: If there is a train right in front of us (who didn't yield), we probably aren't slow. If there is no train right in front of us, we might be slow and should consider yielding.

C: If there is a train on the YL, he might be slow and we should try to pass! (Continue on ML) If there is no train on the YL... well, this by itself doesn't really tell us much! Also note that if we don't check for trains on the YL, as soon as the first train Yields, the ML becomes clear... which could result in every train taking the YL.

So the logic, first in words, then formula, is that we want: (Train Will Yield) if (Train is Behind) and (No Train on ML) and (No Train on YL) Q = X NAND B NAND C

which is the same as saying: (Train Will Yield) if (Train is Behind) and [No Train on ML or YL] Q = X AND (B NOR C)

Truth Table: A = (No Train on ML or YL) = B NOR C

The Construct

Yield Line in Action

Using the Logic Train newGRF and Osai's NOT and OR Gates, I was able to construct a sample Yield Line.

X should be placed more then 1 TL and less than 2 TL from Q. B and C can test as far down as you'd like (I used 2 TL). Don't forget a Penalty on the YL.

Currently, there are two main flaws, and two areas I haven't started work on. First flaw: the lead train in a group of all fast trains will yield to the other fast trains, and if using a simple prio to rejoin, will get passed by every train in the line. Unfortunately, this is a core design flaw. Second flaw: like most logic gates, this needs a Fail Safe, but it is fairly in-elegant to place it so close to "X," as I was forced to do to get the prototype working. Someone with a better idea for a FS (or a better way to check for X) might fix this. The area I haven't worked on yet is the re-join down the line. In the save-game, I put in a simple prio, but this is in-elegant. There should be a precise gap in the prio to allow for the situation (Flaw 1) of a fast train needing the re-join the head of the line and not yield priority. Second new area - it should be possible to queue slow trains in the Yield Line by using a more elegant check for C and having a better re-entry system. Even further, you could use this as a sorter to segregate fast and slow trains on different lines, if a method was developed to allow the fast trains in Flaw 1 back onto the correct track.

Pros:

Catches slow trains that are jamming the ML

Allows overtaking

Cons:

Low/Medium Traffic: Lead trains always yield

Progress on Yield Line