OpenTTD allows to control trains with [[signals]]. The introduction of presignals allows to build more complex setups - the state of a signal (green/red) does not only depend on the following signal block, but also on other signals. For details, see the signal-article in the OpenTTD wiki [http://wiki.openttd.org/Signals].

Presignals are frequently used to control trains in [[priorities]] and station entries. The combination with [[dummy train]]s, however, allows even more powerful constructions. Signals can be green or red, those states can be identified with 0 and 1, respectively (this is just a convention, it could be used the other way round as well). With trains and signals, it is possible to build all basic computer elements. In theory, it is possible to build a CPU in a game. You could even simulate OpenTTD ''in'' OpenTTD, if map size and computing power would not be a limit.

To keep constructions simple, most logic constructions are built out of several standard elements, called gates. Usually, those gates are separated with combo signals to avoid unplanned influences. If the setup is sensitive to the timing (train A has to arrive before train B or similar), this has to be taken into account in the design. Otherwise, logic gates can be combined in arbitrary way to get the desired output (green/red signals) based on some input (usually: train positions).

== Logic gates ==

There are always many ways to build gates. The constructions shown here are the most simple setups - if space is limited, it is often useful to change their shape a bit.

=== NOT ===
The most common logic gate you will see on coop servers is the NOT gate. It inverts the input: If the input is green, the result is red, if the input is red the result is green. This is done with two trains running on a 3x3-tile ring. If the input is green, they keep moving and at least one train keeps the output red. If the input is red, both trains stop behind an entry signal and the output is green. It is possible to use TL0.5-trains (single engine), but the gates work better with TL1-trains (two engines or double engine).
{| align="right"
|| [[File:NOT.png|thumb|430px|right|Two NOT gates, one converting red to green and the other one converting green to red.]]
|| [[File:AND.png|thumb|430px|center|AND "gates" with different input states]]
|-
|}

=== AND ===
AND gates are red if and only if all inputs are red. This is a feature of presignals - an entry or combo signal is red if all exit and combo signals leading to that block are red. There is no (practical) limit on the number of inputs.

=== OR ===
OR gates are red if and only if at least one input is red. There are two ways to implement this: An OR gate or a construction similar to a [[priority]]. The latter method requires less space, but it works only with trains in that signal block itself - you cannot combine arbitrary logic lines like that.
{| align="center"
|| [[File:OR.png|thumb|430px|left|OR gates with different input states]]
|| [[File:OR prio.png|thumb|430px|center|OR, built like a priority]]
|-
|}

== Advanced logic elements ==

[[File:XOR.png|thumb|220px|left|XOR construction, you can see the OR and NOT gate inside]]
[[File:Edge_detector_falling_inverted.png|thumb|220px|right|Falling edge detector (inverted). Output (right) flashes green when input (left) changes from red to green.]]
[[File:Logic traincounter.png|thumb|220px|left|A simple train counter. It can fail if the line jams. The counter train (lower left part) is released if the TL2-train blocks the NOT gate entry, but not the signal block behind and in front of it.]]
[[File:Logic_delay.png|thumb|220px|right|A delay circuit. When the input (top right) turns green, after the train traverses the loop the output (bottom left) will flash green. The delay depends on the speed of the train.]]
[[File:Logic_abs_red_converter.png|thumb|220px|left|A green to absolute red converter (red PURR). The dummy train on the right alternates moves left or right depending on the input (bottom left), creating the absolute red output (bottom right). Used to make an absolute red based OR gate with the yellow line.]]
=== XOR ===
XOR gates are red if exactly one of its two inputs is red. There is no known elementary gate for this, but it can be built as combination of multiple gates: (A XOR B) = (A OR B) AND (NOT(A AND B)) where A and B are the inputs.

=== Edge detector ===
An edge detector is sensitive to ''changes'' of its input: If the input switches from red to green (or green to red, depending on the implementation), its output becomes green (or red) for some time, and switches back to its original position afterwards. This can be used to detect trains running on a line.

=== Basic train counter ===
A train, running in a loop, can be used as counter: Most of the time, all signals for this train are red. To count up, all signals get green for a short time, and the train travels to the next signal. This can be used to store data, for example in [[Self-regulating Network|self-regulating networks]].

=== Delay ===
A delay has the same output as its input, but it needs some (usually fixed) time to change the output. This can be useful if timing is important.

=== Red -> absolute red ===
A special gate to produce absolute red: A train in a signal block instead of a red presignal.

=== Clocks ===
Clocks are used to track time, for example time after the last train went through a line. See [[:File:Mark Clock.png|Mark's clock]] for an example. A very simple clock can be built with a train and a timetable to stay in a station for x days.

== Applications ==

=== SRNW stations ===
Stations in self-regulating networks are the most common application of logic. The trains themself cannot have a full load order, therefore it is required to control that with logic. Usually, this is done with dummy or feeder trains - they have a full load order, and SRNW trains are allowed to go into a station only if a feeder/dummy train is unloading there.

There are many possible layouts for SRNW stations, some of them are collected in the [[Junctionary_-_Stations_-_Special_Cases|Junctionary]].

[[File:Logic forcedsplit.png|thumb|400px|right|A split for lost trains: If the SL (western exit) is free, the NOT gate switches the twoway signal on the ML to red.]]
=== Flipflop-Split ===
A flipflop is a small memory with two possible states. This allows splits where exactly 50% of the trains go to one side and 50% go to the other side: The flipflop stores the direction of the last train and directs the new train to the other side.

=== Forced Split ===
If trains are lost, their destination at a split can be unpredictable. With a red twoway signal, they can be forced to split in a specific direction.



[[Category:Advanced Networking]]

Logic

2019-08-27T21:14:13Z

Hazzard: /* Advanced logic elements */

OpenTTD allows to control trains with [[signals]]. The introduction of presignals allows to build more complex setups - the state of a signal (green/red) does not only depend on the following signal block, but also on other signals. For details, see the signal-article in the OpenTTD wiki [http://wiki.openttd.org/Signals].

Presignals are frequently used to control trains in [[priorities]] and station entries. The combination with [[dummy train]]s, however, allows even more powerful constructions. Signals can be green or red, those states can be identified with 0 and 1, respectively (this is just a convention, it could be used the other way round as well). With trains and signals, it is possible to build all basic computer elements. In theory, it is possible to build a CPU in a game. You could even simulate OpenTTD ''in'' OpenTTD, if map size and computing power would not be a limit.

To keep constructions simple, most logic constructions are built out of several standard elements, called gates. Usually, those gates are separated with combo signals to avoid unplanned influences. If the setup is sensitive to the timing (train A has to arrive before train B or similar), this has to be taken into account in the design. Otherwise, logic gates can be combined in arbitrary way to get the desired output (green/red signals) based on some input (usually: train positions).

== Logic gates ==

There are always many ways to build gates. The constructions shown here are the most simple setups - if space is limited, it is often useful to change their shape a bit.

=== NOT ===
The most common logic gate you will see on coop servers is the NOT gate. It inverts the input: If the input is green, the result is red, if the input is red the result is green. This is done with two trains running on a 3x3-tile ring. If the input is green, they keep moving and at least one train keeps the output red. If the input is red, both trains stop behind an entry signal and the output is green. It is possible to use TL0.5-trains (single engine), but the gates work better with TL1-trains (two engines or double engine).
{| align="right"
|| [[File:NOT.png|thumb|430px|right|Two NOT gates, one converting red to green and the other one converting green to red.]]
|| [[File:AND.png|thumb|430px|center|AND "gates" with different input states]]
|-
|}

=== AND ===
AND gates are red if and only if all inputs are red. This is a feature of presignals - an entry or combo signal is red if all exit and combo signals leading to that block are red. There is no (practical) limit on the number of inputs.

=== OR ===
OR gates are red if and only if at least one input is red. There are two ways to implement this: An OR gate or a construction similar to a [[priority]]. The latter method requires less space, but it works only with trains in that signal block itself - you cannot combine arbitrary logic lines like that.
{| align="center"
|| [[File:OR.png|thumb|430px|left|OR gates with different input states]]
|| [[File:OR prio.png|thumb|430px|center|OR, built like a priority]]
|-
|}

== Advanced logic elements ==

[[File:XOR.png|thumb|220px|left|XOR construction, you can see the OR and NOT gate inside]]
[[File:Edge_detector_falling_inverted.png|thumb|220px|right|Falling edge detector (inverted). Output (right) flashes green when input (left) changes from red to green.]]
[[File:Logic traincounter.png|thumb|220px|left|A simple train counter. It can fail if the line jams. The counter train (lower left part) is released if the TL2-train blocks the NOT gate entry, but not the signal block behind and in front of it.]]
[[File:Logic_delay.png|thumb|220px|right|A delay circuit. When the input (top right) turns green, after the train traverses the loop the output (bottom left) will flash green. The delay depends on the speed of the train.]]
[[File:Logic_abs_red_converter.png|thumb|220px|left|A green to absolute red converter (red PURR). The dummy train on the right alternates moves left or right depending on the input, creating the absolute red. Used to make an absolute red based OR gate with the yellow line.]]
=== XOR ===
XOR gates are red if exactly one of its two inputs is red. There is no known elementary gate for this, but it can be built as combination of multiple gates: (A XOR B) = (A OR B) AND (NOT(A AND B)) where A and B are the inputs.

=== Edge detector ===
An edge detector is sensitive to ''changes'' of its input: If the input switches from red to green (or green to red, depending on the implementation), its output becomes green (or red) for some time, and switches back to its original position afterwards. This can be used to detect trains running on a line.

=== Basic train counter ===
A train, running in a loop, can be used as counter: Most of the time, all signals for this train are red. To count up, all signals get green for a short time, and the train travels to the next signal. This can be used to store data, for example in [[Self-regulating Network|self-regulating networks]].

=== Delay ===
A delay has the same output as its input, but it needs some (usually fixed) time to change the output. This can be useful if timing is important.

=== Red -> absolute red ===
A special gate to produce absolute red: A train in a signal block instead of a red presignal.

=== Clocks ===
Clocks are used to track time, for example time after the last train went through a line. See [[:File:Mark Clock.png|Mark's clock]] for an example. A very simple clock can be built with a train and a timetable to stay in a station for x days.

== Applications ==

=== SRNW stations ===
Stations in self-regulating networks are the most common application of logic. The trains themself cannot have a full load order, therefore it is required to control that with logic. Usually, this is done with dummy or feeder trains - they have a full load order, and SRNW trains are allowed to go into a station only if a feeder/dummy train is unloading there.

There are many possible layouts for SRNW stations, some of them are collected in the [[Junctionary_-_Stations_-_Special_Cases|Junctionary]].

[[File:Logic forcedsplit.png|thumb|400px|right|A split for lost trains: If the SL (western exit) is free, the NOT gate switches the twoway signal on the ML to red.]]
=== Flipflop-Split ===
A flipflop is a small memory with two possible states. This allows splits where exactly 50% of the trains go to one side and 50% go to the other side: The flipflop stores the direction of the last train and directs the new train to the other side.

=== Forced Split ===
If trains are lost, their destination at a split can be unpredictable. With a red twoway signal, they can be forced to split in a specific direction.



[[Category:Advanced Networking]]

File:Logic abs red converter.png

2019-08-27T21:11:55Z

Hazzard:

Logic

2019-08-27T21:08:53Z

Hazzard: /* Advanced logic elements */

OpenTTD allows to control trains with [[signals]]. The introduction of presignals allows to build more complex setups - the state of a signal (green/red) does not only depend on the following signal block, but also on other signals. For details, see the signal-article in the OpenTTD wiki [http://wiki.openttd.org/Signals].

Presignals are frequently used to control trains in [[priorities]] and station entries. The combination with [[dummy train]]s, however, allows even more powerful constructions. Signals can be green or red, those states can be identified with 0 and 1, respectively (this is just a convention, it could be used the other way round as well). With trains and signals, it is possible to build all basic computer elements. In theory, it is possible to build a CPU in a game. You could even simulate OpenTTD ''in'' OpenTTD, if map size and computing power would not be a limit.

To keep constructions simple, most logic constructions are built out of several standard elements, called gates. Usually, those gates are separated with combo signals to avoid unplanned influences. If the setup is sensitive to the timing (train A has to arrive before train B or similar), this has to be taken into account in the design. Otherwise, logic gates can be combined in arbitrary way to get the desired output (green/red signals) based on some input (usually: train positions).

== Logic gates ==

There are always many ways to build gates. The constructions shown here are the most simple setups - if space is limited, it is often useful to change their shape a bit.

=== NOT ===
The most common logic gate you will see on coop servers is the NOT gate. It inverts the input: If the input is green, the result is red, if the input is red the result is green. This is done with two trains running on a 3x3-tile ring. If the input is green, they keep moving and at least one train keeps the output red. If the input is red, both trains stop behind an entry signal and the output is green. It is possible to use TL0.5-trains (single engine), but the gates work better with TL1-trains (two engines or double engine).
{| align="right"
|| [[File:NOT.png|thumb|430px|right|Two NOT gates, one converting red to green and the other one converting green to red.]]
|| [[File:AND.png|thumb|430px|center|AND "gates" with different input states]]
|-
|}

=== AND ===
AND gates are red if and only if all inputs are red. This is a feature of presignals - an entry or combo signal is red if all exit and combo signals leading to that block are red. There is no (practical) limit on the number of inputs.

=== OR ===
OR gates are red if and only if at least one input is red. There are two ways to implement this: An OR gate or a construction similar to a [[priority]]. The latter method requires less space, but it works only with trains in that signal block itself - you cannot combine arbitrary logic lines like that.
{| align="center"
|| [[File:OR.png|thumb|430px|left|OR gates with different input states]]
|| [[File:OR prio.png|thumb|430px|center|OR, built like a priority]]
|-
|}

== Advanced logic elements ==

[[File:XOR.png|thumb|220px|left|XOR construction, you can see the OR and NOT gate inside]]
[[File:Edge_detector_falling_inverted.png|thumb|220px|right|Falling edge detector (inverted). Output (right) flashes green when input (left) changes from red to green.]]
[[File:Logic traincounter.png|thumb|220px|left|A simple train counter. It can fail if the line jams. The counter train (lower left part) is released if the TL2-train blocks the NOT gate entry, but not the signal block behind and in front of it.]]
[[File:Logic_delay.png|thumb|220px|right|A delay circuit. When the input (top right) turns green, after the train traverses the loop the output (bottom left) will flash green. The delay depends on the speed of the train.]]
=== XOR ===
XOR gates are red if exactly one of its two inputs is red. There is no known elementary gate for this, but it can be built as combination of multiple gates: (A XOR B) = (A OR B) AND (NOT(A AND B)) where A and B are the inputs.

=== Edge detector ===
An edge detector is sensitive to ''changes'' of its input: If the input switches from red to green (or green to red, depending on the implementation), its output becomes green (or red) for some time, and switches back to its original position afterwards. This can be used to detect trains running on a line.

=== Basic train counter ===
A train, running in a loop, can be used as counter: Most of the time, all signals for this train are red. To count up, all signals get green for a short time, and the train travels to the next signal. This can be used to store data, for example in [[Self-regulating Network|self-regulating networks]].

=== Delay ===
A delay has the same output as its input, but it needs some (usually fixed) time to change the output. This can be useful if timing is important.

=== Red -> absolute red ===
A special gate to produce absolute red: A train in a signal block instead of a red presignal.

=== Clocks ===
Clocks are used to track time, for example time after the last train went through a line. See [[:File:Mark Clock.png|Mark's clock]] for an example. A very simple clock can be built with a train and a timetable to stay in a station for x days.

== Applications ==

=== SRNW stations ===
Stations in self-regulating networks are the most common application of logic. The trains themself cannot have a full load order, therefore it is required to control that with logic. Usually, this is done with dummy or feeder trains - they have a full load order, and SRNW trains are allowed to go into a station only if a feeder/dummy train is unloading there.

There are many possible layouts for SRNW stations, some of them are collected in the [[Junctionary_-_Stations_-_Special_Cases|Junctionary]].

[[File:Logic forcedsplit.png|thumb|400px|right|A split for lost trains: If the SL (western exit) is free, the NOT gate switches the twoway signal on the ML to red.]]
=== Flipflop-Split ===
A flipflop is a small memory with two possible states. This allows splits where exactly 50% of the trains go to one side and 50% go to the other side: The flipflop stores the direction of the last train and directs the new train to the other side.

=== Forced Split ===
If trains are lost, their destination at a split can be unpredictable. With a red twoway signal, they can be forced to split in a specific direction.



[[Category:Advanced Networking]]

Logic

2019-08-27T21:08:33Z

Hazzard: /* Advanced logic elements */

OpenTTD allows to control trains with [[signals]]. The introduction of presignals allows to build more complex setups - the state of a signal (green/red) does not only depend on the following signal block, but also on other signals. For details, see the signal-article in the OpenTTD wiki [http://wiki.openttd.org/Signals].

Presignals are frequently used to control trains in [[priorities]] and station entries. The combination with [[dummy train]]s, however, allows even more powerful constructions. Signals can be green or red, those states can be identified with 0 and 1, respectively (this is just a convention, it could be used the other way round as well). With trains and signals, it is possible to build all basic computer elements. In theory, it is possible to build a CPU in a game. You could even simulate OpenTTD ''in'' OpenTTD, if map size and computing power would not be a limit.

To keep constructions simple, most logic constructions are built out of several standard elements, called gates. Usually, those gates are separated with combo signals to avoid unplanned influences. If the setup is sensitive to the timing (train A has to arrive before train B or similar), this has to be taken into account in the design. Otherwise, logic gates can be combined in arbitrary way to get the desired output (green/red signals) based on some input (usually: train positions).

== Logic gates ==

There are always many ways to build gates. The constructions shown here are the most simple setups - if space is limited, it is often useful to change their shape a bit.

=== NOT ===
The most common logic gate you will see on coop servers is the NOT gate. It inverts the input: If the input is green, the result is red, if the input is red the result is green. This is done with two trains running on a 3x3-tile ring. If the input is green, they keep moving and at least one train keeps the output red. If the input is red, both trains stop behind an entry signal and the output is green. It is possible to use TL0.5-trains (single engine), but the gates work better with TL1-trains (two engines or double engine).
{| align="right"
|| [[File:NOT.png|thumb|430px|right|Two NOT gates, one converting red to green and the other one converting green to red.]]
|| [[File:AND.png|thumb|430px|center|AND "gates" with different input states]]
|-
|}

=== AND ===
AND gates are red if and only if all inputs are red. This is a feature of presignals - an entry or combo signal is red if all exit and combo signals leading to that block are red. There is no (practical) limit on the number of inputs.

=== OR ===
OR gates are red if and only if at least one input is red. There are two ways to implement this: An OR gate or a construction similar to a [[priority]]. The latter method requires less space, but it works only with trains in that signal block itself - you cannot combine arbitrary logic lines like that.
{| align="center"
|| [[File:OR.png|thumb|430px|left|OR gates with different input states]]
|| [[File:OR prio.png|thumb|430px|center|OR, built like a priority]]
|-
|}

== Advanced logic elements ==

[[File:XOR.png|thumb|220px|left|XOR construction, you can see the OR and NOT gate inside]]
[[File:Edge_detector_falling_inverted.png|thumb|220px|right|Falling edge detector (inverted). Output (right) flashes green when input (left) changes from red to green.]]
[[File:Logic traincounter.png|thumb|220px|left|A simple train counter. It can fail if the line jams. The counter train (lower left part) is released if the TL2-train blocks the NOT gate entry, but not the signal block behind and in front of it.]]
[[File:Logic traincounter.png|thumb|220px|right|A delay circuit. When the input (top right) turns green, after the train traverses the loop the output (bottom left) will flash green. The delay depends on the speed of the train.]]
=== XOR ===
XOR gates are red if exactly one of its two inputs is red. There is no known elementary gate for this, but it can be built as combination of multiple gates: (A XOR B) = (A OR B) AND (NOT(A AND B)) where A and B are the inputs.

=== Edge detector ===
An edge detector is sensitive to ''changes'' of its input: If the input switches from red to green (or green to red, depending on the implementation), its output becomes green (or red) for some time, and switches back to its original position afterwards. This can be used to detect trains running on a line.

=== Basic train counter ===
A train, running in a loop, can be used as counter: Most of the time, all signals for this train are red. To count up, all signals get green for a short time, and the train travels to the next signal. This can be used to store data, for example in [[Self-regulating Network|self-regulating networks]].

=== Delay ===
A delay has the same output as its input, but it needs some (usually fixed) time to change the output. This can be useful if timing is important.

=== Red -> absolute red ===
A special gate to produce absolute red: A train in a signal block instead of a red presignal.

=== Clocks ===
Clocks are used to track time, for example time after the last train went through a line. See [[:File:Mark Clock.png|Mark's clock]] for an example. A very simple clock can be built with a train and a timetable to stay in a station for x days.

== Applications ==

=== SRNW stations ===
Stations in self-regulating networks are the most common application of logic. The trains themself cannot have a full load order, therefore it is required to control that with logic. Usually, this is done with dummy or feeder trains - they have a full load order, and SRNW trains are allowed to go into a station only if a feeder/dummy train is unloading there.

There are many possible layouts for SRNW stations, some of them are collected in the [[Junctionary_-_Stations_-_Special_Cases|Junctionary]].

[[File:Logic forcedsplit.png|thumb|400px|right|A split for lost trains: If the SL (western exit) is free, the NOT gate switches the twoway signal on the ML to red.]]
=== Flipflop-Split ===
A flipflop is a small memory with two possible states. This allows splits where exactly 50% of the trains go to one side and 50% go to the other side: The flipflop stores the direction of the last train and directs the new train to the other side.

=== Forced Split ===
If trains are lost, their destination at a split can be unpredictable. With a red twoway signal, they can be forced to split in a specific direction.



[[Category:Advanced Networking]]

2019-07-24T00:32:30Z

Hazzard:

<noinclude>{{JunctionaryLogicAndOtherMenu}}</noinclude>
It is hard to describe [[logic]] shortly since it's very purpose is to do something extra. This section lists mechanisms and thingies that usually control trains somehow, and thus improve how our network works. Although there are for sure cases that are completely useless like train counters.

{{JunctionaryTableHeader|headline=Logic and other constructions <font size="small">([[Logic|what is that?]])}}

{{Junctionary|13/07/2008|[[Image:Lensort.jpg|center|140px|]]|Train Length Sorter|Sorts trains by their length. In this example trains longer than 5 cars (or 2 tiles) will be sorted via the penalty, those of 5 cars or less through the non-penalty line. this is useful when trains of varying type use a station, and some platforms are shorter than others. It can also be used at junctions where there are two options of track, to move shorter trains onto a loop with tighter turns. Finally it may be used to seperate main line trains from local trains (assuming different train lengths). A local train may be forced onto a longer, slower loop to allow mainline trains to pass.|Audigex, original credit unknown.|}}

{{Junctionary|16/12/2008|[[Image:psg121_MarkClock.png|center|140px|]]|Advanced Timer|An advanced timer which works with a certain cycle. Once the dummy train finishes the cycle, a train is released by the timer. However this has one crucial condition - if a train overflows, the whole cycle is cancelled and the counting starts again.|{{User|Mark}}|{{PublicServerGameSave|121}} }}

{{Junctionary|11.01.11|[[Image:psg131_Compressor.png|center|140px|]]|'''Train packing'''|The so called compressor. Waits until a few trains are ready to go and then releases them very close together, allowing trains further down the line join. |{{User|Mark}}|{{PublicServerGameSave|131}} }}

{{Junctionary|11.01.11|[[Image:psg180_flipflop.png|center|140px|]]|'''Flipflop'''|A typical flipflop splitting trains into 6 directions equally. |{{User|V453000}}|{{PublicServerGameSave|180}} }}

{{Junctionary|11.01.11|[[Image:psg196_counter.png|center|140px|]]|'''Counter'''|A mechanism which counts how many trains have passed a certain spot. Completely useless for the network. |{{User|HDIEagle}}|{{PublicServerGameSave|196}} }}

{{Junctionary|11.01.11|[[Image:psg200_comparer.png|center|140px|]]|'''Counter/comparer'''|This array of stations had a special overflow which counted which station gets the least amount of trains and released trains to that. Therefore there are logic mechanisms which count how many trains have passed (based on Mark's clock) and a mechanism which says which station had gotten X trains as the last one. |{{User|V453000}}|{{PublicServerGameSave|200}} }}

{{Junctionary|11.01.11|[[Image:psg203_sparta.png|center|140px|]]|'''Long train abuse'''|This mechanism is meant to pack looong trains in just 3x3. It is very slow due to the effective more than 1xTL signal gap. |{{User|V453000}}|{{PublicServerGameSave|203}} }}

{{Junctionary|11.01.11|[[Image:psg224_flipflop.png|center|140px|]]|'''Flipflop without memory''' (SR-NOR latch)|A very interesting way how to make a flipflop without memories, using the NOT gates swap their states. Unfortunately (probably) only usable for 1:1 split. |{{User|mfb}}|{{PublicServerGameSave|224}} }}

{{Junctionary|16.10.12|[[Image:psg245_split_to_N.png|center|140px|]]|'''Pathfinder-based Perfect N-way split'''|A split from 1 to N (here 7) tracks. Fairly easy to build, with full throughput and does not seem to break. |{{User|V453000}}|{{PublicServerGameSave|245}} }}

{{Junctionary|16.10.12|[[Image:3waysplit.png|center|140px|]]|'''Logic-based Perfect N-way split'''|A split from 1 to N (here 3) tracks. Fail-safe. |{{User|Hazzard}} }}

|}

File:Line hierarchy.PNG

2019-06-19T19:18:37Z

Hazzard: Hazzard uploaded a new version of File:Line hierarchy.PNG

PublicServer:Archive - Games 321 - 330

2019-05-18T05:08:12Z

Hazzard: fix psg 332 start date

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=332
|date= xx.04.19 - 17.05.19
|players= {{User|virtualrandomnumber}}, {{User|Hazzard}}, {{User|V453000}}, {{User|Arveen}}, {{User|tyteen}}
|type=Cargo
|TL=3
|mapsize=512x512 Temperate
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A fairly standard refit game using DB set and TL3 2x BR 182, where we managed to get almost 1800 trains running on the network.
|imagedescription=BBH 02, one of the places with biggest traffic.}}

{{Archive PublicServer
|id=331
|date= 03.07.18 - xx.04.19
|players= {{User|bio}}, {{User|virtualrandomnumber}}, {{User|Jam35}}, {{User|eirc}}, {{User|Maraxus}}, {{User|Arveen}}, {{User|The_Saladman}}, {{User|codertux}}, {{User|dfceaef}}, {{User|Kolo}}
|type=Cargo
|TL=3
|mapsize=512x512 Temperate
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Well, as the only survivor of this PSG (as V called it) I (Arveen) declare this the possibly longest PSG ever. Started during summer 2018 and ending in spring 2019 a lot of construction, expansion and redesign has been done. Massive hubs overgrown small cities and 14 people died during a train accident near Nadingham (RIP 14 passengers on a cargo train).
|imagedescription=We sure like symmetric stuff.}}

{{Archive PublicServer
|id=330
|date= 18.04.18 - 03.07.18
|players= {{User|Vinnie}}, {{User|AlphaSC}}, {{User|loeky}}, {{User|bio}}, {{User|virtualrandomnumber}}, {{User|V453000}}
|type=Cargo
|TL=3 & 5
|mapsize=512x256 Temperate
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=TL3 in the east vs TL5 in the west. See in-game plan for details :)
|imagedescription=Some rails here.}}

{{Archive PublicServer
|id=329
|date= 28.12.17 - 17.04.18
|players= {{User|V453000}}, {{User|Mark}}, {{User|Jam35}}, {{User|Bio}}, {{User|Arveen}}, {{User|Loeky}}, {{User|AlphaSC}}
|type=Tropic
|TL= 2
|mapsize=512x512
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=As most FIRS games, a lot of planning is required to make the network construction go smoothly. We chose a plan where all of the engineering supplies would be distributed evenly to all primaries at a rate sufficient to make them reach maximum production. Only when they would all be at gung-ho and fully serviced, we would add more primaries. Turns out we only needed 2 primary industries of each type to cause massive traffic of 3430 slugs.
|imagedescription=The ES pickup, distributing ES evenly over all industries.}}

{{Archive PublicServer
|id=328
|date= 23.10.17 - 28.12.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Deactivated}}, {{User|Arveen}}, {{User|John}}, {{User|V453000}}, {{User|Imutrainfolks}}, {{User|John}}, {{User|Mark}}
|type=Arctic
|TL= 5
|mapsize=512x256
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Little arctic map to try out the awesome new BRIX. Original trainset's Lev3 Pegasus turned out to be tricky to work with on this small map. In the end we managed to have 750 trains running smoothly on a mostly LLL_RRR network.
|imagedescription=Boats, Trucks, and Trains}}

{{Archive PublicServer
|id=327
|date= 26.07.17 - 23.10.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Arveen}}
|type=Temperate
|TL= 3
|mapsize=512x512
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Another nice game.
|imagedescription=BBH 01}}

{{Archive PublicServer
|id=326
|date= 02.04.17 - 26.07.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Arveen}}
|type=Toyland
|TL= 2
|mapsize=256x256
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A game to welcome BRIX 0.0.1. People built and kept expanding over months which lead the game to end with many trains.
|imagedescription=BRIX apparently doesn't stop people from building a lot of trains.}}

{{Archive PublicServer
|id=325
|date= 30.01.17 - 02.04.17
|players= {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Loeky}}
|type=YETI game utilizing PURR Barcode
|TL= 5
|mapsize=256x512
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A nice game making use of the PURR/MEOW magic for conditional orders on a whole-map scale. Even though this game didn't grow to it's full potential, the system works quite nicely.
|imagedescription=A pickup station with 6 different colour patterns for 6 different outputs.}}

{{Archive PublicServer
|id=324
|date= 14.01.17 - 30.01.17
|players={{User|V453000}}, {{User|Lejving}}, {{User|absolutis}}, {{User|zxbiohazardzx}}, {{User|Jam35}}, {{User|Maraxus}}, {{User|happpy}}, {{User|TheRisen}}, {{User|AzureSpeed|}}, {{User|mari_kari|}}
|type=Standard cargo in Toyland
|TL= 5
|mapsize=512x512
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= There was initially three plans which none of them felt just right, so V453000 took the best part of them all and created the winning plan. The games glory piece was the really big HELL secondary station {{User|V453000}} created, one of the biggest in PSG history. To add further to this we had a nice LLLL_RRRR system going with many good and creative MSHs which the CL 1,5 can take some credit for. Game ended with 2000 trains, capped Fizzy Drinks factory (9180), 8 lane hell and 8 lane drop!
|imagedescription=HELL!}}

{{Archive PublicServer
|id=323
|date= 04.01.17 - 14.01.17
|players={{User|V453000}}, {{User|Lejving}}, {{User|absolutis}}, {{User|zxbiohazardzx}}, {{User|Jam35}}, {{User|Maraxus}}, {{User|Cornelius}}, {{User|TheRisen}}, {{User|Mark}}
|type=Cargo Refit
|TL= 3
|mapsize=1024 x 256
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A simple 'snake' style network with refitting at each end and return stuff to SL drop. We got to 5 lines end to end and 2600+ trains before getting some laggy connections. Game ended slightly prematurely but still a nice game.
|imagedescription=Unfinished in the end but still impressive.}}

{{Archive PublicServer
|id=322
|date= 27.12.16 - 04.01.17
|players={{User|Jam35}}, {{User|Lejving}}, {{User|zxbiohazardzx}}, {{User|V453000}}, {{User|Techinica}}, {{User|Deactivated}}, {{User|fleet75}}, {{User|TheRisen}}
|type=Simplified YETI
|TL= n/a (Many different)
|mapsize=256x512 Sub-arctic
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=An easygoing and short game for the end of 2016. Plan was chaos mode, so we utilized all modes of transportation (planes, ships, trains, rvs, trams). Happy new year!
|imagedescription=Station with nearly all modes of transportation}}

{{Archive PublicServer
|id=321
|date=04.12.16 - 27.12.16
|players={{User|Jam35}}, {{User|Lejving}}, {{User|zxbiohazardzx}}, {{User|lol}}, {{User|Techinica}}, {{User|Maraxus}}, {{User|Ethereal}}, {{User|mari}}, {{User|happpy}}
|type=Cargo
|TL= 4 Maglev 'Get Heavy'
|mapsize=512x512 Arctic
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A cargo game with two drops for most primaries. It was hoped that this would give a balanced network overall with traffic spreading in all directions fairly evenly. This worked to a certain degree with everything needing expansion before returning to expand the same, busier areas again. Some areas ultimately ending with 5 lines .The game was getting hard for some to join so it was ended.
|imagedescription=MSH 04}}

PublicServer:Archive - Games 321 - 330

2019-05-02T05:36:34Z

Hazzard:

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=331
|date= 03.07.18 - xx.04.19
|players= {{User|bio}}, {{User|virtualrandomnumber}}, {{User|Jam35}}, {{User|eirc}}, {{User|Maraxus}}, {{User|Arveen}}, {{User|The_Saladman}}, {{User|codertux}}, {{User|dfceaef}}, {{User|Kolo}}
|type=Cargo
|TL=3
|mapsize=512x512 Temperate
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Well, as the only survivor of this PSG (as V called it) I (Arveen) declare this the possibly longest PSG ever. Started during summer 2018 and ending in spring 2019 a lot of construction, expansion and redesign has been done. Massive hubs overgrown small cities and 14 people died during a train accident near Nadingham (RIP 14 passengers on a cargo train).
|imagedescription=We sure like symmetric stuff.}}

{{Archive PublicServer
|id=330
|date= 18.04.18 - 03.07.18
|players= {{User|Vinnie}}, {{User|AlphaSC}}, {{User|loeky}}, {{User|bio}}, {{User|virtualrandomnumber}}, {{User|V453000}}
|type=Cargo
|TL=3 & 5
|mapsize=512x256 Temperate
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=TL3 in the east vs TL5 in the west. See in-game plan for details :)
|imagedescription=Some rails here.}}

{{Archive PublicServer
|id=329
|date= 28.12.17 - 17.04.18
|players= {{User|V453000}}, {{User|Mark}}, {{User|Jam35}}, {{User|Bio}}, {{User|Arveen}}, {{User|Loeky}}, {{User|AlphaSC}}
|type=Tropic
|TL= 2
|mapsize=512x512
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=As most FIRS games, a lot of planning is required to make the network construction go smoothly. We chose a plan where all of the engineering supplies would be distributed evenly to all primaries at a rate sufficient to make them reach maximum production. Only when they would all be at gung-ho and fully serviced, we would add more primaries. Turns out we only needed 2 primary industries of each type to cause massive traffic of 3430 slugs.
|imagedescription=The ES pickup, distributing ES evenly over all industries.}}

{{Archive PublicServer
|id=328
|date= 23.10.17 - 28.12.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Deactivated}}, {{User|Arveen}}, {{User|John}}, {{User|V453000}}, {{User|Imutrainfolks}}, {{User|John}}, {{User|Mark}}
|type=Arctic
|TL= 5
|mapsize=512x256
|version=r27951 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Little arctic map to try out the awesome new BRIX. Original trainset's Lev3 Pegasus turned out to be tricky to work with on this small map. In the end we managed to have 750 trains running smoothly on a mostly LLL_RRR network.
|imagedescription=Boats, Trucks, and Trains}}

{{Archive PublicServer
|id=327
|date= 26.07.17 - 23.10.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Arveen}}
|type=Temperate
|TL= 3
|mapsize=512x512
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Another nice game.
|imagedescription=BBH 01}}

{{Archive PublicServer
|id=326
|date= 02.04.17 - 26.07.17
|players= {{User|Loeky}}, {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Arveen}}
|type=Toyland
|TL= 2
|mapsize=256x256
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A game to welcome BRIX 0.0.1. People built and kept expanding over months which lead the game to end with many trains.
|imagedescription=BRIX apparently doesn't stop people from building a lot of trains.}}

{{Archive PublicServer
|id=325
|date= 30.01.17 - 02.04.17
|players= {{User|Jam35}}, {{User|Lejving}}, {{User|Maraxus}}, {{User|AzureSpeed|}}, {{User|Vinnie}}, {{User|Clockworker}}, {{User|Deactivated}}, {{User|Loeky}}
|type=YETI game utilizing PURR Barcode
|TL= 5
|mapsize=256x512
|version=r27742 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A nice game making use of the PURR/MEOW magic for conditional orders on a whole-map scale. Even though this game didn't grow to it's full potential, the system works quite nicely.
|imagedescription=A pickup station with 6 different colour patterns for 6 different outputs.}}

{{Archive PublicServer
|id=324
|date= 14.01.17 - 30.01.17
|players={{User|V453000}}, {{User|Lejving}}, {{User|absolutis}}, {{User|zxbiohazardzx}}, {{User|Jam35}}, {{User|Maraxus}}, {{User|happpy}}, {{User|TheRisen}}, {{User|AzureSpeed|}}, {{User|mari_kari|}}
|type=Standard cargo in Toyland
|TL= 5
|mapsize=512x512
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= There was initially three plans which none of them felt just right, so V453000 took the best part of them all and created the winning plan. The games glory piece was the really big HELL secondary station {{User|V453000}} created, one of the biggest in PSG history. To add further to this we had a nice LLLL_RRRR system going with many good and creative MSHs which the CL 1,5 can take some credit for. Game ended with 2000 trains, capped Fizzy Drinks factory (9180), 8 lane hell and 8 lane drop!
|imagedescription=HELL!}}

{{Archive PublicServer
|id=323
|date= 04.01.17 - 14.01.17
|players={{User|V453000}}, {{User|Lejving}}, {{User|absolutis}}, {{User|zxbiohazardzx}}, {{User|Jam35}}, {{User|Maraxus}}, {{User|Cornelius}}, {{User|TheRisen}}, {{User|Mark}}
|type=Cargo Refit
|TL= 3
|mapsize=1024 x 256
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= A simple 'snake' style network with refitting at each end and return stuff to SL drop. We got to 5 lines end to end and 2600+ trains before getting some laggy connections. Game ended slightly prematurely but still a nice game.
|imagedescription=Unfinished in the end but still impressive.}}

{{Archive PublicServer
|id=322
|date= 27.12.16 - 04.01.17
|players={{User|Jam35}}, {{User|Lejving}}, {{User|zxbiohazardzx}}, {{User|V453000}}, {{User|Techinica}}, {{User|Deactivated}}, {{User|fleet75}}, {{User|TheRisen}}
|type=Simplified YETI
|TL= n/a (Many different)
|mapsize=256x512 Sub-arctic
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=An easygoing and short game for the end of 2016. Plan was chaos mode, so we utilized all modes of transportation (planes, ships, trains, rvs, trams). Happy new year!
|imagedescription=Station with nearly all modes of transportation}}

{{Archive PublicServer
|id=321
|date=04.12.16 - 27.12.16
|players={{User|Jam35}}, {{User|Lejving}}, {{User|zxbiohazardzx}}, {{User|lol}}, {{User|Techinica}}, {{User|Maraxus}}, {{User|Ethereal}}, {{User|mari}}, {{User|happpy}}
|type=Cargo
|TL= 4 Maglev 'Get Heavy'
|mapsize=512x512 Arctic
|version=r27680 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A cargo game with two drops for most primaries. It was hoped that this would give a balanced network overall with traffic spreading in all directions fairly evenly. This worked to a certain degree with everything needing expansion before returning to expand the same, busier areas again. Some areas ultimately ending with 5 lines .The game was getting hard for some to join so it was ended.
|imagedescription=MSH 04}}

File:PSG328.png

2019-05-02T05:35:17Z

Hazzard: Boats, Trucks, and Trains

Boats, Trucks, and Trains

File:PSG327.png

2019-05-02T05:29:45Z

Hazzard: BBH 01

BBH 01

File:3waysplit.png

2019-04-28T11:00:26Z

Hazzard: Hazzard uploaded a new version of File:3waysplit.png

2014-10-30T04:53:17Z

Hazzard:

{{obsolete}}
{{Merge |Wiki/Server Administration}}

On this page all the needed commands are shown to administrate a Server via SSH and especially those for administrating the #openttdcoop Servers

=== Servers / Directories ===
====ps.openttdcoop.org====
* 3979 - [[Public Server]]: '''~/svn-publicserver/autopilot/'''
* 0000 - [[Special Server]]: '''~/svn-special/autopilot''' (inactive)
* 0000 - [[Pro Dev Server]]: '''~/svn-dev/autopilot/''' (inactive)
* 3982 - [[ProZone]]: '''~/svn-prozone/autopilot/'''
* 3999 - [[StableServer]] '''~/svn-stable/autopilot/'''

====mz.openttdcoop.org====
* 3979 - [[WWOTTDGD]]: '''~/svn-wwottdgd/autopilot/''' (inactive)
* 3979 - [[YACD]]: ''' ~/svn-yacd/autopilot/'''
* 3980 - [[Member Zone]]: '''~/svn-member/autopilot/''' (inactive)
* 3981 - [[dev server]]: '''~/svn-play-is/autopilot/'''
* 3982 - [[coopetition server]]: '''~/svn-h2h/autopilot/'''
* 3999 - [[StableServer]] '''~/svn-stable/autopilot/'''

Check internal member board for access infos.

=== Connecting to the server ===
* Connect to the server with ssh
* Issue command screen -x
* Issue quit -> ends game without saving
* Issue exit -> ends game with save

=== Starting the Server (via autopilot) ===
* Start a new game: ./autopilot.tcl new | tee logs/<gamenr>.log
* Load the default savegame (save/game.sav): ./autopilot.tcl load | tee logs/<gamenr>.log
* Load another savegame: ./autopilot.tcl load save/game/path.sav | tee logs/<gamenr>.log

=== Reloading the Server (via console) ===
* configure settings with Progman's Config Tool
* save current game with '''save game$Number''' (Recommend to add a number, so you can find it better for archiving.)
* Reload server: '''newgame'''

=== Editing the openttd.cfg ===
'''Common things should be edited with the Configuration Tool: http://openttdcoop.org/config/'''

<div style="font-size: xx-small;">Before you start a new game, the config file has to be edited. Map-Size, diff_custom, [[GRF template for Administrators|NewGrfs]] and need to be set.
* To edit openttd.cfg via SSH you should use vim: '''vi openttd.cfg'''
* To search for a string change to search-mode with '''?''' and type your search string, with '''n''' you can jump to next result.
* To edit a value you have to change to the insert mode with '''i''', then you can edit the values
* To save and leave vim, leave any mode first with '''ESC''', and type ''':wq''' (: = command mode)
* To leave without saving type ''':q!'''
* Some values are a bit confusing, i.e. diff_custom, you can find details about this value on the [[openttd:Diff_custom|openttd.org wiki page]]</div>

To upload a file to the publicserver (usually a .sav), use http://ps.openttdcoop.org/public/config/files.php

=== Updating the server ===

Easy way via script (updates automatically to the last nightly):
* ./update
Patch the server, if needed (see below for details). Make sure the patches apply cleanly. Otherwise fix them or skip them.
* patch -p0 < nomod.diff
* patch -p0 < bb2.diff
* patch -p0 < magic_bulldozer.diff
* patch -p1 < patches/keepBlitterForDedicated.p1.diff
* make bundle
Did the compile work? If so, copy the files:
* cp -Rf bundle/* autopilot
* cd autopilot
* ./autopilot.tcl load | tee -a logs/<gamenr>.log

====Manual update====

* svn up rREV
check, if all files have updated without conflicts (prefix "C"), if there are lines with "C":
* svn revert . -R and reapply the patches
on manual update, you need write the finger manually:
* ./update -w

====Patching Server====
The update script did revert the server build to clean trunk, but maybe we need to patch our server:
the patches need to be multiplayer safe, no information can be saved in the savegame. We store the patches in subfolder patches.
* nomod.diff: it does tell openttd to compile without adding "M" to the version
* bb2.diff: logging the docommands
* magic_bulldozer.diff: enables switch with rcon

First, you apply one patch ('''patch -p0 < patch.diff'''), if there are no errors, you take the next, if there are errors, you revert the apply with -R ('''patch -Rp0 < patch.diff''') and ask the patch creator to update or try self. If all patches are applied, you need to remake: '''make bundle''' (no configure).
copy the bundle to autopilot: '''cp -Rf bundle/ autopilot/'''

====Support for [[Autostart]] and other tools====
To support other tools to update client or homepage with current used revision etc., we need to have the following tags on our server:
* '''rev''': currently used SVN trunk revision
* '''grfversion''': currently used #openttdcoop NewGRF package version
* '''patch.url''': currently used patch (mostly for dev server, link to TT-Forums)
* '''$OS.url''': link to the binary (if it isn't a nightly)

Those "Tags" are located in http://<server>/<port>/
They can be configured over the webconfigurator: config/urls.php

=== Using rcon ===
Some values have to be change in runtime, you can do this really easy with Remote Connection in-game. If you are connected to the Server toggle the Console with '''^''' and use commands:
* To pause/unpause the game: '''rcon password pause/unpause'''
* To change a patch setting: '''rcon password "patch patch_setting value"''' (don't forget the quotation marks)
** To view a value of a setting: '''rcon password "patch patch_setting"'''
** Some settings use namespaces: i.e. '''"patch yapf.rail_use_yapf"'''

=== Archiving a PublicServer Game===
If a game is done do the following step via IRC: !transfer <num> localsave.sav (might be game.sav)
then add a Report to the Wiki (if you don't have time, add at least the date and the used revision!)

== Custom Server Commands ==

===!content===

Update the BaNaNaS content, needs !restart after to load the new NewGRFs

===!gamenr===

Sets the gamenr, needed for the logs and topic, run this before !restart

===!restart===

Restarts the server after update or for newgame

[[Category:Guides]]