Merging Tracks - Revision history

Lisbon: fixed an awkward sentence

2014-03-07T13:28:52Z

fixed an awkward sentence

V453000: /* Hint: Marking where trains stop */

2013-12-04T11:11:54Z

‎Hint: Marking where trains stop

Benny at 07:22, 7 November 2013

2013-11-07T07:22:14Z

Mazur: /* General Merger Logic */ Correcte "sinplest" spelling.

2013-05-16T12:42:22Z

‎General Merger Logic: Correcte "sinplest" spelling.

Mfb: some details

2013-03-24T15:28:26Z

some details

V453000 at 18:19, 22 March 2013

2013-03-22T18:19:03Z

V453000 at 18:18, 22 March 2013

2013-03-22T18:18:34Z

V453000 at 13:43, 22 March 2013

2013-03-22T13:43:55Z

V453000: done for now :)

2013-03-22T10:09:30Z

done for now :)

Show changes

V453000 at 23:20, 21 March 2013

2013-03-21T23:20:07Z

@@ Line 8: / Line 8: @@
 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 long 3 tiles!'''
+'''All of the things are constructed for trains 3 tiles long!'''
 [[file:Merging.sav]]

@@ Line 157: / Line 157: @@
 ====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.
-You could also mark waiting bays with universal rail. Note that to do this with normal rail, you need to apply a railtype newGRF to it, like Swedish Rails.
+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.]]

← Older revision		Revision as of 07:22, 7 November 2013
Line 273:		Line 273:

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

@@ Line 76: / Line 76: @@
 ==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 simpliest, towards more complicated – pretending that we are expanding in the process.
+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 simpliest possible merger is 3->2 so let’s see what options we have there.
+The simplest possible merger is 3->2 so let’s see what options we have there.
 ====All to All====

@@ Line 12: / Line 12: @@
 [[file:Merging.sav]]
-[[Image:Mergers_basic.png|left|200px|]]
+__TOC__
 === What is a merger? ===
-A merger is a place where some amount of lines reduces to smaller count. Most typically used in all kinds of hubs, they can also be used (or their look-alikes) as station exits, station entrances and/or just as standalone mergers without a hub (rare cases).
+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|left|200px]]
+[[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 ratio.
+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.
@@ Line 53: / Line 51: @@
 ====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 understands 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.
+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.
@@ Line 110: / Line 108: @@
 ===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 traffi came from all those lines, it would inevitably jam.
+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.
@@ Line 200: / Line 198: @@
 The best option is to have all choices available at the first split.
-===Hight throughput choice===
+===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.
@@ Line 221: / Line 219: @@
 ====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 from A will have a lot harder time joining than trains from D, simply because all the choices for A are already checked first by D.
+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 D has the easiest time joining the line because it has 50:50 chance to join in relation to all others (the line, A, B and C together)
+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====
@@ Line 246: / Line 244: @@
 ==Bridges (also tunnels) and evil mode==
-There exists a so-called evilmode 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.
+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====
@@ Line 273: / Line 271: @@
 File:Mergers_bridges_nodouble.png|Making no double bridges requires adapting the hub in general. From psg 255
 </gallery>

← Older revision		Revision as of 18:19, 22 March 2013
Line 7:		Line 7:

	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.		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 long 3 tiles!'''		'''All of the things are constructed for trains long 3 tiles!'''

← Older revision		Revision as of 18:18, 22 March 2013
Line 7:		Line 7:

	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.		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 long 3 tiles!'''

	[[file:Merging.sav]]		[[file:Merging.sav]]

← Older revision		Revision as of 13:43, 22 March 2013
Line 2:		Line 2:

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

@@ Line 168: / Line 168: @@
 ====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.