Merging Tracks
From #openttdcoop wiki
Written by 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. (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!
Contents
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 hubs, they (or their look-alikes) can also be used as station exits, station entrances and/or just as standalone mergers without a hub (rare cases).
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.
Typical merger.
Joiner, also SLH-styled merger.
Choice to one of the outputs.
Input tracks.
Output tracks.
Direction.
Line.
Priority check.
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.
All to all
1->2 for one of the lines
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.
All to all
2 of the lines choose from the other 2
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)
Added output, All to all
Added output, Inner choice
Added output, Inner choice "escapes" for outer
Added input, Inner choice
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.
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.
Dual waiting bays with PBS.
Dual waiting bays with Pre-signals.
Choice with combo signals.
Stuck choice with combo signals.
Combo signals to same block, stuck.
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.
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!
Unnecessarily long choice for 3 trains.
Do not be afraid to move the ML!
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.
1 way pre-signals are standard
PBS into 1-way signals is bad
PBS needs 2-way signals to choose well
2 way pre-signals should not be necessary
Advanced choosing for less throughput on choices
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.
Splitting all from one tile is fastest.
Allowing high throughput through the choice to make the next 2 choices well available.
Increasing throughput by bridges can be helpful when necessary.
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.
Joining the line once is best
Sequential join with prio is sub-optimal
Sequential join without prio is not the best either
Sequential join with small prio works nicely
Merging lines together equally works great for BBH mergers
Using gravity to your advantage can drastically increase output capacity. From psg213
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.
Pre-signals on slowed bridges keep evil mode.
PBS on slowed bridges keep evil mode.
Basic signals on slowed bridges can deal with evil mode.
If the bridges can deal with it, we can use shorter priority.
When bridges are fragile, they need long priority.
Not bridging the prioritized line overcomes this problem entirely.
Making no double bridges requires adapting the hub in general. From psg 255
