#openttdcoop wiki - User contributions [en]

Self-regulating Network

2016-06-06T07:32:52Z

Dwarf: /* Using MEOW Speed as Control */

== The Purpose ==
The idea of Self-regulating network is to have an amount (eventually all) of pickup stations automatically used by one group of trains.

That way we can manage just one train group and service all industries in question automatically - regardless how much each of them produces.

There are many deviations and extra usages of SRNW as you will be able to read down below.
== Technical Requirements ==
To get to know SRNW it is important to be aware of features like [[Two-way end of line|2-way end of line]] and related mechanisms such as [[pathfinder traps]].

Note: Sometimes implicit orders can create serious problems and the train order lists need to be filled with 255 orders in order to prevent creation of implicit orders!

== Sideline waypoint SRNW ==
This is the most basic SRNW design and it is recommended to start with it as the other designs require knowledge of the basics. The basic SRNW will have those key segments:

1. SL works as a ring, while the only way out of the SL is through pickup stations

2. Trains use a waypoint order to be able to load in any of the stations they could possibly end up in, and to make them "want" to go through the stations.

3. As trains do not have a (full load) order in the stations - as they do not have any station orders - we need to make sure that trains get fully loaded. That is solved by various SRNW stations [[Junctionary_-_Stations_-_SRNW|(see junctionary)]] , most typically using dummy trains.'''

After the SL exit there can happen any other order, but most typically an unpload order.

[[File:Basic_SRNW.jpg|500px|thumb|center|Basic SRNW concept.]]

In the beginnings of SRNW, in public server game 121 and later on 149, we used waypoints which made a border of a SL as a closed mechanism, and trains would regulate over the industries connected to that sideline.
As a specific, every SL typically has an overflow which needs to be controlled by some sort of logic, be it timer, on-demand release or clock which detects how long has no train overflown.
===Overflow Release Conditions===
We generally recognize 3 main types of overflow release. Using a '''timer interval'''. Timer is probably the easiest way how to add any overflow control, you have to set it's trigger interval manually though.
Secondly there is the option to''' detect whether there are any free waiting bays''', and releasing trains there eventually. This generally gets to a problem where you release multipler trains towards one waiting bay, because it mostly does not detect trains which are on the way towards the waiting bay.
A good solution could be a '''clock''' - which is made to detect whether any trains have overflown in the last period of time, and eventually release a new train into the circuit if none has overflown. This can work sub-optimally if there is a lot of train waves.
The clock is red all the time, until all the memories become red - by the little running train making a complete loop without being interrupted. Interruption occurs by resetting all memories to green whenever a train overflows.
<gallery>
File:SRNW_Timer.png|A simple timer which blocks trains until going for the next order, usually set by a timetable.
File:SRNW_On_Demand_Release.png|Waiting bay detection for a SL, just like in overflow stations.
File:Mark_Clock.png|Mark's clock
File:SRNW_121orders.png|Typical SRNW orders. Pay special attention to the missing non-stop on the SL Exit order.
</gallery>
{{Archive_ExamplePS|PSG 121|121|The first really large scale SRNW game with a lot of experiments with stations. Many self-regulating twin-sidelines with 2 cargoes used on each.|[[File:SRNW_PSG121plan.png|200px]]}}
{{Archive_ExamplePS|PSG 149|149|Another attempt to make a system of multiple sidelines consisting of 2 cargoes.|[[File:SRNW_PSG149plan.png|200px]]}}
{{Archive_ExamplePS|PSG 172|172|Trying to build a SRNW using 4 cargoes, having a separate network for each cargo. We also noticed that massive stations create huge train waves which can be a problem.|[[File:SRNW_PSG172plan.png|200px]]}}

== Orderless SRNW ==
Later on we tried to use SRNW globally so that trains would not regulate only within a single SL, but on the whole map. To reach absolute universalness of trains, we gave trains no orders (psg157 orders have no real role). That brought immense amount of new complications of constructing splits which tell trains where to actually go. This instance of self-regulation is limited to doing only one thing - pickup and drop at stations which supply/require the cargo. We also only did this with a single cargo type as that would require more split logic.
'''ML->SL Split''' is a necessary mechanism which forces trains into the waiting bay if the bay is empty. Also note the necessity of fail-safe mechanism as the 2-way entry signal on the ML could get red at any time, possibly deadlocking a train.
The biggest problem with orderless trains is that their pathfinding is extremely unpredictable as even 2way eol can easily break.
<gallery>
File:SRNW_157flipflop.png|Flipflop to direct ML traffic.
File:SRNW_157split.png|A counting splitter which forces every 8th train to split.
File:SRNW_180split.png|Forced split when waiting bay is empty, with fail-safe mechanism to avoild deadlocks.
File:SRNW_180trap.png|Pathfinder traps neccesary to make 2way eol work with orderless trains.
File:SRNW_PSG180orders.png|This SRNW has complicated orders.
</gallery>
{{Archive_ExamplePS|PSG 157|157|A specific passenger game which made trains split in equal ratios into all 16 ICE stations on the map, using flipflops, counter splits and similar logic mechanisms.|[[File:SRNW_PSG157plan.png|200px]]}}
{{Archive_ExamplePS|PSG 180|180|Truly global self-regulation split in two halves, each having access all sidelines, furtherly split in North/South drop using flipflops, so both ML ends had the same traffic coming out from the drop towards ML->SL splits. The split also helped to get rid of massive train waves from large synchronized stations.|[[File:SRNW_PSG180plan.png|200px]]}}
{{Archive_ExamplePS|PSG 199|199|A system of 8 rings which overflow into the n+1th, and stay within the ring if they succeed loading.|[[File:SRNW_PSG199plan.png|200px]]}}

== Conditional Order SRNW ==

We also tried to make a self-regulating network where trains would evaluate what to do based on what percentage of cargo they randomly collected. This is rather typically done in passenger games but we also tried it with cargo.

Closely related to this is also a technique of orders by which you can cycle the conditional orders, so that until a train is 100% full, it will be lost. This creates the same effect as orderless trains and can cause some serious issues with directing trains - unless trains go only in a loop of stations, nowhere else - but you still need them to go somewhere else to unload/transfer the cargo they collected. There is a closer article about this, but the technique is not very usable.

http://blog.openttdcoop.org/2010/12/17/a-different-srnw-sl-concept/

'''Another option''' is to make waypoints in a sequence and check train load after each waypoint. This can be necessary for refit SRNW because you still need to have some orders moving to tell trains when to refit - not just an unreachable order which would be "stuck".
We did exactly this in pzg 22 where each SL had four waypoints on the ML, and on the SL exit. Each SL was a shortcut to the waypoint (as ML waypoint was heavily penalized) so trains prefered to try to pick the SL when empty (heading to that waypoint).

Once they reached that waypoint, a conditional order check was made:
If train was full, it went directly to drop - ignoring all following sidelines.
If it was empty, it just continued trying to join a SL and load there.

Obviously after that you are free to use any orders you want - so we used refit to complete the process, and then the trains tried to load primary cargo again.
Trains which failed to load the primary cargo on all four SLs went to refit to the next cargo in the cycle.
All of this allowed for 8 primary cargoes to be serviced, plus their products.

<gallery>
File:SRNW_200orders.png|The orders are rather simple, when the train reaches the end of the loop, it decides what to do.
File:SRNW_pzg22orders.png|A bit longer order list; trains making decisions at checkpoints (waypoints).
</gallery>

{{Archive_ExamplePS|PSG 200|200|As one of the many things we did in this game, we tried SRNW loop with using conditional orders.|[[File:SRNW_200conditionals.png|200px]]}}
{{Archive_ExamplePS|PSG 230|230|One of the stations had a feeder with especially simple conditional orders which even have the exact stations in orders.|[[File:SRNW_230conditionals.png|200px]]}}
{{Archive_ExamplePZ|PZG 22|22|A network which did literally everything with just one train group.|[[File:SRNW_pzg22conditionals.png|200px]]}}

== TL1 Leader / Timed SRNW ==
There were also attempts to make multi-cargo SRNW by making trains go in a certain pattern behind each other, so we would then be able to distinguis cargo type just by counting the TL1 indicator trains which created the spots.
It was also tried with timing the trains instead of creating spots for real trains by TL1 separators.

There is a detailed article available on the blog: http://blog.openttdcoop.org/2012/07/07/orderless-multi-cargo-srnw-my-first-article/

Timing the trains is also a possibility http://wiki.openttdcoop.org/images/f/f5/SRNW_NoOrders1_LoPo.sav

This concept can however be done much simplier just by Unreachable waypoints below.

== Unreachable waypoint SRNW ==
The concept of this kind of SRNW is having trains chase a destination which they can never reach, but they still see the path to it through pathfinder traps.
First off, unreachable waypoint SRNW was just a concept for psg207 which would make SML work as a SRNW mechanism - making trains want to go towards the center of the circle, able to split there, but never able to reach the waypoint thanks to pf traps.
Later on we realized that trains heading towards a waypoint can be very easily directed, allowing for a very feasible multi-cargo SRNW and global SRNWs in general, which we also tried in psg 223. We found out that this idea completely overthrows Orderless SRNW due to vastly reduced complications and increased amount of possibilities. This concept was furtherly re-applied in psg239 where we did it with a total of 7 cargoes.
<gallery>
File:SRNW_207trap.png|Trains believe they can find beer through the inner ring of the SML.
File:SRNW_223split.png|Two separate splits for ore and coal, each having it's own waypoint.
File:SRNW_239split.png|A split which only makes trains splits if they are required by a certain cargo type.
File:SRNW_207orders.png|Trains heading towards station they can never reach. With 255 orders to prevent implicit order creation.
</gallery>
{{Archive_ExamplePS|PSG 207|207|Unique usage of SML, turning it into a SRNW where trains use the inner ring "bait" as exit, making sure trains will not be able to exit the ML until they manage to get to the inner ring - which adds distance and randomness to the splitting towards various ICE stations.|[[File:SRNW_PSG207plan.png|200px]]}}
{{Archive_ExamplePS|PSG 223|223|Two-cargo SRNW which directs trains based on two waypoints which could never be reached.|[[File:SRNW_PSG223plan.png|200px]]}}
{{Archive_ExamplePS|PSG 239|239|Having 7 cargoes brings some new problems as it is inconvenient to separate all 7 cargoes at each SL split, we even tried to make some splits which would be able to all that at once.|[[File:SRNW_PSG239plan.png|200px]]}}

== Refit SRNW ==

When it comes to multi-cargo SRNW, we wanted not only to have a few separate groups of trains running on the same network, each group taking care of their own primaries. We wanted to have all trains be able to adapt to what cargo is needed to be transported on that SL.
Therefore we did a series of conditional orders and refits, refitting until trains find cargo to load. This is typically done by having a waypoint like "Fruit Check". When trains go through the waypoint, they look if they have loaded or not - by conditional orders. If they did not load, they apparently need to refit and try again with another cargo. If they did load, they just proceed towards the drop. Making the "0% load" check behind a reverser is important in order to make trains prefer going towards the loading station (this could also be solved by massive penalties but reversers are more reliable).
<gallery>
File:SRNW_214check.png|The decision point, did the train exit station and is full, or did it pass around empty and needs refit to next cargo?
File:SRNW_214orders.png|Typical train orders for refit SRNW. If empty, refit to next cargo.
</gallery>
{{Archive_ExamplePS|PSG 214|214|Every SL has one group of trains which is able to take care of all the 4 cargoes there, no matter how much of which cargo is available.|[[File:SRNW_PSG214plan.png|200px]]}}

=== Using MEOW Speed as Control ===

A drawback of the above scheme is that trains have to cycle through all cargo types to find which cargo is available to load. In order to allow trains to enter whatever station that has an open platform, they have to be able to detect which station they entered. A way to do it, is to use MEOW trains that change maximum speed based on the purr color, and conditional orders with maximum speed as the condition.

SL4 in PSG297 used this idea. Every station on the SL has a WP that can be reached both on the station entrance and further up on the sideline. Going towards the station the red purr has higher speed, when the WP is passed, the conditional order jump is evaluated. If the maximum speed is high, it jumps to orders to refit to the appropriate cargo and deliver it, otherwise the train goes on to visit the next WP.

{{Archive_ExamplePS|PSG 297|297|Every station on the SL has a WP, if the train manages to enter the station, it gets on the red purr, max speed is increased, and orders appropriate for that station are activated. Otherwise it continues to the next station on the SL.|[[File:SRNW_PSG297.png|200px]]}}

A variation of this method is to essentially use the trains as "barcode scanners", to let them know which cargo type the station they are entering will have. A sideline uses only two waypoints (as many waypoints, a the number of dits required to identify the cargo type by a color code). This has the advantage that the order lists for trains on different sidelines can be almost identical, except for the WP name, adding new stations doesn't require any changes to the order list. A drawback is that all the station entrances on the SL have the same WP's, limiting the size. This can be circumvented by adding a color code to let the trains know that they are leaving the coverage area of a given WP, and switching to a new set of orders using different WP's.
<gallery>
File:SRNW_multicargo_example.png|Example refit SRNW with two stations with different color codes to identify the cargo type, the color code dictionary and order list.
</gallery>

== See also ==

*[[Self-regulating SBahn]]
*[[SML]]
*[[User:V453000/TLS|Train Length Splitters]]

[[Category:Gametypes]]
[[Category:Advanced Networking]]

Self-regulating Network

2016-06-06T07:20:31Z

Dwarf: /* Refit SRNW */

== The Purpose ==
The idea of Self-regulating network is to have an amount (eventually all) of pickup stations automatically used by one group of trains.

That way we can manage just one train group and service all industries in question automatically - regardless how much each of them produces.

There are many deviations and extra usages of SRNW as you will be able to read down below.
== Technical Requirements ==
To get to know SRNW it is important to be aware of features like [[Two-way end of line|2-way end of line]] and related mechanisms such as [[pathfinder traps]].

Note: Sometimes implicit orders can create serious problems and the train order lists need to be filled with 255 orders in order to prevent creation of implicit orders!

== Sideline waypoint SRNW ==
This is the most basic SRNW design and it is recommended to start with it as the other designs require knowledge of the basics. The basic SRNW will have those key segments:

1. SL works as a ring, while the only way out of the SL is through pickup stations

2. Trains use a waypoint order to be able to load in any of the stations they could possibly end up in, and to make them "want" to go through the stations.

3. As trains do not have a (full load) order in the stations - as they do not have any station orders - we need to make sure that trains get fully loaded. That is solved by various SRNW stations [[Junctionary_-_Stations_-_SRNW|(see junctionary)]] , most typically using dummy trains.'''

After the SL exit there can happen any other order, but most typically an unpload order.

[[File:Basic_SRNW.jpg|500px|thumb|center|Basic SRNW concept.]]

In the beginnings of SRNW, in public server game 121 and later on 149, we used waypoints which made a border of a SL as a closed mechanism, and trains would regulate over the industries connected to that sideline.
As a specific, every SL typically has an overflow which needs to be controlled by some sort of logic, be it timer, on-demand release or clock which detects how long has no train overflown.
===Overflow Release Conditions===
We generally recognize 3 main types of overflow release. Using a '''timer interval'''. Timer is probably the easiest way how to add any overflow control, you have to set it's trigger interval manually though.
Secondly there is the option to''' detect whether there are any free waiting bays''', and releasing trains there eventually. This generally gets to a problem where you release multipler trains towards one waiting bay, because it mostly does not detect trains which are on the way towards the waiting bay.
A good solution could be a '''clock''' - which is made to detect whether any trains have overflown in the last period of time, and eventually release a new train into the circuit if none has overflown. This can work sub-optimally if there is a lot of train waves.
The clock is red all the time, until all the memories become red - by the little running train making a complete loop without being interrupted. Interruption occurs by resetting all memories to green whenever a train overflows.
<gallery>
File:SRNW_Timer.png|A simple timer which blocks trains until going for the next order, usually set by a timetable.
File:SRNW_On_Demand_Release.png|Waiting bay detection for a SL, just like in overflow stations.
File:Mark_Clock.png|Mark's clock
File:SRNW_121orders.png|Typical SRNW orders. Pay special attention to the missing non-stop on the SL Exit order.
</gallery>
{{Archive_ExamplePS|PSG 121|121|The first really large scale SRNW game with a lot of experiments with stations. Many self-regulating twin-sidelines with 2 cargoes used on each.|[[File:SRNW_PSG121plan.png|200px]]}}
{{Archive_ExamplePS|PSG 149|149|Another attempt to make a system of multiple sidelines consisting of 2 cargoes.|[[File:SRNW_PSG149plan.png|200px]]}}
{{Archive_ExamplePS|PSG 172|172|Trying to build a SRNW using 4 cargoes, having a separate network for each cargo. We also noticed that massive stations create huge train waves which can be a problem.|[[File:SRNW_PSG172plan.png|200px]]}}

== Orderless SRNW ==
Later on we tried to use SRNW globally so that trains would not regulate only within a single SL, but on the whole map. To reach absolute universalness of trains, we gave trains no orders (psg157 orders have no real role). That brought immense amount of new complications of constructing splits which tell trains where to actually go. This instance of self-regulation is limited to doing only one thing - pickup and drop at stations which supply/require the cargo. We also only did this with a single cargo type as that would require more split logic.
'''ML->SL Split''' is a necessary mechanism which forces trains into the waiting bay if the bay is empty. Also note the necessity of fail-safe mechanism as the 2-way entry signal on the ML could get red at any time, possibly deadlocking a train.
The biggest problem with orderless trains is that their pathfinding is extremely unpredictable as even 2way eol can easily break.
<gallery>
File:SRNW_157flipflop.png|Flipflop to direct ML traffic.
File:SRNW_157split.png|A counting splitter which forces every 8th train to split.
File:SRNW_180split.png|Forced split when waiting bay is empty, with fail-safe mechanism to avoild deadlocks.
File:SRNW_180trap.png|Pathfinder traps neccesary to make 2way eol work with orderless trains.
File:SRNW_PSG180orders.png|This SRNW has complicated orders.
</gallery>
{{Archive_ExamplePS|PSG 157|157|A specific passenger game which made trains split in equal ratios into all 16 ICE stations on the map, using flipflops, counter splits and similar logic mechanisms.|[[File:SRNW_PSG157plan.png|200px]]}}
{{Archive_ExamplePS|PSG 180|180|Truly global self-regulation split in two halves, each having access all sidelines, furtherly split in North/South drop using flipflops, so both ML ends had the same traffic coming out from the drop towards ML->SL splits. The split also helped to get rid of massive train waves from large synchronized stations.|[[File:SRNW_PSG180plan.png|200px]]}}
{{Archive_ExamplePS|PSG 199|199|A system of 8 rings which overflow into the n+1th, and stay within the ring if they succeed loading.|[[File:SRNW_PSG199plan.png|200px]]}}

== Conditional Order SRNW ==

We also tried to make a self-regulating network where trains would evaluate what to do based on what percentage of cargo they randomly collected. This is rather typically done in passenger games but we also tried it with cargo.

Closely related to this is also a technique of orders by which you can cycle the conditional orders, so that until a train is 100% full, it will be lost. This creates the same effect as orderless trains and can cause some serious issues with directing trains - unless trains go only in a loop of stations, nowhere else - but you still need them to go somewhere else to unload/transfer the cargo they collected. There is a closer article about this, but the technique is not very usable.

http://blog.openttdcoop.org/2010/12/17/a-different-srnw-sl-concept/

'''Another option''' is to make waypoints in a sequence and check train load after each waypoint. This can be necessary for refit SRNW because you still need to have some orders moving to tell trains when to refit - not just an unreachable order which would be "stuck".
We did exactly this in pzg 22 where each SL had four waypoints on the ML, and on the SL exit. Each SL was a shortcut to the waypoint (as ML waypoint was heavily penalized) so trains prefered to try to pick the SL when empty (heading to that waypoint).

Once they reached that waypoint, a conditional order check was made:
If train was full, it went directly to drop - ignoring all following sidelines.
If it was empty, it just continued trying to join a SL and load there.

Obviously after that you are free to use any orders you want - so we used refit to complete the process, and then the trains tried to load primary cargo again.
Trains which failed to load the primary cargo on all four SLs went to refit to the next cargo in the cycle.
All of this allowed for 8 primary cargoes to be serviced, plus their products.

<gallery>
File:SRNW_200orders.png|The orders are rather simple, when the train reaches the end of the loop, it decides what to do.
File:SRNW_pzg22orders.png|A bit longer order list; trains making decisions at checkpoints (waypoints).
</gallery>

{{Archive_ExamplePS|PSG 200|200|As one of the many things we did in this game, we tried SRNW loop with using conditional orders.|[[File:SRNW_200conditionals.png|200px]]}}
{{Archive_ExamplePS|PSG 230|230|One of the stations had a feeder with especially simple conditional orders which even have the exact stations in orders.|[[File:SRNW_230conditionals.png|200px]]}}
{{Archive_ExamplePZ|PZG 22|22|A network which did literally everything with just one train group.|[[File:SRNW_pzg22conditionals.png|200px]]}}

== TL1 Leader / Timed SRNW ==
There were also attempts to make multi-cargo SRNW by making trains go in a certain pattern behind each other, so we would then be able to distinguis cargo type just by counting the TL1 indicator trains which created the spots.
It was also tried with timing the trains instead of creating spots for real trains by TL1 separators.

There is a detailed article available on the blog: http://blog.openttdcoop.org/2012/07/07/orderless-multi-cargo-srnw-my-first-article/

Timing the trains is also a possibility http://wiki.openttdcoop.org/images/f/f5/SRNW_NoOrders1_LoPo.sav

This concept can however be done much simplier just by Unreachable waypoints below.

== Unreachable waypoint SRNW ==
The concept of this kind of SRNW is having trains chase a destination which they can never reach, but they still see the path to it through pathfinder traps.
First off, unreachable waypoint SRNW was just a concept for psg207 which would make SML work as a SRNW mechanism - making trains want to go towards the center of the circle, able to split there, but never able to reach the waypoint thanks to pf traps.
Later on we realized that trains heading towards a waypoint can be very easily directed, allowing for a very feasible multi-cargo SRNW and global SRNWs in general, which we also tried in psg 223. We found out that this idea completely overthrows Orderless SRNW due to vastly reduced complications and increased amount of possibilities. This concept was furtherly re-applied in psg239 where we did it with a total of 7 cargoes.
<gallery>
File:SRNW_207trap.png|Trains believe they can find beer through the inner ring of the SML.
File:SRNW_223split.png|Two separate splits for ore and coal, each having it's own waypoint.
File:SRNW_239split.png|A split which only makes trains splits if they are required by a certain cargo type.
File:SRNW_207orders.png|Trains heading towards station they can never reach. With 255 orders to prevent implicit order creation.
</gallery>
{{Archive_ExamplePS|PSG 207|207|Unique usage of SML, turning it into a SRNW where trains use the inner ring "bait" as exit, making sure trains will not be able to exit the ML until they manage to get to the inner ring - which adds distance and randomness to the splitting towards various ICE stations.|[[File:SRNW_PSG207plan.png|200px]]}}
{{Archive_ExamplePS|PSG 223|223|Two-cargo SRNW which directs trains based on two waypoints which could never be reached.|[[File:SRNW_PSG223plan.png|200px]]}}
{{Archive_ExamplePS|PSG 239|239|Having 7 cargoes brings some new problems as it is inconvenient to separate all 7 cargoes at each SL split, we even tried to make some splits which would be able to all that at once.|[[File:SRNW_PSG239plan.png|200px]]}}

== Refit SRNW ==

When it comes to multi-cargo SRNW, we wanted not only to have a few separate groups of trains running on the same network, each group taking care of their own primaries. We wanted to have all trains be able to adapt to what cargo is needed to be transported on that SL.
Therefore we did a series of conditional orders and refits, refitting until trains find cargo to load. This is typically done by having a waypoint like "Fruit Check". When trains go through the waypoint, they look if they have loaded or not - by conditional orders. If they did not load, they apparently need to refit and try again with another cargo. If they did load, they just proceed towards the drop. Making the "0% load" check behind a reverser is important in order to make trains prefer going towards the loading station (this could also be solved by massive penalties but reversers are more reliable).
<gallery>
File:SRNW_214check.png|The decision point, did the train exit station and is full, or did it pass around empty and needs refit to next cargo?
File:SRNW_214orders.png|Typical train orders for refit SRNW. If empty, refit to next cargo.
</gallery>
{{Archive_ExamplePS|PSG 214|214|Every SL has one group of trains which is able to take care of all the 4 cargoes there, no matter how much of which cargo is available.|[[File:SRNW_PSG214plan.png|200px]]}}

=== Using MEOW Speed as Control ===

A drawback of the above scheme is that trains have to cycle through all cargo types to find which cargo is available to load. In order to allow trains to enter whatever station that has an open platform, they have to be able to detect which station they entered. A way to do it, is to use rails with different speed after the split to a station, and conditional orders with maximum speed as the condition.

SL4 in PSG297 used this idea. Every station on the SL has a WP that can be reached both on the station entrance and further up on the sideline. Going towards the station the rail has higher speed, when the WP is passed, the conditional order jump is evaluated. If the maximum speed is high, it jumps to orders to refit to the appropriate cargo and deliver it, otherwise the train goes on to visit the next WP.

{{Archive_ExamplePS|PSG 297|297|Every station on the SL has a WP, if the train manages to enter the station, it gets on the red purr, max speed is increased, and orders appropriate for that station are activated. Otherwise it continues to the next station on the SL.|[[File:SRNW_PSG297.png|200px]]}}

A variation of this method is to essentially use the trains as "barcode scanners", to let them know which cargo type the station they are entering will have. A sideline uses only two waypoints (as many waypoints, a the number of dits required to identify the cargo type by a color code). This has the advantage that the order lists for trains on different sidelines can be almost identical, except for the WP name, adding new stations doesn't require any changes to the order list. A drawback is that all the station entrances on the SL have the same WP's, limiting the size. This can be circumvented by adding a color code to let the trains know that they are leaving the coverage area of a given WP, and switching to a new set of orders using different WP's.
<gallery>
File:SRNW_multicargo_example.png|Example refit SRNW with two stations with different color codes to identify the cargo type, the color code dictionary and order list.
</gallery>

== See also ==

*[[Self-regulating SBahn]]
*[[SML]]
*[[User:V453000/TLS|Train Length Splitters]]

[[Category:Gametypes]]
[[Category:Advanced Networking]]

Self-regulating Network

2016-06-06T06:47:08Z

Dwarf: /* Refit SRNW */ Added section for SRNW controlled by MEOW speed limit change.

== The Purpose ==
The idea of Self-regulating network is to have an amount (eventually all) of pickup stations automatically used by one group of trains.

That way we can manage just one train group and service all industries in question automatically - regardless how much each of them produces.

There are many deviations and extra usages of SRNW as you will be able to read down below.
== Technical Requirements ==
To get to know SRNW it is important to be aware of features like [[Two-way end of line|2-way end of line]] and related mechanisms such as [[pathfinder traps]].

Note: Sometimes implicit orders can create serious problems and the train order lists need to be filled with 255 orders in order to prevent creation of implicit orders!

== Sideline waypoint SRNW ==
This is the most basic SRNW design and it is recommended to start with it as the other designs require knowledge of the basics. The basic SRNW will have those key segments:

1. SL works as a ring, while the only way out of the SL is through pickup stations

2. Trains use a waypoint order to be able to load in any of the stations they could possibly end up in, and to make them "want" to go through the stations.

3. As trains do not have a (full load) order in the stations - as they do not have any station orders - we need to make sure that trains get fully loaded. That is solved by various SRNW stations [[Junctionary_-_Stations_-_SRNW|(see junctionary)]] , most typically using dummy trains.'''

After the SL exit there can happen any other order, but most typically an unpload order.

[[File:Basic_SRNW.jpg|500px|thumb|center|Basic SRNW concept.]]

In the beginnings of SRNW, in public server game 121 and later on 149, we used waypoints which made a border of a SL as a closed mechanism, and trains would regulate over the industries connected to that sideline.
As a specific, every SL typically has an overflow which needs to be controlled by some sort of logic, be it timer, on-demand release or clock which detects how long has no train overflown.
===Overflow Release Conditions===
We generally recognize 3 main types of overflow release. Using a '''timer interval'''. Timer is probably the easiest way how to add any overflow control, you have to set it's trigger interval manually though.
Secondly there is the option to''' detect whether there are any free waiting bays''', and releasing trains there eventually. This generally gets to a problem where you release multipler trains towards one waiting bay, because it mostly does not detect trains which are on the way towards the waiting bay.
A good solution could be a '''clock''' - which is made to detect whether any trains have overflown in the last period of time, and eventually release a new train into the circuit if none has overflown. This can work sub-optimally if there is a lot of train waves.
The clock is red all the time, until all the memories become red - by the little running train making a complete loop without being interrupted. Interruption occurs by resetting all memories to green whenever a train overflows.
<gallery>
File:SRNW_Timer.png|A simple timer which blocks trains until going for the next order, usually set by a timetable.
File:SRNW_On_Demand_Release.png|Waiting bay detection for a SL, just like in overflow stations.
File:Mark_Clock.png|Mark's clock
File:SRNW_121orders.png|Typical SRNW orders. Pay special attention to the missing non-stop on the SL Exit order.
</gallery>
{{Archive_ExamplePS|PSG 121|121|The first really large scale SRNW game with a lot of experiments with stations. Many self-regulating twin-sidelines with 2 cargoes used on each.|[[File:SRNW_PSG121plan.png|200px]]}}
{{Archive_ExamplePS|PSG 149|149|Another attempt to make a system of multiple sidelines consisting of 2 cargoes.|[[File:SRNW_PSG149plan.png|200px]]}}
{{Archive_ExamplePS|PSG 172|172|Trying to build a SRNW using 4 cargoes, having a separate network for each cargo. We also noticed that massive stations create huge train waves which can be a problem.|[[File:SRNW_PSG172plan.png|200px]]}}

== Orderless SRNW ==
Later on we tried to use SRNW globally so that trains would not regulate only within a single SL, but on the whole map. To reach absolute universalness of trains, we gave trains no orders (psg157 orders have no real role). That brought immense amount of new complications of constructing splits which tell trains where to actually go. This instance of self-regulation is limited to doing only one thing - pickup and drop at stations which supply/require the cargo. We also only did this with a single cargo type as that would require more split logic.
'''ML->SL Split''' is a necessary mechanism which forces trains into the waiting bay if the bay is empty. Also note the necessity of fail-safe mechanism as the 2-way entry signal on the ML could get red at any time, possibly deadlocking a train.
The biggest problem with orderless trains is that their pathfinding is extremely unpredictable as even 2way eol can easily break.
<gallery>
File:SRNW_157flipflop.png|Flipflop to direct ML traffic.
File:SRNW_157split.png|A counting splitter which forces every 8th train to split.
File:SRNW_180split.png|Forced split when waiting bay is empty, with fail-safe mechanism to avoild deadlocks.
File:SRNW_180trap.png|Pathfinder traps neccesary to make 2way eol work with orderless trains.
File:SRNW_PSG180orders.png|This SRNW has complicated orders.
</gallery>
{{Archive_ExamplePS|PSG 157|157|A specific passenger game which made trains split in equal ratios into all 16 ICE stations on the map, using flipflops, counter splits and similar logic mechanisms.|[[File:SRNW_PSG157plan.png|200px]]}}
{{Archive_ExamplePS|PSG 180|180|Truly global self-regulation split in two halves, each having access all sidelines, furtherly split in North/South drop using flipflops, so both ML ends had the same traffic coming out from the drop towards ML->SL splits. The split also helped to get rid of massive train waves from large synchronized stations.|[[File:SRNW_PSG180plan.png|200px]]}}
{{Archive_ExamplePS|PSG 199|199|A system of 8 rings which overflow into the n+1th, and stay within the ring if they succeed loading.|[[File:SRNW_PSG199plan.png|200px]]}}

== Conditional Order SRNW ==

We also tried to make a self-regulating network where trains would evaluate what to do based on what percentage of cargo they randomly collected. This is rather typically done in passenger games but we also tried it with cargo.

Closely related to this is also a technique of orders by which you can cycle the conditional orders, so that until a train is 100% full, it will be lost. This creates the same effect as orderless trains and can cause some serious issues with directing trains - unless trains go only in a loop of stations, nowhere else - but you still need them to go somewhere else to unload/transfer the cargo they collected. There is a closer article about this, but the technique is not very usable.

http://blog.openttdcoop.org/2010/12/17/a-different-srnw-sl-concept/

'''Another option''' is to make waypoints in a sequence and check train load after each waypoint. This can be necessary for refit SRNW because you still need to have some orders moving to tell trains when to refit - not just an unreachable order which would be "stuck".
We did exactly this in pzg 22 where each SL had four waypoints on the ML, and on the SL exit. Each SL was a shortcut to the waypoint (as ML waypoint was heavily penalized) so trains prefered to try to pick the SL when empty (heading to that waypoint).

Once they reached that waypoint, a conditional order check was made:
If train was full, it went directly to drop - ignoring all following sidelines.
If it was empty, it just continued trying to join a SL and load there.

Obviously after that you are free to use any orders you want - so we used refit to complete the process, and then the trains tried to load primary cargo again.
Trains which failed to load the primary cargo on all four SLs went to refit to the next cargo in the cycle.
All of this allowed for 8 primary cargoes to be serviced, plus their products.

<gallery>
File:SRNW_200orders.png|The orders are rather simple, when the train reaches the end of the loop, it decides what to do.
File:SRNW_pzg22orders.png|A bit longer order list; trains making decisions at checkpoints (waypoints).
</gallery>

{{Archive_ExamplePS|PSG 200|200|As one of the many things we did in this game, we tried SRNW loop with using conditional orders.|[[File:SRNW_200conditionals.png|200px]]}}
{{Archive_ExamplePS|PSG 230|230|One of the stations had a feeder with especially simple conditional orders which even have the exact stations in orders.|[[File:SRNW_230conditionals.png|200px]]}}
{{Archive_ExamplePZ|PZG 22|22|A network which did literally everything with just one train group.|[[File:SRNW_pzg22conditionals.png|200px]]}}

== TL1 Leader / Timed SRNW ==
There were also attempts to make multi-cargo SRNW by making trains go in a certain pattern behind each other, so we would then be able to distinguis cargo type just by counting the TL1 indicator trains which created the spots.
It was also tried with timing the trains instead of creating spots for real trains by TL1 separators.

There is a detailed article available on the blog: http://blog.openttdcoop.org/2012/07/07/orderless-multi-cargo-srnw-my-first-article/

Timing the trains is also a possibility http://wiki.openttdcoop.org/images/f/f5/SRNW_NoOrders1_LoPo.sav

This concept can however be done much simplier just by Unreachable waypoints below.

== Unreachable waypoint SRNW ==
The concept of this kind of SRNW is having trains chase a destination which they can never reach, but they still see the path to it through pathfinder traps.
First off, unreachable waypoint SRNW was just a concept for psg207 which would make SML work as a SRNW mechanism - making trains want to go towards the center of the circle, able to split there, but never able to reach the waypoint thanks to pf traps.
Later on we realized that trains heading towards a waypoint can be very easily directed, allowing for a very feasible multi-cargo SRNW and global SRNWs in general, which we also tried in psg 223. We found out that this idea completely overthrows Orderless SRNW due to vastly reduced complications and increased amount of possibilities. This concept was furtherly re-applied in psg239 where we did it with a total of 7 cargoes.
<gallery>
File:SRNW_207trap.png|Trains believe they can find beer through the inner ring of the SML.
File:SRNW_223split.png|Two separate splits for ore and coal, each having it's own waypoint.
File:SRNW_239split.png|A split which only makes trains splits if they are required by a certain cargo type.
File:SRNW_207orders.png|Trains heading towards station they can never reach. With 255 orders to prevent implicit order creation.
</gallery>
{{Archive_ExamplePS|PSG 207|207|Unique usage of SML, turning it into a SRNW where trains use the inner ring "bait" as exit, making sure trains will not be able to exit the ML until they manage to get to the inner ring - which adds distance and randomness to the splitting towards various ICE stations.|[[File:SRNW_PSG207plan.png|200px]]}}
{{Archive_ExamplePS|PSG 223|223|Two-cargo SRNW which directs trains based on two waypoints which could never be reached.|[[File:SRNW_PSG223plan.png|200px]]}}
{{Archive_ExamplePS|PSG 239|239|Having 7 cargoes brings some new problems as it is inconvenient to separate all 7 cargoes at each SL split, we even tried to make some splits which would be able to all that at once.|[[File:SRNW_PSG239plan.png|200px]]}}

== Refit SRNW ==

When it comes to multi-cargo SRNW, we wanted not only to have a few separate groups of trains running on the same network, each group taking care of their own primaries. We wanted to have all trains be able to adapt to what cargo is needed to be transported on that SL.
Therefore we did a series of conditional orders and refits, refitting until trains find cargo to load. This is typically done by having a waypoint like "Fruit Check". When trains go through the waypoint, they look if they have loaded or not - by conditional orders. If they did not load, they apparently need to refit and try again with another cargo. If they did load, they just proceed towards the drop. Making the "0% load" check behind a reverser is important in order to make trains prefer going towards the loading station (this could also be solved by massive penalties but reversers are more reliable).
<gallery>
File:SRNW_214check.png|The decision point, did the train exit station and is full, or did it pass around empty and needs refit to next cargo?
File:SRNW_214orders.png|Typical train orders for refit SRNW. If empty, refit to next cargo.
</gallery>
{{Archive_ExamplePS|PSG 214|214|Every SL has one group of trains which is able to take care of all the 4 cargoes there, no matter how much of which cargo is available.|[[File:SRNW_PSG214plan.png|200px]]}}

=== Using MEOW Speed as Control ===

A drawback of the above scheme is that trains have to cycle through all cargo types to find which cargo is available to load. In order to allow trains to enter whatever station that has an open platform, they have to be able to detect which station they entered. A way to do it, is to use rails with different speed after the split to a station, and conditional orders with maximum speed as the condition.

SL4 in PSG297 used this idea. Every station on the SL has a WP both going towards the station and going on towards the line. Going towards the station the rail has higher speed, when the WP is passed, the conditional order jump is evaluated. If the maximum speed is high, it jumps to orders to refit to the appropriate cargo and deliver it, otherwise the train goes on to visit the next WP.

{{Archive_ExamplePS|PSG 297|297|Every station on the SL has a WP, if the train manages to enter the station, it gets on the red purr, max speed is increased, and orders appropriate for that station are activated. Otherwise it continues to the next station on the SL.|[[File:SRNW_PSG297.png|200px]]}}

A variation of this method is to essentially use the trains as "barcode scanners", to let them know which cargo type the station they are entering will have. A sideline uses only two waypoints (as many waypoints, a the number of dits required to identify the cargo type by a color code). This has the advantage that the order lists for trains on different sidelines can be almost identical, except for the WP name, adding new stations doesn't require any changes to the order list. A drawback is that all the station entrances on the SL have the same WP's, limiting the size. This can be circumvented by adding a color code to let the trains know that they are leaving the coverage area of a given WP, and switching to a new set of orders using different WP's.
<gallery>
File:SRNW_multicargo_example.png|Example refit SRNW with two stations with different color codes to identify the cargo type, the color code dictionary and order list.
</gallery>

== See also ==

*[[Self-regulating SBahn]]
*[[SML]]
*[[User:V453000/TLS|Train Length Splitters]]

[[Category:Gametypes]]
[[Category:Advanced Networking]]

File:SRNW multicargo example.png

2016-06-06T06:40:56Z

Dwarf: Example refit SRNW with two stations with different color codes to identify the cargo type, the color code dictionary and order list.

Example refit SRNW with two stations with different color codes to identify the cargo type, the color code dictionary and order list.

File:SRNW PSG297.png

2016-06-06T06:29:48Z

Dwarf: Example of refit SRNW using conditional orders with different rail speeds.

Example of refit SRNW using conditional orders with different rail speeds.

PublicServer:Archive - Games 311 - 320

2016-06-03T19:15:41Z

Dwarf: some more words for PSG 314

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=314
|date=04.05.16 - 03.06.16
|players={{User|Mark}}, {{User|Dwarf}}, {{User|Jam35}}, {{User|lol}}, {{User|Sietse}}, {{User|BiG_MEECH}}, {{User|Absolutis}}, {{User|barnex}}, {{User|bubbleheads}}, {{User|Maraxus}}, {{User|NCommander}}, {{User|Tray}}, {{User|tyteen4a03}}
|type=YETI cargo (tired yeti mode)
|TL= 3 "Get Heavy"
|mapsize=512x512 Tropic
|version=r27534 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The game was a test of the new YETI release. A new mode using tired Yeti that need to return to Yeti yards was used. Instead of doing things simply though, we chose to refit trains everywhere giving us a few groups of trains with many orders. With no trains running empty we achieved huge amounts of delivered cargo for the number of trains.
End game train count was 2100 with no jams, most of the network was upgraded to 4 lines and 3 YETI yards were running near maximum production.
|imagedescription= One of the Yeti yard stations and hub. }}

{{Archive PublicServer
|id=313
|date=20.04.16 - 04.05.16
|players={{User|Jam35}}, {{User|Clockworker}}, {{User|Ramsvs}}, {{User|lol}}, {{User|Absolutis}}, {{User|damalix}}, {{User|tyteen4a03}}, {{User|Mark}}, {{User|bubbleheads}}, {{User|DyeH}}, {{User|Sietse}}, {{User|Maraxus}}, {{User|NCommander}}, {{User|Ben_}}
|type=Cargo
|TL= 5
|mapsize=512x1024 Arctic
|version=r27534 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= FIRS Arctic Basic industries was loaded on a large, mountainous and very watery map. Having no fixed plan resulted in an extensive LR network, about of half of which got expanded to LL_RR later on in the game. Primary industries were set not to increase production, and we kept the number of primaries connected balanced, which resulted in very even traffic flows. In the end of the game, almost 1100 trains fully serviced all industries; no cargo waiting at stations.
|imagedescription= Yet another one of Mark's eyecandies.}}

{{Archive PublicServer
|id=312
|date=27.03.16 - 20.04.16
|players={{User|Jam35}}, {{User|Clockworker}}, {{User|Ramsvs}}, {{User|lol}}, {{User|Absolutis}}, {{User|damalix}}, {{User|Arveen}}, {{User|Maraxus}}, {{User|tyteen4a03}}, {{User|Mark}}, {{User|BiG_MEECH}}
|type=Cargo
|TL= 3
|mapsize=256x256 Temperate
|version=r27534 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= Cute little cargo game with some nice compact hubs.
|imagedescription= One of the nice BBHs featured in this game.}}

{{Archive PublicServer
|id=311
|date=02.03.16 - 27.03.16
|players= {{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|StarLite}}, {{User|lol}}, {{User|Clockworker}}, {{User|Ramsvs}}, {{User|Kalaidos}}, {{User|BiG_MEECH}}
|type=Pax
|TL=5 Wicked Warp
|mapsize=512x256 Temperate
|version=r27510 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This game produced some nice Sbahn networks in towns, most notable of which was the PURR/MEOW based SRNW by V453000. Train behaviour at his Doom York town is controlled by decisions based on current max speed when passing waypoints.
|imagedescription= An area of Doom York}}

PublicServer:Archive - Games 301 - 310

2015-11-22T23:33:22Z

Dwarf:

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=306
|date=03.11.15 - 21.11.15
|players= {{User|Jam35}}, {{User|lol}}, {{User|cha0tics}}, {{User|dwarf}}, {{User|Sylf}}
|type=PAX
|TL=7
|mapsize=512x512 Temperate
|version=r27428 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= An orderless SRNW PAX game where mainline trains were controlled 100% by logic gates. Shows some inventive logic constructions, game ended with 700 mainline trains and extensive SBahn systems.
|imagedescription= One of the BBH's that was upgraded to 3 lines, includes a logic controlled split and a new type of slowdown-avoiding merge.}}

{{Archive PublicServer
|id=305
|date=18.10.15 - 03.11.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|cha0tics}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Mark}}, {{User|lol}}
|type=YETI Cargo
|TL=3 Maglev 'Get Heavy'
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The plan was to use a single YETI yard to support the whole network. After some work and number-crunching, an optimal number of trains for each chain was found to keep the YETI town growing. Unfortunately we maxed out the number of YETIs that could be produced so the game ended prematurely. Still the network had grown to at least 3L 3R everywhere and ended with over 1500 trains.
|imagedescription= YETI yard area. }}

{{Archive PublicServer
|id=304
|date=01.10.15 - 18.10.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|Asgeir}}, {{User|Black}}, {{User|cha0tics}}, {{User|maraxus}}, {{User|Mazur}}, {{User|mari_kiri}}, {{User|Arveen}}, {{User|happy train sport}}, {{User|lol}}, {{User|glevans2}}, {{User|Purion}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic (NewGRF+ Industries)
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= This game featured a plan with 9 one-way rings, joined to next rings with hubs. A plan based on one-way rings allow us to build simpler hubs. Still, when the hubs are expanded from 2-line ML to 3-lines, and eventually to 4-lines, we see some impressive looking structures. We ended the game with nearly 2500 trains.
|imagedescription= BBH01, one of the hubs expanded to 4 lines in and out in all directions, surrounded by water. Very impressive expansion works. }}

{{Archive PublicServer
|id=303
|date=19.09.15 - 01.10.15
|players= {{User|Jam35}}, {{User|dwarf}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Sylf}}, {{User|StarLite}}, {{User|lol}}, {{User|Plonka}}, {{User|glevans2}}, {{User|Sedontane}}, {{User|YellowMiner}}, {{User|Asgeir}}
|type=FIRS 2 Cargo
|TL=5
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The first outing for the FIRS2 industry newGRF. The game used transfer of supplies to primary drop stations so that primary trains with 2 dedicated supply wagons could drop them on their return journey. The many industry chains, 24 cargoes, with several sources and destinations make this game a little more complicated than the usual cargo game.
|imagedescription= Network Map. }}

{{Archive PublicServer
|id=302
|date=03.09.15 - 19.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|lol}}, {{User|jrb0001}}, {{User|Purion}}, {{User|Plonka}}, {{User|Maraxus}}, {{User|dwarf}}, {{User|glevans2}}, {{User|Mark}}, {{User|YellowMiner}}, {{User|mfb}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This map features 2 one-way concentric loops connected by spokes and single town drop in the center. The inner loop was upgraded from 4 lines to 6 lines almost entirely. Relatively small upgrades, yet we fit over 1800 trains on the map.
|imagedescription= Center of the map, the town drop. }}

{{Archive PublicServer
|id=301
|date=19.08.15 - 03.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|Mazur}}, {{User|lol}}, {{User|__Fellini__}}, {{User|mfb}}, {{User|Maraxus}}, {{User|StarLite}}, {{User|YellowMiner}}, {{User|Mark}}
|type=Cargo
|TL=3
|mapsize=512x512 Arctic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=It's a relatively quick cargo game: a back-to-basic game. The game still ended with over 1450 trains. Another feature of this game was rich eyecandies.
|imagedescription= An example of eye-candy-rich area, the oil refinery. }}

File:PSG306.png

2015-11-22T23:30:17Z

Dwarf: Dwarf uploaded a new version of File:PSG306.png

PublicServer:Archive - Games 301 - 310

2015-11-22T23:22:30Z

Dwarf:

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=306
|date=03.11.15 - 21.11.15
|players= {{User|Jam35}}, {{User|lol}}, {{User|cha0tics}}, {{User|dwarf}}, {{User|Sylf}}
|type=PAX
|TL=7
|mapsize=512x512 Temperate
|version=r27428 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= An orderless SRNW PAX game where mainline trains were controlled 100% by logic gates. Shows some inventive logic constructions, game ended with 700 mainline trains and extensive SBahn systems.
|imagedescription= Example flip-flops }}

{{Archive PublicServer
|id=305
|date=18.10.15 - 03.11.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|cha0tics}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Mark}}, {{User|lol}}
|type=YETI Cargo
|TL=3 Maglev 'Get Heavy'
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The plan was to use a single YETI yard to support the whole network. After some work and number-crunching, an optimal number of trains for each chain was found to keep the YETI town growing. Unfortunately we maxed out the number of YETIs that could be produced so the game ended prematurely. Still the network had grown to at least 3L 3R everywhere and ended with over 1500 trains.
|imagedescription= YETI yard area. }}

{{Archive PublicServer
|id=304
|date=01.10.15 - 18.10.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|Asgeir}}, {{User|Black}}, {{User|cha0tics}}, {{User|maraxus}}, {{User|Mazur}}, {{User|mari_kiri}}, {{User|Arveen}}, {{User|happy train sport}}, {{User|lol}}, {{User|glevans2}}, {{User|Purion}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic (NewGRF+ Industries)
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= This game featured a plan with 9 one-way rings, joined to next rings with hubs. A plan based on one-way rings allow us to build simpler hubs. Still, when the hubs are expanded from 2-line ML to 3-lines, and eventually to 4-lines, we see some impressive looking structures. We ended the game with nearly 2500 trains.
|imagedescription= BBH01, one of the hubs expanded to 4 lines in and out in all directions, surrounded by water. Very impressive expansion works. }}

{{Archive PublicServer
|id=303
|date=19.09.15 - 01.10.15
|players= {{User|Jam35}}, {{User|dwarf}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Sylf}}, {{User|StarLite}}, {{User|lol}}, {{User|Plonka}}, {{User|glevans2}}, {{User|Sedontane}}, {{User|YellowMiner}}, {{User|Asgeir}}
|type=FIRS 2 Cargo
|TL=5
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The first outing for the FIRS2 industry newGRF. The game used transfer of supplies to primary drop stations so that primary trains with 2 dedicated supply wagons could drop them on their return journey. The many industry chains, 24 cargoes, with several sources and destinations make this game a little more complicated than the usual cargo game.
|imagedescription= Network Map. }}

{{Archive PublicServer
|id=302
|date=03.09.15 - 19.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|lol}}, {{User|jrb0001}}, {{User|Purion}}, {{User|Plonka}}, {{User|Maraxus}}, {{User|dwarf}}, {{User|glevans2}}, {{User|Mark}}, {{User|YellowMiner}}, {{User|mfb}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This map features 2 one-way concentric loops connected by spokes and single town drop in the center. The inner loop was upgraded from 4 lines to 6 lines almost entirely. Relatively small upgrades, yet we fit over 1800 trains on the map.
|imagedescription= Center of the map, the town drop. }}

{{Archive PublicServer
|id=301
|date=19.08.15 - 03.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|Mazur}}, {{User|lol}}, {{User|__Fellini__}}, {{User|mfb}}, {{User|Maraxus}}, {{User|StarLite}}, {{User|YellowMiner}}, {{User|Mark}}
|type=Cargo
|TL=3
|mapsize=512x512 Arctic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=It's a relatively quick cargo game: a back-to-basic game. The game still ended with over 1450 trains. Another feature of this game was rich eyecandies.
|imagedescription= An example of eye-candy-rich area, the oil refinery. }}

PublicServer:Archive - Games 301 - 310

2015-11-22T23:18:21Z

Dwarf: some edits on PSG 306 description

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=306
|date=03.11.15 - 21.11.15
|players= {{User|Jam35}}, {{User|lol}}, {{User|cha0tics}}, {{User|dwarf}}, {{User|Sylf}}
|type=PAX
|TL=7
|mapsize=512x512 Temperate
|version=r27428 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= An orderless SRNW PAX game where mainline trains were controlled 100% by logic gates. Shows some inventive logic constructions, game ended with 700 mainline trains.
|imagedescription= Example flip-flops }}

{{Archive PublicServer
|id=305
|date=18.10.15 - 03.11.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|cha0tics}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Mark}}, {{User|lol}}
|type=YETI Cargo
|TL=3 Maglev 'Get Heavy'
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The plan was to use a single YETI yard to support the whole network. After some work and number-crunching, an optimal number of trains for each chain was found to keep the YETI town growing. Unfortunately we maxed out the number of YETIs that could be produced so the game ended prematurely. Still the network had grown to at least 3L 3R everywhere and ended with over 1500 trains.
|imagedescription= YETI yard area. }}

{{Archive PublicServer
|id=304
|date=01.10.15 - 18.10.15
|players= {{User|Sylf}}, {{User|dwarf}}, {{User|Jam35}}, {{User|Asgeir}}, {{User|Black}}, {{User|cha0tics}}, {{User|maraxus}}, {{User|Mazur}}, {{User|mari_kiri}}, {{User|Arveen}}, {{User|happy train sport}}, {{User|lol}}, {{User|glevans2}}, {{User|Purion}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic (NewGRF+ Industries)
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= This game featured a plan with 9 one-way rings, joined to next rings with hubs. A plan based on one-way rings allow us to build simpler hubs. Still, when the hubs are expanded from 2-line ML to 3-lines, and eventually to 4-lines, we see some impressive looking structures. We ended the game with nearly 2500 trains.
|imagedescription= BBH01, one of the hubs expanded to 4 lines in and out in all directions, surrounded by water. Very impressive expansion works. }}

{{Archive PublicServer
|id=303
|date=19.09.15 - 01.10.15
|players= {{User|Jam35}}, {{User|dwarf}}, {{User|Maraxus}}, {{User|Mazur}}, {{User|Sylf}}, {{User|StarLite}}, {{User|lol}}, {{User|Plonka}}, {{User|glevans2}}, {{User|Sedontane}}, {{User|YellowMiner}}, {{User|Asgeir}}
|type=FIRS 2 Cargo
|TL=5
|mapsize=512x512 Temperate
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description= The first outing for the FIRS2 industry newGRF. The game used transfer of supplies to primary drop stations so that primary trains with 2 dedicated supply wagons could drop them on their return journey. The many industry chains, 24 cargoes, with several sources and destinations make this game a little more complicated than the usual cargo game.
|imagedescription= Network Map. }}

{{Archive PublicServer
|id=302
|date=03.09.15 - 19.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|lol}}, {{User|jrb0001}}, {{User|Purion}}, {{User|Plonka}}, {{User|Maraxus}}, {{User|dwarf}}, {{User|glevans2}}, {{User|Mark}}, {{User|YellowMiner}}, {{User|mfb}}
|type=Cargo
|TL=3
|mapsize=512x512 Tropic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This map features 2 one-way concentric loops connected by spokes and single town drop in the center. The inner loop was upgraded from 4 lines to 6 lines almost entirely. Relatively small upgrades, yet we fit over 1800 trains on the map.
|imagedescription= Center of the map, the town drop. }}

{{Archive PublicServer
|id=301
|date=19.08.15 - 03.09.15
|players= {{User|Sylf}}, {{User|Jam35}}, {{User|Mazur}}, {{User|lol}}, {{User|__Fellini__}}, {{User|mfb}}, {{User|Maraxus}}, {{User|StarLite}}, {{User|YellowMiner}}, {{User|Mark}}
|type=Cargo
|TL=3
|mapsize=512x512 Arctic
|version=r27387 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=It's a relatively quick cargo game: a back-to-basic game. The game still ended with over 1450 trains. Another feature of this game was rich eyecandies.
|imagedescription= An example of eye-candy-rich area, the oil refinery. }}

User:Dwarf

2013-02-23T00:43:40Z

Dwarf:

'''Born:''' 1986/09/16

'''From:''' Hungary

'''Location:''' California

'''Started playing TTD:''' Sometime around 1995, played single player for a couple of years, then returned to competitive online gaming in 2008.

'''Joined OpenTTDcoop:''' PSG 233 (2012/04/16)

'''Member since:''' 2013/04/22

'''Likes:''' Low terraforming, neat track layouts, logic

'''In the real world:''' Studies condensed matter physics

User:Dwarf

2013-02-23T00:42:11Z

Dwarf:

'''Born:''' 1986/09/16

'''From:''' Hungary

'''Location:''' California

'''Started playing TTD:''' Sometime around 1995, played single player for a couple of years, then returned to competitive online gaming in 2008.

'''Joined OpenTTDcoop:''' PSG 233

'''Member since:''' 2013/04/22

'''Likes:''' Low terraforming, neat track layouts, logic

'''In the real world:''' Studies condensed matter physics

User:Dwarf

2013-02-23T00:40:14Z

Dwarf: new user page

'''Born:''' 1986/09/16

'''From:''' Hungary

'''Location:''' California

'''Started playing TTD:''' Sometime around 1995, returned to competitive online gaming around 2008.

'''Joined OpenTTDcoop:''' PSG 233

'''Member since:''' 2013/04/22

'''Likes:''' Low terraforming, neat track layouts, logic

'''In the real world:''' Studies condensed matter physics

PublicServer:Archive - Games 231 - 240

2012-06-06T07:20:20Z

Dwarf:

{{PublicServerArchiveMenu}}

{{Archive_PublicServer|Public Server Game 236| 09.05.12 - 04.06.12 | {{User|V453000}}, {{User|Mark}}, {{User|mfb}}, {{User|Chris Booth}}, {{User|Vinne}}, {{User|dwarf}} | Cargo| TL8 | 256 x 1024 Temperate | r24217 [[GRF|#openttdcoop-GRF-Pack 8.0]] | This plan involved only 1 ML, which started out as LLLL_RRRR, we only had 3 planed stations on the ML, a Northern Drop, a Southern Drop and a Central Town Drop. This idea behind this layout was to balance the ML between the north and the south. To do this trains from Primary Industries in the North headed to the South, or from the South to the North. No Iron Ore was transported on the Main Lines, this was made locally at steel mills on the Sidelines. As with any Temperate game that has Oil Rigs, this game became rather Oil heavy, and by the end of the game 1/5th of the 1000 trains in total, where dedicated to Oil duties. |236|File:psg236.png|This is the busy Norther Drop station, tunnels for the entrance to the pick up pass under this}}

{{Archive_PublicServer|Public Server Game 235| 02.05.12-09.05.12 | {{User|V453000}}, {{User|Mark}}, {{User|mfb}}, {{User|Hazzard}}, {{User|Chris Booth}}, {{User|LoPo}}, {{User|Maraxus}}, {{User|dwarf}}, {{User|Cermix}}, {{User|Firestar}}, {{User|soloswitch}}, {{User|thgergo}}, {{User|Tray}}, {{User|Steven}} | Passengers | TL3 | 512 x 512 Temperate | r24119 [[GRF|#openttdcoop-GRF-Pack 8.0]] |
A passenger plan that involved making a huge central transfer station and 4 independent networks of varying rail types. 1900 trains run in these networks.|235|File:psg235.png|The central transfer stations}}

{{Archive_PublicServer|Public Server Game 234| 22.04.12-02.05.12 | {{User|V453000}}, {{User|mfb}}, {{User|Mark}}, {{User|XeryusTC}}, {{User|Mazur}}, {{User|dwarf}}, {{User|LoPo}}, {{User|Hazzard}}, {{User|Absolutis}}, {{User|Tray}}, {{User|Maraxus}}, {{User|Cermix}}, {{User|Steven}} | Cargo | TL3 | 512 x 512 TOYLAND | r24119 [[GRF|#openttdcoop-GRF-Pack 8.0]] |
It has been quite a while since we played toyland climate. Unlike before, now we played it with NUTS so we could use some nice trains and in this case also refittable wagons. Toyland industry chains are particularly special as all of the cargoes do produce a secondary cargo, therefore being ideal for a refit game. And a refit game we did. There were many town drops used on each sideline, some sidelines even had primary stations joined with a town drop in one station. This meant that trains always picked up the secondary cargo after refit, and just returned to the sideline no matter what. Therefore we could have omitted the conditional orders. This meant our network was very stable without wave traffic so we did not need any kind of overflows. As every train had a high chance of making a profit, we checked our network fluency by looking at the profitability of our trains - we ended the game having 1000 performance rating which means that every single of our 1729 trains managed to turn profit in the last year. |234|File:psg234.png|SLH04 services about 11,000 units of production spread over 6 drop-refit-load stations.}}

{{Archive_PublicServer|Public Server Game 233| 16.04.12-22.04.12 | {{User|V453000}}, {{User|mfb}}, {{User|dwarf}}, {{User|XeryusTC}}, {{User|Mazur}}, {{User|Meech}}, {{User|Hazzard}}, {{User|LoPo}}, {{User|Mark}}, {{User|Absolutis}}, {{User|Tray}}, {{User|Maraxus}}, {{User|Steven}} | Cargo | TL4 | 512 x 512 Temperate | r24119 [[GRF|#openttdcoop-GRF-Pack 8.0]] |
In this game we chose a plan consisting of four circular rings connected with hubs. The network started with 2 lines in each ring and after expanding it as needed we ended with up to 5 lines in some of the rings. 1500 trains were running at the end.|233|File:psg233.png|The map of this game.}}

{{Archive_PublicServer|Public Server Game 232| 09.04.12-15.04.12 | {{User|V453000}}, {{User|mfb}}, {{User|Chris Booth}}, {{User|XeryusTC}}, {{User|Mazur}}, {{User|Bassals}}, {{User|Hazzard}}, {{User|Ryton}}, {{User|Mark}}, {{User|Absolutis}}, {{User|Tray}}, {{User|Maraxus}}, {{User|Steven}} | Cargo | TL2 | 512 x 512 Temperate | r23974 [[GRF|#openttdcoop-GRF-Pack 8.0]] |
In this game, an improved version of the NUTS train set was put to a test again. The network plan featured a maze of single mainlines, connected trough a whopping count of 35 BBH's and 10 distributed MSH's. This caused the map to be covered with a spaghetti of small main lines. During the game the most busy lines, hubs and stations were upgraded, leading to a well flowing network with 1600 2 tile long 'Get Heavy' maglev trains, with a LLL-RRR mainline in the busiest area.|232|File:psg232.png|The map showing the spaghetti of mainlines.}}

{{Archive_PublicServer|Public Server Game 231| 31.03.12-08.04.12 | {{User|V453000}}, {{User|mfb}}, {{User|Chris Booth}}, {{User|XeryusTC}}, {{User|Mazur}}, {{User|Sylf}}, {{User|Hazzard}}, {{User|Ryton}}, {{User|Thorimbur}}, {{User|Steven}}, {{User|Mark}}, {{User|KyleS}}, {{User|Kanddak}}, {{User|Big_Meech}}, {{User|Absolutis}} | Cargo | TL3 | 512 x 512 Temperate | r23974 [[GRF|#openttdcoop-GRF-Pack 8.0]] | This map marks the introduction of V453000's trainset NUTS (0.0.1), so to test the entire set, and as an April 1st surprise, we played a chaos game with many small networks at first, amalgating them into three larger networks as the game progressed; one regular rail (East), one monorail (West), and one maglev (Center), to test as many of the individual trains as possible and allowing any oddities and mistakes in the set to be corrected.|231|File:psg231.png|A section of the map where all three networks approached each other. }}

Community:Members

2012-04-18T06:13:51Z

Dwarf: /* The usual suspects around the Public Server [39] */

__NOTOC__
==Active Members of #openttdcoop [20]==
*{{User|Ammler|ch}}, the one who dances with the newgrfs '''*'''
*{{User|Hylje|fi}}, the silent guy always and never around.
*{{User|KenjiE20|uk}}, the master of puppets, pulling your strings '''*'''
*{{User|Mark|nl}}
*{{User|Mazur|nl}}, the senile one, who know nothing, no-thing! '''*'''
*{{User|mfb|de}}, always wants to try something new
*{{User|Mucht|at}}, the oldie who controlls our community from background.'''*'''
*{{User|ODM|nl}}, the innocent ''black'' lamb of #openttdcoop '''*'''
*{{User|Osai|de}}, doctor of the web and autopilot, who can hit back, if needed '''*'''
*{{User|Phazorx|iru}}, what does a communist in the tycoon world?
*{{User|planetmaker|de}}, Make(file), newgrfs and patches '''*'''
*{{User|SmatZ|cz}}, pest-controller on all levels of OpenTTD(coop) '''*'''
*{{User|^Spike^|nl}}, the last Dutchy
*{{User|StarLite|nl}} master of the magic roundabout that everybody fears ;-)
*{{User|Sylf|us}}, the oblivious, always getting into troubles
*{{User|thgergo|hu}}, the one who builds bridges
*{{User|Thraxian|us}}, makes some little members
*{{User|tneo|nl}}, the spelling angel '''*'''
*{{User|V453000|cz}}, the network construction consultant
*{{User|valhallasw|nl}}, BOFH, Wiki-god and mainly werkloos '''*'''
*{{User|XeryusTC|nl}}, Rebellous doing-stuff-differently-from-convention type of guy '''*'''
''Note: '''*''' Admins have shell access to our servers, all others have rcon access''

==Honorary Members of #openttdcoop [3]==
*{{User|Brianetta|uk}} (our amiable host who is responsible for making #openttdcoop to such a vital community it is today) '''*'''
*{{User|Phoenix the II|nl}} (our host for the most busy [http://www.openttdcoop.org/blog/public-server/ PublicServer], thanks to him, we don't need to finish a game, because of the server limits.)
*{{User|TrueLight|nl}} (for being a bugfixer over ... a long time ;-) )

==Currently Inactive Members of #openttdcoop [12]==
*{{User|Adm.Spock|nl}} still too busy with other things in life, but "I'll be back"!
*{{User|Combuster|nl}} joins and parts the whole day '''*'''
*{{User|dihedral|de}}
*{{User|dp|de}}
*{{User|e1ko|cz}}
*{{User|Guru3|se}}
*{{User|Kommer|nl}}, we lost his exclusive love to openttd
*{{User|ottd-king|uk}}
*{{User|Piratejerk|ca}}
*{{User|Progman|de}}, builds bigger networks on his Pentium2 at home, than 20 members on publicserver. '''*'''
*{{User|uliko|se}}, omnipresent
*{{User|xahodo|nl}}

==The usual suspects around the Public Server [39]==

{|
|-
| valign="top" |
*{{User|Avdg|be}}
*{{User|Barbaar|nl}}
*{{User|Benny|no}}
*{{User|CharcoalDioxide|fi}} (known also as Absolutis)
*{{User|Chris booth|uk}}
*{{User|Damalix|fr}}
*{{User|DCritic|us}}
*{{User|DJNekkid|no}}
*{{User|draconnier|lu}}
*{{User|dwarf|hu}}
*{{User|einKarl|de}}
*{{User|F223|us}}
*{{User|Farden|fr}}
*{{User|Floffe|se}}
*{{User|fmauNeko|fr}}
*{{User|Fuco|sk}}

|                  
|valign="top" |
*{{User|Gleeb|uk}}
*{{User|HanziQ|cz}}
*{{User|James|uk}}
*{{User|jondisti|fi}}
*{{User|Intexon|cz}}
*{{User|Kolo|pl}}
*{{User|LittleMikey|au}}
*{{User|LordAzamath|ee}}
*{{User|LoPo|nl}}
*{{User|Macha|ie}}
*{{User|MrD2DG|uk}}
*{{User|mrruben5|nl}}
*{{User|narc|ro}}
*{{User|Nickman|be}}

|                  
|valign="top" |

*{{User|OwenS|uk}}
*{{User|Petert|us}}
*{{User|pugi|de}}
*{{User|Sedontane|uk}}
*{{User|Thijs|nl}}
*{{User|thomashauk|uk}}
*{{User|Twerkhoven|uk}}
*{{User|Vitus|cz}}
*{{User|Wouterr|be}}
*{{User|Yso|ch}}
*{{User|ZarenorDarkstalker|us}}
*{{User|Zerpa|dk}}
*{{User|Zuu|se}}

|}
''And of course all the others above!''

== Exsuspects & retired members [84] ==
If you are on the ex-suspects list and you start playing again, please move yourself up to the suspects list !
If you are still active and on the ex-suspects list, sorry for the moving :) we sometimes cannot find an IRC log of you while you are still active

{|
|-
| valign="top" |
*{{User|A3aan|nl}}
*{{User|Addi|ch}}
*{{User|Alanin|de}}
*{{User|Alendo|no}}
*{{User|AlexanderB|nl}}
*{{User|Andyp|us}}
*{{User|AntB|uk}}
*{{User|Bob27|us}}
*{{User|ChrisM|de}}
*{{User|Cipri|nl}}
*{{User|Clifs|us}}
*{{User|csuke|uk}}
*{{User|Dark_Link|se}}
*{{User|Davil|at}}
*{{User|Doke|de}}
*{{User|Dopefish|de}}
*{{User|eJoJ|no}}
*{{User|Elske|nl}}
*{{User|EmiT|cz}}
*{{User|Franco|hu}}
*{{User|Gamer|nl}}
*{{User|Giles|uk}}
*{{User|Godde|no}}
*{{User|Green-devil|dk}}
*{{User|Hans|nl}}
*{{User|hdp|us}}
*{{User|h3rzb1ut|de}}
*{{User|hzzzln|de}}
*{{User|Ichi|nl}}

|                  
|valign="top" |
*{{User|Ihmemies|fi}}
*{{User|itsnotvalid|hk}}
*{{User|Jinx|be}}
*{{User|John|sk}}
*{{User|Juustro|fi}}
*{{User|Kejhic|cz}}
*{{User|Kirov|ar}}
*{{User|Kolbur|de}}
*{{User|Kul|nl}}
*{{User|Levi|de}}
*{{User|Logix|us}}
*{{User|MDGrein|se}}
*{{User|mensi|ch}}
*{{User|Microshit|nl}}
*{{User|mitooo|fr}}
*{{User|mixrin|ru}}
*{{User|MooUK|uk}}
*{{User|N101|au}}
*{{User|Nazirro|pl}}
*{{User|Nitehawk|us}}
*{{User|Pikita|uk}}
*{{User|Phil|uk}}
*{{User|RaWt|no}}
*{{User|Red|us}}
*{{User|RichK|uk}}
*{{User|RMJ|dk}}
*{{User|Rob|us}}
*{{User|Satyap|in}}
*{{User|sbn|be}}

|                  
|valign="top" |
*{{User|SerriaRomeo|us}}
*{{User|Shader|pl}}
*{{User|Sian|dk}}
*{{User|Skasi|at}}
*{{User|Skidd13|de}}
*{{User|S m w|de}}
*{{User|Spectre100|us}}
*{{User|Stoffe|se}}
*{{User|strstrep|us}}
*{{User|Talonius|uk}}
*{{User|Tautrimas|lt}}
*{{User|Teddy|no}}
*{{User|Tim|de}}
*{{User|Torben Paw|dk}}
*{{User|Tussengas|nl}}
*{{User|UnderBuilder|ar}}
*{{User|Vinni3|uk}}
*{{User|Volny|cz}}
*{{User|Walle|be}}
*{{User|welterde|de}}
*{{User|Zakjan|cz}}
*{{User|Zavior|fi}}

|}