|
|
| Line 1: |
Line 1: |
| − | {{Merge|Signalling}} | + | #REDIRECT{Signals} |
| − | | + | |
| − | OpenTTD currently has 4 basic signal types. These 4 are:
| + | |
| − | [[Image:Signals_basic.png|center]]
| + | |
| − | | + | |
| − | Each of these 4 signal types has different properties and should be used in different circumstances. An overview:
| + | |
| − | {| style="border:1px solid black;" border="1"
| + | |
| − | |-
| + | |
| − | ! Signal
| + | |
| − | ! Type
| + | |
| − | ! Direction
| + | |
| − | ! Comments
| + | |
| − | |-
| + | |
| − | ! Standard single
| + | |
| − | | Block
| + | |
| − | | One-way
| + | |
| − | | The standard signal for one-way tracks, and therefor the most-used signal in coop games.
| + | |
| − | |-
| + | |
| − | ! Standard double
| + | |
| − | | Block
| + | |
| − | | Two-way
| + | |
| − | | Arguably the hardest signal to use properly. Standard double signals have an EOL property that means that if they are red, the pathfinder considers the signal the End Of a Line, thereby discaring its route. This property can lead to very unexpected and unwelcome behaviour. Use with caution.
| + | |
| − | |-
| + | |
| − | ! PBS 1-Way
| + | |
| − | | Path-based
| + | |
| − | | One-way
| + | |
| − | | The bath-based version of the standard single signal. In general, use this instead of the PBS signal. However, whenever path-based signals are nog strictly needed, use the standard single signal instead.
| + | |
| − | |-
| + | |
| − | ! PBS
| + | |
| − | | Path-based
| + | |
| − | | Two-way
| + | |
| − | | While this path-based signal can be driven two-ways, it does have a preference for one direction. This preferred driving direction is indicated by the single signal pole and is the same as with the PBS 1-Way. Driving a PBS signal the wrong way gives a massive penalty in the pathfinder. This is the reason why we commonly use the reversed versions of these signals as penalties in our games.
| + | |
| − | |}
| + | |
| − | | + | |
| − | The two block signals themselves have specific versions, called pre-signals. More about those can be found in [[Presignal Basics]].
| + | |
| − | Path-based signals themselves have their own unique features, which are detailed [[Guides:Advanced_Signals|here]].
| + | |
| − | | + | |
| − | = Using standard two-way signals =
| + | |
| − | While used in combination with the default YAPF pathfinder, two-way signals have a weird and often misunderstood property. This property, called rail_firstred_twoway_eol, means that if the first encountered signal is a red two-way, that signal is considered a dead end. Now to understand the impact of this, one must first understand the basics of YAPF. In a nutshell: YAPF calculates all possible routes, called paths, from the train's current position. Each path is evaluated to a single score, determined by the length of the path, obstacles like stations, roads and hills, and upcoming red signals and ofcourse the ability to reach the destination (station). The train then chooses the path with the lowest penalty score.
| + | |
| − | | + | |
| − | Consider the train is on a junction and has multiple exit possibilities. The issue with red two-way signals is that if the first signal on a path is a red two-way, that path is not evaluated at all as it is considered a dead end. You could say that the path gets a penalty score of infinity. This also means that any other possible path, if it exists, is automatically better than the two-way path. Even if the other possibility is a trivial, detouring or outright useless path.
| + | |
| − | What this means in practice is:
| + | |
| − | * If all possible paths start with red two-way signals, the paths are considered equal and a choice is made without considering the network after the signals.
| + | |
| − | * If there is a single path not starting with a red two-way signal, that path is automatically chosen without considering the usefulness of the path itself.
| + | |
| − | Most important is that a choice is made without looking ahead at all. This includes checking if the chosen path actually leads to the desired destination. This can cause massive problems in our games, with games detouring or even driving themselves into a station or actual dead end.
| + | |
| − | | + | |
| − | Now is the EOL property a setting that can be changed. However, on our servers it is always on, as it gives trains the ability of free choice. If two different paths share a destination, but are considered by the pathfinder to be very unequal penaltywise, with single signals a train might decide to take the path with the lowest penalty, even though that means waiting for a red light. With two-way signals this will never happen.
| + | |
| − | | + | |
| − | In short:
| + | |
| − | * Only use two-way signals when you understand their workings and use. Otherwise, use single signals.
| + | |
| − | * Only use two-way signals in situations where each path has the same destination but a possibly very unequal penalty, and where it is important for the train to make an indiscriminant choice. You can think of mergers and SLH joins. But please remember that you don't always have to use them. If you can avoid them, do so.
| + | |
| − | * Especially avoid two-way signals when not all of the exits are two-way, and not all paths lead to the same place. The most common error is combining a double bridging of a mainline with the exit of a track.
| + | |
| − | * The exception is ofcourse for track that actually has to be two-way, like the signals next to platforms in terminus stations.
| + | |
| − | * Two-way signals can also legitimately be used in logic systems and the creation of priorities.
| + | |
| − | | + | |
| − | = Combining block and path-based signals. =
| + | |
| − | Path-based signals and block signals work with two totally different systems. Yet they have to be able to work together, as they are used next to eachother in the game. The most important difference is that path-based signals reserve only a path, while block signals reserve an entire block. A block is a set of tracks surrounded by signals, while a path is a sequence of track sections in such a block.
| + | |
| − | * If all signals allowing entrance to the block are block signals, the block itself is a block-block. A train can only enter if the entire block is empty. There are no reserved track sections, except those underneath the train itself.
| + | |
| − | * If not all signals allowing entrance to the block are block signals, the block itself is a path-block. All trains entering the block reserve their entire path, even normal block signals. However, trains coming from a block signal can still only enter when the block is empty, while trains coming from a path-based signal can enter as long as their wanted path is free.
| + | |
| − | This way, it is very easy to combine the two types of signals in-game, but in complex track blocks thought should be given to the correct choice of signal type.
| + | |
