Two-way end of line - Revision history

OpenTTD Player9876556789 at 02:21, 22 January 2024

2024-01-22T02:21:38Z

Hazzard: /* Station with overflow */

2019-04-16T07:23:45Z

‎Station with overflow

PaulF: minor corrections

2014-05-10T11:50:34Z

minor corrections

Benny: Added link to full overflow article

2013-12-09T10:44:23Z

Added link to full overflow article

Benny: typo

2013-12-04T10:16:33Z

typo

Benny: Created page

2013-12-02T12:28:04Z

Created page

New page

=== 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.
{| 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.

{| 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]]
|}

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:Advanced networking]]

← Older revision		Revision as of 10:16, 4 December 2013
Line 48:		Line 48:

	[[Category:Guides]]		[[Category:Guides]]
−	[[Category:Advanced ~~networking~~]]	+	[[Category:Advanced Networking]]

@@ Line 1: / Line 1: @@
 === 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.
+''Two-way end of line'' is a setting in OpenTTD that can be altered to create interesting train behaviour. By default it has been on in recent years (as of Jan 2024), but was off in the years when Openttdcoop was popular, 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 of course the ability to reach the destination (station). The train then chooses the path with the lowest penalty score.
+''While used in combination with the default YAPF pathfinder, two-way signals (exculding the two way PBS/Path-Based Signal) have a weird and often misunderstood property. This property, called yapf.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 of course 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.
+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 wrong direction, detouring or actual dead end 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 trains detouring or even driving themselves into a station or actual dead end.
+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 trains detouring or even driving themselves into a non-penalty 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 penalty-wise, 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.
+Now is the EOL (End of Line) 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 penalty-wise, 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 block signals when you understand their workings and use. Otherwise, use one way block signals or PBS.
-* 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 indiscriminate 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.
+* Only use two-way block 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 indiscriminate 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 of course for track that actually has to be two-way, like the signals next to platforms in terminus stations.
@@ Line 22: / Line 23: @@
 === 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.
+A major use of this setting is found in our [[SRNW]] games, where 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 (which would create a train traffic jam) and a merger gives us a balanced output.
 {| align="center"
 || [[File:Pftrap.png|300px|thumb|center|Pathfinder trap in its raw form.]]
@@ Line 46: / Line 47: @@
 *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.
+*The second way of changing this setting is by editing your openttd config file. And please do this when the game is closed, otherwise the file won't save or your game might malfunction. The location of this file is a question Google Search 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:Advanced Networking]]

@@ Line 28: / Line 28: @@
 |}
 === Station with overflow ===
-Full article: http://wiki.openttdcoop.org/Overflow
+[[Overflow|Full article]]
 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.
@@ Line 40: / Line 40: @@
 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 ===