Difference between revisions of "Signals"

From #openttdcoop wiki

Jump to: navigation, search
(wip)
 
(Merged with signalling)
Line 1: Line 1:
Arguably one of the things which gives OpenTTD the possibilities it has, signals are essential to learn in order to construct anything worth mentioning. This page will attempt to you show you the basics of what signals do and how they behave.
+
{{Merge |Guides:Presignals}}
 +
{{Merge |Signal Types}}
 +
{{update}}
  
 +
== Signal types ==
 +
OpenTTD currently has 4 basic signal types (not counting presignals). These 4 are:
 +
[[Image:Signals_basic.png|center]]
  
== Block signals ==
+
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 best place to start is block signals. This is the very most basic signal which does only one thing - is green if the block in front of it is free, and is red if the block is occupied by a train.
+
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]].
  
=== Signal Block ===
 
  
Question is however, what all is a signal block. The answer would be, any place between two signals. This means literally any place, including "senseless" rail combinations.
 
  
===== Self-blocking =====
+
==Placing Signals==
Wrapping rails around the signal, unifying the signal block, can cause deadlocks! This can be used in some special cases.
+
[[Image:Standard signal dragging.png|left|thumb|200px|Basic Signalling]]
 +
Before you start to use Automatic Signalling or Signal Dragging you should check the signal density. You can change it in the signal interface or edit the drag_signals_density value in your openttd.cfg. Make sure the value is set to two.
  
 +
=== Basic Signalling ===
 +
The first thing you should know is how use the basic signal dragging feature of OpenTTD: Build a signal (fastest Shortcut is A & S), left-click it and hold the button, drag it as far as you want to build signals. Release the button and the signals will be built. Very easy.
  
 +
[[Image:Automatic signal completion.png|right|thumb|200px|Automatic Signal Completion]]
 +
=== Automatic Signal Completion ===
 +
Now we are ready to build signals and know how to use the basic feature of dragging. We can go a step further. Again Build a signal and drag it. While you are dragging it a little bit press the CTRL button and release it. The track will be filled up with signals until a breakpoint which are existing signals on the track, stations and junctions.
  
=== Signal directions ===
+
[[Image:Deleting signals.png|left|thumb|200px|Removing Signals]]
 +
=== Removing Signals ===
 +
It's also possible to remove Signals with the Automatic Completion feature. If you have build a track with signals, use the signal deletion function (Shortcut: A & S & R): click the signal, drag it while pressing the CTRL button and all the signals will be deleted. The breakpoints are stations and junctions.
  
It matters which direction is the signal facing - it always detects the block in front of it.
+
=== Breakpoints ===
 +
[[Image:Signalling breakpoints.png|right|thumb|200px|Breakpoints]]
 +
Automatic Signal Completion won't stop at: '''Tunnels''' and '''Bridges'''
 +
but stops at: Junctions, Stations and Existing Signals
  
 +
===Checking anyway===
 +
After you have "signaled" a track, you should optimize signaling at junctions, they might need a signal right before or after the interruption to avoid signal gaps.
  
When you build a two-way signal, it is the same as if you had two separate signals, each of them detecting a different block.
+
==Two-way signals==
  
 +
Two-way signals are a common way to influence trains on coop servers. This is possible with the setting ''Two-way end of line''.
  
== Pre-signals ==
+
=== Two-way end of line ===
 +
''Two-way end of line'' is a setting in OpenTTD that can be altered to create interesting train behaviour. By default it is off, but it is activated on every openttdcoop server.
 +
A red two-way signal directs train to a different route if one is available.
  
Pre-signals share all the mechanisms how they work with basic block signals, but they can be red in some extra cases, dependent on the state of other pre-signals. There are three of them:
+
''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.
  
=== Entry signals ===
+
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.
Detects Exit or Combo signals ahead. If All of them are Red, then this entry signal is Red too.
+
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.
  
Entry signal is a stopper - a place where trains stop under some condition. This means that it is used in any spot where train chooses from multiple options (platforms, choice waiting bays, anything) and we need it to wait for at least one platform/thing to be free.
+
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.
  
=== Exit signals ===
 
  
Exit signal is the end of pre-signal chain. It does not detect anything else than the block ahead of it.
+
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.''
  
=== Combo signal ===
 
  
Entry and Exit signal in one - detects Exit or other Combo signals ahead, and is detected by Entry or other Combo signals at the same time.
+
=== Pathfinder trap ===
 +
The most use of this setting is found in our [[SRNW]] games, we control trains to either take an exit to the sideline or stay on the mainline. We also combine this signal with a certain station or shortcut to create pathfinder traps. Pathfinder traps give us options to trick trains, we can decrease the pathfinder penalties to an actual station and so create more balanced traffic or we can balance mainline mergers. There are occasions where the inner lane is preferred so much we will create a shortcut from each lane to the inner lane after a merger. We disable an exit with the pathfinder trap so the trains will not actually take this path and a merger gives us a balanced output.
 +
{| align="center"
 +
|| [[File:Pftrap.png|300px|thumb|center|Pathfinder trap in its raw form.]]
 +
|| [[File:Pftraponmainline.png|300px|thumb|center|Pathfinder trap on mainline to create a shortcut that can never be used.]]
 +
|}
 +
=== Station with overflow ===
 +
In our games we often use overflows and this setting can help us create easy to implement overflows for our primaries. One example of this is found in the picture below.
  
The signals which chain the pre-signals and thus can separate signal blocks, but keep the pre-signal chain.
+
{| align="right"
 +
|| [[File:Overflow primary.png|300px|thumb|center|Overflow on the a primary with reverser arrows.]]
 +
|| [[File:TerminusPrimary.png|300px|thumb|right|Arrows on a primary station]]
 +
|}
  
== Path Signals ==
+
In the picture you can see the “ arrow” in the reverser. It is not eye-candy it actually has a use. The pathfinder sees that the other tracks are blocked and considers the reverser only a viable line if it has at least 2 options. This means we create a split in the reverser so the pathfinder thinks it has two options.
 +
 
 +
Similarly we advise you to also use this arrow on every reverser, and in every terminus station with  pre-signals at the final X as seen in picture below.  In theory only the track that has a straight line to the exit track should have one, but we still prefer using them on all platforms for a terminus station.
 +
 
 +
 
 +
=== Setting up two-way end of line ===
 +
To setup this behaviour in your own game you can do this in two ways: We at openttdcoop prefer you use the second way because it is permanent, stable and easier.
 +
 
 +
*Either in game trough the console command accessible with the “~”  key. Follow this by sending the following command:
 +
“set yapf.rail_firstred_twoway_eol 1”
 +
*The second way of changing this setting is by editing your openttd config file. And please do this when the game is closed. The location of this file is a question Google has an answer to. In here you find the line “yapf.rail_firstred_twoway_eol = false” and change it to “yapf.rail_firstred_twoway_eol = true” Follow this by saving and closing the config file.
 +
 
 +
[[Category:Guides]]
 +
[[Category:Basic networking]]

Revision as of 12:09, 2 December 2013


Signal types

OpenTTD currently has 4 basic signal types (not counting presignals). These 4 are:

Signals basic.png

Each of these 4 signal types has different properties and should be used in different circumstances. An overview:

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 here.


Placing Signals

Basic Signalling

Before you start to use Automatic Signalling or Signal Dragging you should check the signal density. You can change it in the signal interface or edit the drag_signals_density value in your openttd.cfg. Make sure the value is set to two.

Basic Signalling

The first thing you should know is how use the basic signal dragging feature of OpenTTD: Build a signal (fastest Shortcut is A & S), left-click it and hold the button, drag it as far as you want to build signals. Release the button and the signals will be built. Very easy.

Automatic Signal Completion

Automatic Signal Completion

Now we are ready to build signals and know how to use the basic feature of dragging. We can go a step further. Again Build a signal and drag it. While you are dragging it a little bit press the CTRL button and release it. The track will be filled up with signals until a breakpoint which are existing signals on the track, stations and junctions.

Removing Signals

Removing Signals

It's also possible to remove Signals with the Automatic Completion feature. If you have build a track with signals, use the signal deletion function (Shortcut: A & S & R): click the signal, drag it while pressing the CTRL button and all the signals will be deleted. The breakpoints are stations and junctions.

Breakpoints

Breakpoints

Automatic Signal Completion won't stop at: Tunnels and Bridges but stops at: Junctions, Stations and Existing Signals

Checking anyway

After you have "signaled" a track, you should optimize signaling at junctions, they might need a signal right before or after the interruption to avoid signal gaps.

Two-way signals

Two-way signals are a common way to influence trains on coop servers. This is possible with the setting Two-way end of line.

Two-way end of line

Two-way end of line is a setting in OpenTTD that can be altered to create interesting train behaviour. By default it is off, but it is activated on every openttdcoop server. A red two-way signal directs train to a different route if one is available.

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.


Pathfinder trap

The most use of this setting is found in our SRNW games, we control trains to either take an exit to the sideline or stay on the mainline. We also combine this signal with a certain station or shortcut to create pathfinder traps. Pathfinder traps give us options to trick trains, we can decrease the pathfinder penalties to an actual station and so create more balanced traffic or we can balance mainline mergers. There are occasions where the inner lane is preferred so much we will create a shortcut from each lane to the inner lane after a merger. We disable an exit with the pathfinder trap so the trains will not actually take this path and a merger gives us a balanced output.

Pathfinder trap in its raw form.
Pathfinder trap on mainline to create a shortcut that can never be used.

Station with overflow

In our games we often use overflows and this setting can help us create easy to implement overflows for our primaries. One example of this is found in the picture below.

Overflow on the a primary with reverser arrows.
Arrows on a primary station

In the picture you can see the “ arrow” in the reverser. It is not eye-candy it actually has a use. The pathfinder sees that the other tracks are blocked and considers the reverser only a viable line if it has at least 2 options. This means we create a split in the reverser so the pathfinder thinks it has two options.

Similarly we advise you to also use this arrow on every reverser, and in every terminus station with pre-signals at the final X as seen in picture below. In theory only the track that has a straight line to the exit track should have one, but we still prefer using them on all platforms for a terminus station.


Setting up two-way end of line

To setup this behaviour in your own game you can do this in two ways: We at openttdcoop prefer you use the second way because it is permanent, stable and easier.

  • Either in game trough the console command accessible with the “~” key. Follow this by sending the following command:

“set yapf.rail_firstred_twoway_eol 1”

  • The second way of changing this setting is by editing your openttd config file. And please do this when the game is closed. The location of this file is a question Google has an answer to. In here you find the line “yapf.rail_firstred_twoway_eol = false” and change it to “yapf.rail_firstred_twoway_eol = true” Follow this by saving and closing the config file.
Powered by MediaWiki