TK Signal Requirement

(Originally by garyhahn.geo) The reason for the TK to require a signal is that TKs are route dependent. The signal apparently provides a starting point for route determination. If you have a signal onto a facing point switch, which TK "squares" should you light? Clearly the first square and the switch itself, but then what... follow the lined switch route. In fact, you'll note that if you hover over the first square behind a green signal on the dispatcher display, you'll see that the square lists something like A:T>, where the greater than symbol apparently indicates the route determination start point.

If there was no such signal starting point one could argue that logic could be applied to simply pick a spot and work both directions to determine the route, but that has not been implemented (not sure it's even really possible). I think what would have to happen is this for a TK example:

• Pick a spot that is always T and attempt a route.
• If you hit a wrong switch throw, start over, but pick a different T spot and try again.
• If you hit a block division or a different T (such as 2T), quit.

Programming nightmare? Beats me.

If you want to see what I mean, simply convert your TK block to a non-dummy approach block, and you'll see that it becomes ugly right quickly.

I agree that it would be nice if it could be done for:

• Trains talked thru signals
• Missed greens (dropped packets)
• Rail yards with switch and track, but obviously no signals

As for forcing the TK divisions, take a look at the Garrett interlocking on the CSX Garrett sub layout in the files area for example of how to implement this.

-- BrianSwan - 24 Oct 2006