#openttdcoop wiki - User contributions [en]

Merging Tracks

2014-03-07T13:28:52Z

Lisbon: fixed an awkward sentence

''Written by {{User|V453000}}''

There are many misleading names to this, I will however call them Merging with a sub-case of Joining. I will try to explain not just how to call these things, but also how they work, why are they necessary and what to consider when building them.

This page is an explanation of merger theory and basics, for real game examples see the [[Junctionary_-_Mergers|junctionary]]. (Recommended after reading this page)

Many screenshots on this page are taken from this example savegame which also includes some signs with explanations. It is recommended to obtain it. Saved with r25071, Swedish Rails 0.7.4 and NUTS Unrealistic Train Set 0.4.7 both available on BaNaNaS.

'''All of the things are constructed for trains 3 tiles long!'''

[[file:Merging.sav]]

__TOC__

[[Image:Mergers_basic.png|right|400px|]]
=== What is a merger? ===
A merger is a place where some amount of lines reduces to a smaller count. Most typically used in all kinds of [[hub]]s, they (or their look-alikes) can also be used as [[Junctionary_-_Stations|station]] exits, station entrances and/or just as standalone mergers without a hub (rare cases).

[[Image:Mergers_NoChoice.png|right|400px]]
===The purpose===
The logic for people who do not know about proper Merging yet is theory that line A will have about 50% traffic going this way while line C will also have about 50%, therefore logically they give 100% in line 1, and the same applies for B + D = 2.
The important thing to note is that the percentages are not entirely wrong, but they are first of all only theoretically expected traffic, and second – average theoretically expected traffic. With perfect randomness, trains will indeed go like that, but in a normal game they will not.
One of the problems is that you cannot even expect the traffic correctly in the long term. Just slight changes or even expansions at some other hub will most likely mean that trains will come on different lines and in different ratios.
Whenever trains come from multiple tracks and are meant to exit in multiple tracks, they need to be able to choose their exit in order to make all exiting tracks used effectively. This choice happens in a Merger.

== Terminology ==
It is important to call things not just with an unified name, but also with a name which intuitively signifies what are we talking about.

====Merger====
is the general name for the mess where tracks X output as tracks Y.

====Joiner====
is a specific case of merging where one direction gets priority, can also be called SLH-style merge.

====Choice====
is the option given to trains to choose from the output tracks in a way that no matter from which input tracks do trains come, the input will not jam until all output tracks are full.

====Input tracks====
or entrance, also substituted with incoming tracks and similar terms, are tracks which go to the merger.

====Output====
outgoing tracks or exit are the reduced amount of tracks which leave the merger.

====Direction====
is the stack of tracks which all go to the same destination, like a LLLL is a direction consisting of 4 lines.

====Line====
also rail or track is just one of the few (or many!) inside a direction.
It is absolutely essential to treat all tracks of the same direction equally as they are in theory the same and traffic on each line can be completely random, totalling a maximum of the throughput of the whole Direction, regardless where the traffic actually is.

====Priority / check====
A very crucial component of many points where tracks merge are [[priorities]]. As one of the first logic mechanisms our players learn, 99% of them understand it as trains A giving way to trains B, also explainable as trains B are prioritized over A, and that trains B are more valuable than A.
That however is not true, the priority is like a check, or a question when trains ask „Which track is free?“ “Which track can I join?“.“
A good example is a common question „How long should a priority be?“. The priority needs to be long enough to be able to detect if there is traffic and eventually not disrupt the traffic on the chosen line too much in case train joins that line. At the same time it needs to be short enough to let trains join frequently and efficiently enough enough. Saying an exact value is not related only to the type of trains, but also to the type of merger. If we have a SLH joiner which expects that the ML will not be slowed down, prio can be longer. If we have a check if the line is 100% full in a BBH merger, the prio will probably need to be very short.
Look out for examples at each of the shown mergers.

<gallery>
File:Mergers_42innerOuter.png|Typical merger.
File:Mergers_joiner.png|Joiner, also SLH-styled merger.
File:Mergers_choice.png|Choice to one of the outputs.
File:Mergers_input.png|Input tracks.
File:Mergers_output.png|Output tracks.
File:Mergers_direction.png|Direction.
File:Mergers_line.png|Line.
File:Mergers_prio.png|Priority check.
</gallery>

You will often see other words which I will mention here but I strongly recommend not to use them as they are majorly misleading.

'''Balancing''', Balancer or Balanced traffic is probably the most used, and the worst term in this case. Most people then take Mergers as a mechanism which has an aim to spread traffic evenly over output lines, which is false.

'''Mixing''' is not as bad but it seems to imply that the logic which line goes where is random, causing some confusion as well.

==General Merger Logic==
The most important part of a merger is the logical way how it works. This is the method of which lines get which choices and why. I will try to go through the general logic from the simplest, towards more complicated – pretending that we are expanding in the process.
Lets take a simple example to start.

===3->2===
The simplest possible merger is 3->2 so let’s see what options we have there.

====All to All====
The first and always valid option is to give all lines the Choice to join any exiting line. The problem obviously is that the many connections cause things to be large, for the cost of reliability.

====1->2====
We have another way how to deal with traffic here however. If trains from track C choose from any of the other two lines A or B, they will always find their place.
We need to add Checks to each of the line to detect if a train can join there or not. This is because lines A and B have no choice so if trains from C just joined them at their free will, one of them would probably start jamming.
Of course when that jamming would occur, trains would automatically move from jamming A to B, but only within the capabilities of C – A would still remain slow.

<gallery>
File:Mergers_32AlltoAll.png|All to all
File:Mergers_32InnerOuter.png|1->2 for one of the lines
</gallery>

===4->2===
If we look at something like 4->2 which is only a little bit different from 3->2, we can apply the same logic as before.
While all to all gives all possible choices, we cannot do a 1->2 anymore as it turned into 2 lines choosing from 2 outputs. And we will do exactly that, each of the two gets both choices.
To make this more space efficient, it is a good idea to make the lines inside get choices – so we have less rail crossings in total. That is what I call the Inner Mix.

<gallery>
File:Mergers_42AlltoAll.png|All to all
File:Mergers_42InnerOuter.png|2 of the lines choose from the other 2
</gallery>

===Expanding more===
Adding more inputs is simple, all-to-all just gets the same thing done more, where the inner mix suddenly gets 3->2 inside.
Note that this 3->2 works differently than a standalone merger as each of the 3 needs both choices. If there would be just a 3->2 made of 1->2, it would mean that 2 of the inputs are forced without choice, therefore if traffic came from all those lines, it would inevitably jam.

Adding an output changes a lot more though as it gives us a lot more options.
First of them could be that the inner lines just get an additional choice. Outer lines are happy as they are, and if they get full, trains from the inner lines can join the new third output.
This can be insufficient for example if the choices to the new line are bridges, or just longer gaps – they might not be able to populate the new line fully.
In such cases we just need to improve the choice throughput by doubling bridges or making unbridged choice with agressive signalling.

Another possibility would be reverse logic, where we would tell the outer lines „if trains need to join from the inner lines, try to send outer lines to the new line. Note that we removed the priorities as all trains have some choices. This solution can get messy, but is relatively effective.
In case of all-to-all we need to add a lot of new choices, usually resulting in a complete rebuild. (unless the design has some free spots for the expansion)

<gallery>
File:Mergers_43AlltoAll.png|Added output, All to all
File:Mergers_43InnerOuter.png|Added output, Inner choice
File:Mergers_43InnerOuterExtra.png|Added output, Inner choice "escapes" for outer
File:Mergers_52InnerOuter.png|Added input, Inner choice
</gallery>

When we add even further, like output of 4 lines, we still follow the same logic, but with more lines. Same for the input. Lets just look at a few bigger examples.

==Speed of the merger==
While logical sense makes trains choose from lines and defines how the merger as a whole works, you might have noticed that there arent oh so many things to consider regarding the logic what is connected to what.
The fun starts when you want to make the merger work well. There are many things to consider regarding throughput, let’s attempt to have a look at some of them.
A lot of this is very related to throughput questions in general, described for example in ABR 07 Stations

===Waiting bays / spots / spaces===
As trains are obviously expected to stop in some spots, we need to make sure that stopped (waiting) trains do not block the access to the other choices as we want trains to choose a different line if the first one is full (and train is waiting for that line).
It becomes a lot more interesting when trains can stop at various locations, which is usually the case.

====Waiting bay length====
The waiting bays should always attempt to be as quick as possible, which requires agressive (dense) signalling. That however does not mean it means signals can be everywhere. You still need to be very careful about where trains can stop, for which it is very useful to mark those spots with entry signals and univ rail.
[[File:Mergers_WaitingBays_length.png|none|200px]]

====Waiting bay usage====
Note that waiting bays are necessary everywhere. For every choice of trains going somewhere they need to have the option of having a safe spot where they could eventually wait without blocking other traffic.
In some cases it can be okay to apply PBS instead of the additional waiting bay for the price of throughput.
It is however absolutely unacceptable to use block signals which lead to the same place without waiting bays as they can stop at wrong spots. This was typically used in some of the old games with combo signals.
Both trains waiting for the choice – as soon as it turns green, both trains start at the same time and one of then gets stuck there until the second train is able to move.
<gallery>
File:Mergers_PBSbays.png|Dual waiting bays with PBS.
File:Mergers_Prebays.png|Dual waiting bays with Pre-signals.
File:Mergers_Prechoice.png|Choice with combo signals.
File:Mergers_Prechoice_stuck.png|Stuck choice with combo signals.
File:Mergers_Combobays.png|Combo signals to same block, stuck.
</gallery>

====Hint: Marking where trains stop====
As entry signal has only one job – to stop trains when pre-signal input is red – it can also sign the point where trains are meant to stop without the pre-signals. I use that to highlight those important spots as you can see in this image.
Probably the best way to mark things is by PURR colours.
[[File:Mergers_Marking.png|thumb|none|200px|Clearly visible where trains are supposed to stop can be helpful.]]

==Choice reactivity==
The waiting bay needs to be long enough, but the shorter it is, the better. When only one train is able to wait for one line, it means that the second train will already react and try to choose some other line. For that reason it is always better to make shorter waiting bays (but long enough to accomodate a train).
It is typical for people to try building this in order not to move with the main line. Under whatever circumstances, the main line are just tracks too – do not be afraid to move with them!
<gallery>
File:Mergers_Split_3bays.png|Unnecessarily long choice for 3 trains.
File:Mergers_Split_moveML.png|Do not be afraid to move the ML!
</gallery>

==Split signalling==
When splitting traffic into multiple choices, we always need some sort of check if there is any choice green. For that we have following options: Pre-signals, PBS with 1-way signals, 2-way pre-signals, PBS with 2-way signals

====One-way pre-signals====
are always the best option as they make trains choose their path quickly and easily (because the exit firstred penalty is like 40 000)(firstred penalty is the penalty a signal has when right in front of the train, and when the signal is red). At the same time they will not divert a lost train which is nice as it shows there is some missing connection somewhere.

====PBS leading into 1-way signals====
is a bit space efficient, but as the normal signal firstred penalty is rather low, PBS can have some serious problems with choosing the right path, and some choices can seem to be ignored completely. This can be fixed with PBS leading into 2-way signals.

====2-way pre-signals and PBS leading into 2-way signals====
both work almost the same way, they reliably choose from any of the options, but the 2-way signals can cause trains to get lost if your network has missing connections. (Not all Lines from a Direction have the same destination chances at splits)
As missing connections should not happen in the first place, 2-way signals are acceptable and sometimes necessary, but where it is possible it is good to have 1-way pre-signals so we could uncover the eventual missing connections at the mergers. With 2-ways trains just get lost and turn around somewhere going through some ro-ro station which is a lot harder to notice.

====PBS and prio entry-signals====
the PBS sees the state of the priority when choosing – instead of choosing based on the state of the waiting bays. With this it is possible to make trains try to join the emptier lines even more. A downside of this is that the throughput of each choice gets to be very low so it is only affordable on main station exits or SLHs.

<gallery>
File:Mergers_Split_pre1.png|1 way pre-signals are standard
File:Mergers_Split_PBS1.png|PBS into 1-way signals is bad
File:Mergers_Split_PBS2.png|PBS needs 2-way signals to choose well
File:Mergers_Split_pre2.png|2 way pre-signals should not be necessary
File:Mergers_Split_PBS2wayentry.png|Advanced choosing for less throughput on choices
</gallery>

==Split layout==
The most important point which defines how quickly it all works is the first split – the place where the merger technically starts for that line.

===Unified split===
The best option is to have all choices available at the first split.

===High throughput choice===
It is however possible to make one of the split parts have sufficient throughput to populate choices going from there. This requires agressive signalling or double bridges.
Double bridges are not quite a good solution as it makes evil mode possible to happen, and gives more waiting spaces so it takes longer for trains to „realize“ they should try other choices instead.
Usually having each bridge lead to a different choice is already a better solution, but this is an option as well.

<gallery>
File:Mergers_Split_Unified.png|Splitting all from one tile is fastest.
File:Mergers_Split_Signals.png|Allowing high throughput through the choice to make the next 2 choices well available.
File:Mergers_Split_Bridges.png|Increasing throughput by bridges can be helpful when necessary.
</gallery>

==Merging point(s)==
Significant improvements can also come from correctly investigating how do the trains merge together. Let’s give a few examples.

====One spot====
The best and most powerful result is to have trains join at only one (possibly prioritized) spot. That means all trains going to this line have about the same chance to join, and eventually disturb traffic on that line only once.

====Sequence – priority====
What is very simple to do is a series of joins onto a single line, prioritizing each of them.
The problem is that trains downstream will have a lot harder time joining than trains in the first spot, simply because all the choices for them are already checked first by other trains.

====Sequence – no priority====
If we remove priority checks, we do not solve the problem but we get a different result. In this case the last line has the easiest time joining the line because it has 50:50 chance to join in relation to all others.

====Sequence – small priority====
A middle way is a priority so short that it does not really make it too hard for any trains. Often used at station exits as station exits usually have many lines out and this design is very simple and repeatable.

====Tree structure====
As one spot can only take three rails maximum, other lines also need to be joining somewhere, so they just join on the other choices.

====Downhill merge====
In some games it is very effective to abuse gravity and help trains accelerate in the merging point. This can improve the output of the merger drastically. Especially effective with weak trains, with strong trains you will barely see any difference.

<gallery>
File:Mergers_join_unified.png|Joining the line once is best
File:Mergers_join_sequence_prio.png|Sequential join with prio is sub-optimal
File:Mergers_join_sequence_noprio.png|Sequential join without prio is not the best either
File:Mergers_join_sequence_smallprio.png|Sequential join with small prio works nicely
File:Mergers_join_tree.png|Merging lines together equally works great for BBH mergers
File:Mergers_join_downhill.png|Using gravity to your advantage can drastically increase output capacity. From psg213
</gallery>

==Bridges (also tunnels) and evil mode==
There exists a so-called [[evil mode]] which is an action when trains endlessly slow each other down in a cycle on doubled bridges. Evil mode itself does not happen without a reason, it needs a slowdown – and slowdowns can happen in merges when trains join lines. That is why it is a thing to consider when building them, which has various solutions.

====Self-unblockable bridges====
If you build bridges with standard block signals, they should be able to unblock themselves if evil mode happens. This is not a perfect solution, but helps greatly. Of course the eventual priority has to be adapted to that as you cannot use any entry check on the bridges (cant use PBS, nor entry signal to stop trains when both bridges are full).
When both bridges are full, the third train will just go to one of them. There is a 50-50 chance that it will go to the „wrong“ bridge, therefore making the bridges work as a single bridge for a while, and reseting them.

====Full priority====
Another option is to give priority to the bridges and hope that it does not do evil. This however has negative drawbacks like too long priority which causes less trains to join the line – while it still can cause the bridges to evilmode and jam. If you can get away with it and not face evil mode, it works too – but is a lot more dangerous especially with trains with mediocre acceleration.

====Prio to unbridged lines====
If we choose from lines which do not have bridges, we automatically cannot get evil mode on those lines.

====No doubled bridges====
If we have a split to two bridges, we can make each of the bridges lead to a different line. With that we reach a point where evil mode does not really happen.

<gallery>
File:Mergers_bridges_pre.png|Pre-signals on slowed bridges keep evil mode.
File:Mergers_bridges_PBS.png|PBS on slowed bridges keep evil mode.
File:Mergers_bridges_basic.png|Basic signals on slowed bridges can deal with evil mode.
</gallery>

<gallery>
File:Mergers_bridges_shortprio.png|If the bridges can deal with it, we can use shorter priority.
File:Mergers_bridges_longprio.png|When bridges are fragile, they need long priority.
File:Mergers_joiner.png|Not bridging the prioritized line overcomes this problem entirely.
File:Mergers_bridges_nodouble.png|Making no double bridges requires adapting the hub in general. From psg 255
</gallery>

[[Category:Guides]]
[[Category:Advanced Networking]]

Signals

2014-02-28T00:47:34Z

Lisbon: Just some small edits for typos I caught and reducing ambiguity by changing "standard single signal" to "standard single block signal" in the PBS 1-Way section.

{{update}}
{{cleanup}}

See also: http://wiki.openttd.org/Signals

== Signal types ==
OpenTTD currently has 4 basic signal types (not counting presignals). 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 therefore 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 discarding its route. This property can lead to very unexpected and unwelcome behaviour. Use with caution.
|-
! PBS 1-Way
| Path-based
| One-way
| The path-based version of the standard single block signal. In general, use this instead of the PBS signal. However, whenever path-based signals are not strictly needed, use the standard single block 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]].

==Placing Signals==
[[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.

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

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

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

Read more: http://wiki.openttdcoop.org/Two-way_end_of_line

== Presignals ==

Presignals are widely used in openttdcoop games for simple constructions as well as the most advanced ones.

Read more: http://wiki.openttdcoop.org/Guides:Presignals

== PBS ==

Full article: http://wiki.openttdcoop.org/PBS

== Signal Gaps ==
[[Image:Signal gap settings.png | thumb | 400px | right | Configuring auto-signalling]]
A signal gap, or gap for short, is the amount of unsignalled space in a single signal block. Understanding signal gaps is important for maximizing train density on a rail line and ensuring that trains continue to move at the maximum allowable speed. In coop games, we adhere to a maximum signal gap of 1 tile.

In general, use of the term "gap" indicates that a signal gap of length greater than 1 has been detected, and as a result, the efficiency of the network is at risk. Steps should be taken to fix any gaps marked in this manner.

Do not confuse a "signal gap" with a "train gap". A train gap is the minimum space between two trains. Because our signals are 2 spaced tiles apart (also known as [http://wiki.openttd.org/Railway_Designs Signal Density]), there is a minimum gap of 3 (the Signal Density +1).

 
=== Why is understanding gaps important? ===

A rail line is only as fast as its weakest link. If there is any point on the line where traffic must slow down or stop, the disruption will have a domino effect on any following trains, resulting in an inefficient network. As the goal is often to build a highly-efficient, and highly-dense network, these types of disruptions must be avoided at all costs!

 
=== What if I need to create a signal gap larger than 1? ===
[[Image:Signal gap sync.png | thumb | 400px | right | Make sure alternate routes are in sync]]
To create a signal gap larger than 1, you must provide following trains an alternate route until the gap is restored to 1. Larger gaps are created at station platforms, bridges, and tunnels, since none of these items can be signalled.

To create an alternate route, simply make a new line parallel to the first line. This line should continue until the signal gap can be restored to 1, making sure to keep the trains [[Line sync|synchronize]]d.

 
=== How to count the length of a gap ===
When using normal block signals, a gap's length is defined as the number of unsignalled spaces between two signals. Normal coop [[mainline]]s use a signal gap of 1, meaning there is only 1 unsignalled tiles between two signalled tiles.

When using pre-signals, the gap is counted from the tile after the first pre-signalled (or combo-signalled) tile through to (but not including) the next normal block signal (exit signals are still counted as part of the gap). If multiple routes exist, the largest value is the gap.

Placing a pre- (or combo-) signal and an exit signal (in that order) on a mainline will create a gap larger than 1, so this type of construction should not be done without creating an alternate route.

When using PBS signals, the gap is counted just like normal block signals: from the tile after the PBS signal through to (but not including) the next signalled tile. If multiple routes exist, the largest value is the gap.
[[Image:Signal gap counting.png | 400px | thumb | left | Counting signal gaps]] [[Image:Signal gap signals.png | 400px | thumb | left | Other signals]]

 

=== How many alternate routes do I need to create? ===
[[Image:Signal gap bridges.png | thumb | 400px | right | Two bridges for this gap is enough for any train length]]
The number of alternate routes is dependent on the length of the gap and the minimum train length that might encounter the gap.

The typical formula used to calculate the maximum gap length for a certain number of lines (LineCount) is

'''SignalGapLength = (TrainLength + 2) * LineCount - (TrainLength - 2)'''

Where TrainLength is the minimum train length to encounter the gap, and LineCount is the sum of the alternate routes provided + 1 (the original route). 
(This can be quickly calculated with [[User:KenjiE20/Webster|Webster's]] @gap)

Conversely:

'''LineCount = (SignalGapLength + TrainLength -2) / (TrainLength+2)'''

Always round any fractions up to the next whole number. 
(This can be quickly calculated with the [[IRC Commands|PublicServer bot's]] !gap)

Refer to the section above for information about how to count a gap properly.

 
==The Evil X ===
[[Image:Signal gap evilx.png | thumb | 400px | right | The Evil X]]
When two lines cross each other in an oblique (non-perpendicular) way, it creates an "evil X". The main problem with the evil X is that it inherently creates a signal gap of 2.

A simple merge does not create a large gap, as long as the tiles before (on both lines) and after (on the single output line) are signalled.

However, note that when the tracks cross obliquely, it is not possible to signal the output line, creating the gap.

In practically all cases, evil X's should be avoided.

[[Category:Guides]]
[[Category:Basic networking]]