Difference between revisions of "InvertibleSignals:Alpha"

From TTWiki
Jump to navigationJump to search
m (Bot: Automated text replacement (--= +==))
(Reformat and update)
Line 1: Line 1:
 
Invert the one-way/two-way routing behaviour of selected signals.
 
 
=Invertible Signals=
 
 
Invert the one-way/two-way routing behaviour of selected signals
 
   
 
'''2.6 alpha 1775 or later'''
 
'''2.6 alpha 1775 or later'''
Line 32: Line 28:
   
 
This feature was contributed by Jonathan G. Rennison (JGR).
 
This feature was contributed by Jonathan G. Rennison (JGR).
  +
[[Category:Patches]][[Category:Infrastructure Patches]][[Category:TTDPatch]][[Category:TTDPatch Manual]]

Revision as of 16:11, 15 June 2011

Invert the one-way/two-way routing behaviour of selected signals.

2.6 alpha 1775 or later

Switch

Configuration file: isignals on/off

Command line: -ZP

Description

Currently the routefinder treats one and two-way signals differently.

A one-way signal will always be taken if it is the best route, but a two-way signal will be taken if it green and others are not, even if it is not the best route.

The latter behaviour is particularly useful at station entrances, where an empty platform is preferable even if the chosen platform is not the closest.

This switch enables this behaviour to be reversed, such that the routefinder will treat a one-way signal as it would usually a two-way signal and vice-versa.

This is useful mainly when the current one or two-way signal types are not suitable, as the (lack of) bidirectionality causes a problem.

An example is a monodirectional station: ordinary two-way signals on the input sides may allow trains to reverse out (particularly if reversing at stations is turned on), but an inverted one-way signal does not allow this behaviour and exhibits the same routing behaviour on the input side (empty platforms/green signals are preferred).

The signal GUI is used to set this property. ExperimentalFeatures:Alpha. The button to use is that to the right of the autosignal button.

In order to visually distinguish these signals, and for an icon to be present in the relevant signal GUI button, a signal GRF must be present which defines the required signal sprites. Such a GRF can be found: here.

This feature was contributed by Jonathan G. Rennison (JGR).