#openttdcoop wiki - User contributions [en]

User:Bennythen00b

2020-03-07T17:02:19Z

Benny: Blanked the page

User:Benny

2020-03-07T16:59:04Z

Benny:

'''Location:''' Norway. {{Flag|no}}

'''Started playing OpenTTD:''' January 2007

'''Joined OpenTTDCoop:''' 10.10.08, First game I actually played in was Public Server Game 116.

'''Prefers:''' Traditional games, low TL, utilizing space well.

'''Specialist on:''' Nothing, I suck at this game.

'''Weakness:''' Main stations, 4-way hubs.

'''Dislikes:''' Shift mainlines, newGRFs with annoying sprites, Toyland.

PublicServer:Archive - Games 271 - 280

2014-06-16T06:47:38Z

Benny: added myself

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=279
|date=1.5.2014-13.6.2014
|players={{User|V453000}}, {{User|Jam35}}, {{User|Sylf}}, {{User|Maraxus}}, {{User|MrD2DG}}, {{User|AlphaSC}}, {{User|Godde}}, {{User|Hazzard}}, {{User|Grimalkin}}
|type=Cargo Refit
|TL=TL3
|mapsize=512 x 512 Temperate
|version=r26601[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Refit mayhem game with goods taken back to drops at sidelines. Started LL_RR and with some 3rd line expansions in various places we ended up with 1572 trains.
|imagedescription=Screenshot not yet here}}

{{Archive PublicServer
|id=278
|date=14.4.2014-1.5.2014
|players={{User|Mark}}, {{User|Jam35}}, {{User|AlphaSC}}, {{User|Firestar}}
|type=Cargo
|TL=TL3
|mapsize=512 x 512 Sub-Arctic
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A simple gameplan with one drop featuring 464 trains was quickly built. Due to little interest this game was not finished.
|imagedescription=Screenshot not yet here}}

{{Archive PublicServer
|id=277
|date=31.3.2014-14.4.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|AlphaSC}}, {{User|Vinnie}}, {{User|Maraxus}}, {{User|Big Meech}}, {{User|Happy Transport}}, {{User|Hijmani}}, {{User|Firestar}}, {{User|Mark}}
|type=Cargo/Chaos
|TL=TL3/Mixed
|mapsize=512 x 512 Temperate
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Game for the celebration of NUTS' 2nd birthday. Chaos game which ended up as a structured network with some random side-networks.
|imagedescription=One of many BBH's in the game. Note the "invisble loco" trains}}

{{Archive PublicServer
|id=276
|date=12.3.2014-31.3.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|Maraxus}}, {{User|Big Meech}}, {{User|Happy Transport}}, {{User|Hijmani}}, {{User|Firestar}}
|type=Cargo
|TL=TL4
|mapsize=512 x 256 Temperate
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=To be written. 973 trains.
|imagedescription=All the colours of the rainbow}}

{{Archive PublicServer
|id=275
|date=21.2.2014-12.3.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|Absolutis}}, {{User|theholyduck}}, {{User|Tray}}, {{User|Benny}}
|type=PAX
|TL=TL5
|mapsize=512 x 256 Temperate
|version=r26315[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A very nice game which split the SRNW network in 2 halves where we attempted to grow both of them to about equal size.
|imagedescription=Slug York, the biggest city on the map}}

{{Archive PublicServer
|id=274
|date=31.1.2014-21.2.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Edi__}}, {{User|Elyon}}, {{User|nicfer}}, {{User|theholyduck}}, {{User|Hazzard}}, {{User|Absolutis}}, {{User|Tray}}, {{User|gerpara}}, {{User|mfb}}
|type=Cargo
|TL=TL 2-8
|mapsize=512 x 512 Toyland
|version=r26315[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This was another Toyland game that failed.
|imagedescription=Love is in the tracks!}}

{{Archive PublicServer
|id=273
|date=19.1.2014-31.1.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|ryx}}, {{User|Hazzard}}, {{User|Jam35}}, {{User|Djanxy}}, {{User|Palen}}, {{User|Zxbiohazardzx}}, {{User|tyteen4a03}}, {{User|theholyduck}}, {{User|edi__}}, {{User|mek42}}, {{User|mfb}}, {{User|NCommander}}, {{User|Niradiel}}, {{User|sim-al2}}, {{User|Tray}}, {{User|Volatar}}, {{User|nicfer}}
|type=Cargo Refit
|TL=TL 5
|mapsize=512 x 512 Temperate
|version=r26264[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This is not your typical wet dream. We decided to play a refit game using the wetrail trains. It was a quick game, but we still managed to pack just under 1100 trains on the map. It is a watery map, and features several major constructs that are built directly on the water, using the canal cheats.
|imagedescription=Main stations and hubs are built around the water, like this side line hub.}}

{{Archive PublicServer
|id=272
|date=2.1.2014-19.1.2014
|players={{User|V453000}}, {{User|Tray}}, {{User|mfb}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|nicfer}}, {{User|ben1066}}, {{User|Benny}}, {{User|ryx}}, {{User|tyteen4a03}}, {{User|vladiano}}, {{User|Firestar}}, {{User|Mark}}, {{User|Sylf}}, {{User|Zxbiohazardzx}}
|type=Cargo
|TL=TL 4
|mapsize=512 x 256 Temperate
|version=r26193[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This game had TL4 (moderate length) fast maglev (not a great accel). ML on this map was a single loop around the map. In the end, the ML had 6 lines all around, serving about 770 trains.
|imagedescription=This game was loaded with some WTF-ness}}

{{Archive PublicServer
|id=271
|date=21.11.2013-2.1.2014
|players={{User|mfb}}, {{User|Vinnie}}, {{User|Maraxus}}, {{User|Jam35}}, {{User|Benny}}, {{User|Damalix}}, {{User|Djanxy}}, {{User|Hazzard}}, {{User|Zxbiohazardzx}}
|type=Cargo
|TL=TL 4
|mapsize=512 x 512 Arctic
|version=r25863 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=We newly used the monorail MEOW class from NUTS and tried to utilize the colourful rails on a rather classic network. The game ended with 1150 trains.
|imagedescription= BBH Wood with all the colours}}

PublicServer:Archive - Games 271 - 280

2014-06-16T06:47:00Z

Benny: Changed description

{{PublicServerArchiveMenu}}

{{Archive PublicServer
|id=279
|date=1.5.2014-13.6.2014
|players={{User|V453000}}, {{User|Jam35}}, {{User|Sylf}}, {{User|Maraxus}}, {{User|MrD2DG}}, {{User|AlphaSC}}, {{User|Godde}}, {{User|Hazzard}}, {{User|Grimalkin}}
|type=Cargo Refit
|TL=TL3
|mapsize=512 x 512 Temperate
|version=r26601[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Refit mayhem game with goods taken back to drops at sidelines. Started LL_RR and with some 3rd line expansions in various places we ended up with 1572 trains.
|imagedescription=Screenshot not yet here}}

{{Archive PublicServer
|id=278
|date=14.4.2014-1.5.2014
|players={{User|Mark}}, {{User|Jam35}}, {{User|AlphaSC}}, {{User|Firestar}}
|type=Cargo
|TL=TL3
|mapsize=512 x 512 Sub-Arctic
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A simple gameplan with one drop featuring 464 trains was quickly built. Due to little interest this game was not finished.
|imagedescription=Screenshot not yet here}}

{{Archive PublicServer
|id=277
|date=31.3.2014-14.4.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|AlphaSC}}, {{User|Vinnie}}, {{User|Maraxus}}, {{User|Big Meech}}, {{User|Happy Transport}}, {{User|Hijmani}}, {{User|Firestar}}, {{User|Mark}}
|type=Cargo/Chaos
|TL=TL3/Mixed
|mapsize=512 x 512 Temperate
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=Game for the celebration of NUTS' 2nd birthday. Chaos game which ended up as a structured network with some random side-networks.
|imagedescription=One of many BBH's in the game. Note the "invisble loco" trains}}

{{Archive PublicServer
|id=276
|date=12.3.2014-31.3.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|Maraxus}}, {{User|Big Meech}}, {{User|Happy Transport}}, {{User|Hijmani}}, {{User|Firestar}}
|type=Cargo
|TL=TL4
|mapsize=512 x 256 Temperate
|version=r26436[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=To be written. 973 trains.
|imagedescription=All the colours of the rainbow}}

{{Archive PublicServer
|id=275
|date=21.2.2014-12.3.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|Absolutis}}, {{User|theholyduck}}, {{User|Tray}}
|type=PAX
|TL=TL5
|mapsize=512 x 256 Temperate
|version=r26315[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=A very nice game which split the SRNW network in 2 halves where we attempted to grow both of them to about equal size.
|imagedescription=Slug York, the biggest city on the map}}

{{Archive PublicServer
|id=274
|date=31.1.2014-21.2.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|Edi__}}, {{User|Elyon}}, {{User|nicfer}}, {{User|theholyduck}}, {{User|Hazzard}}, {{User|Absolutis}}, {{User|Tray}}, {{User|gerpara}}, {{User|mfb}}
|type=Cargo
|TL=TL 2-8
|mapsize=512 x 512 Toyland
|version=r26315[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This was another Toyland game that failed.
|imagedescription=Love is in the tracks!}}

{{Archive PublicServer
|id=273
|date=19.1.2014-31.1.2014
|players={{User|V453000}}, {{User|Sylf}}, {{User|ryx}}, {{User|Hazzard}}, {{User|Jam35}}, {{User|Djanxy}}, {{User|Palen}}, {{User|Zxbiohazardzx}}, {{User|tyteen4a03}}, {{User|theholyduck}}, {{User|edi__}}, {{User|mek42}}, {{User|mfb}}, {{User|NCommander}}, {{User|Niradiel}}, {{User|sim-al2}}, {{User|Tray}}, {{User|Volatar}}, {{User|nicfer}}
|type=Cargo Refit
|TL=TL 5
|mapsize=512 x 512 Temperate
|version=r26264[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This is not your typical wet dream. We decided to play a refit game using the wetrail trains. It was a quick game, but we still managed to pack just under 1100 trains on the map. It is a watery map, and features several major constructs that are built directly on the water, using the canal cheats.
|imagedescription=Main stations and hubs are built around the water, like this side line hub.}}

{{Archive PublicServer
|id=272
|date=2.1.2014-19.1.2014
|players={{User|V453000}}, {{User|Tray}}, {{User|mfb}}, {{User|Jam35}}, {{User|Hazzard}}, {{User|nicfer}}, {{User|ben1066}}, {{User|Benny}}, {{User|ryx}}, {{User|tyteen4a03}}, {{User|vladiano}}, {{User|Firestar}}, {{User|Mark}}, {{User|Sylf}}, {{User|Zxbiohazardzx}}
|type=Cargo
|TL=TL 4
|mapsize=512 x 256 Temperate
|version=r26193[[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=This game had TL4 (moderate length) fast maglev (not a great accel). ML on this map was a single loop around the map. In the end, the ML had 6 lines all around, serving about 770 trains.
|imagedescription=This game was loaded with some WTF-ness}}

{{Archive PublicServer
|id=271
|date=21.11.2013-2.1.2014
|players={{User|mfb}}, {{User|Vinnie}}, {{User|Maraxus}}, {{User|Jam35}}, {{User|Benny}}, {{User|Damalix}}, {{User|Djanxy}}, {{User|Hazzard}}, {{User|Zxbiohazardzx}}
|type=Cargo
|TL=TL 4
|mapsize=512 x 512 Arctic
|version=r25863 [[GRF|#openttdcoop-GRF-Pack 8.0]]
|description=We newly used the monorail MEOW class from NUTS and tried to utilize the colourful rails on a rather classic network. The game ended with 1150 trains.
|imagedescription= BBH Wood with all the colours}}

File:PSG275.png

2014-06-16T06:46:10Z

Benny: Slug York, the biggest town on the map.

Slug York, the biggest town on the map.

PBS

2013-12-19T08:18:26Z

Benny: Omitted the silly "no signals after junction", upsized images, changed some sentences, added link to openttd wiki.

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

==Description==

PBS stands for Path Based Signaling, which is a signal type that allows multiple trains to enter one signal block. Although primarily intended in OpenTTD (and in the real world) to provide bi-directional track, without the deadlocks that will occur with regular signaling. Besides that it can also be used to increase performance in certain situations.

==How it works==
For an explanation on the basics of YAPP and some examples, please check [http://wiki.openttd.org/Yet_Another_PBS_Patch the YAPP page] on the OpenTTD site.

In short: PBS introduces a new type of signal, which comes in two flavors. The first type is a regular (or: two-way) PBS signal, the second a one-way PBS signal. When a train encounters a PBS signal it will attempt to reserve a path. This means that it will look ahead at the path it wants to go and determines whether there are any obstacles in the way, such as another train. It will only look as far as the next signal it encounters (any signal, no specific type). When a reservation can be made, the train will go past the signal along the reserved path, otherwise it'll wait until it can do so.

The advantage of PBS is that it allows multiple trains to enter a PBS guarded area, as long as their reserved paths do not cross each other. While a regular signal would stop the second train until the entire section of track is clear, using PBS signaling trains can overcome this limitation. An example can be shown below. Here, both trains will attempt to enter the crossing, both trains go straight ahead on their path. When the first train encounters PBS signal A, it will reserve a path up to signal C. Since there are no obstacles, the reservation is allowed and the train passes. Moments later, the second train encounters signal B and attempts to reserve a path to signal D. Since train 1 is not in the way, the reservation will be made as well and train 2 will continue as well. At that time, both trains are in the same PBS signaled section. If regular signals would be used in this case, one train would always have to wait.

[[Image:pbs_demo1_2trains.png]] [[Image:pbs_demo2_2trains.png]]

As said, there are two types of the PBS signal (regular and one-way). The regular signal is basically two way, but passing the signal from the back comes with a penalty in the pathfinder which will thus attempt to avoid it. This signal can be useful for situations where you want to allow trains to pass the signal from the back, but only when there's no other way. Applications include two way stations and two-way track, all of which can be found in the OpenTTD wiki. The one-way signal does not allow trains from the back is is used in situations where it's combined with regular one-way track, such as the examples below. It could be said that one should avoid regular PBS in one-way track, because trains that reverse might collide with the train behind them.

==Examples from #OpenTTDCoop games==

===Terminus station===
This is a normal [http://wiki.openttd.org/Railway_station#Terminus terminus station], except that PBS is used to allow more than one train to be in the signaling block in front of the station. The entry has a one-way PBS signal, each station track has a normal PBS signal facing the station. The exit has a regular one-way exit signal. The advantage of the station shown in the screenshot is that it allows a train to leave the station while another train enter it. This could improve throughput, depending on how large your station is. Please note that the exit signal has a gap, to avoid that a train waiting in front of that signal will block the track.

Below is and example of PBS signaling used at a terminus station. As you can see, one train leaves the station taking the left most track to the exit. At the same time a train is entering the station on the middle track. The is actually only 1 PBS signal, directly in front of the station one could place more PBS signals but these are not really needed. Also, in the example below there's a single tile track section in front of the station. Although not really needed, it provides trains with some breaking space so the train will spend less time on the switches. This may sometimes clear a path for the next train sooner, increasing performance.

[[Image:Pbs_terminus.jpg]]

===PBS bridges===
The bridges shown here have only one signal placed in front of them, with regular signals after them. As you can see from the screenshot, there is very little track in front of the bridge, because there are no signals needed in front of the bridge.

[[Image:Pbs_bridge.jpg]]

===PBS depot===
This depot setup slightly improves the amount of trains that can be serviced. It basically allows for two trains to be on the same tile, for example to have one train exit the depot while the other enters it.

[[Image:Pbs_depot.jpg|PBS depot. Notice that one train enters the depot while the other leaves, sharing the same tile.]]

===Hints for using PBS===
* Enable 'Show reserved tracks' in the OpenTTD patches to show ingame which tracks are being taken by trains entering sections. In the screenshots above you can see this, the track is a little darker.
* Build one-way PBS signals if possible. #OpenTTDCoop games will rarely need the use of two-way PBS.

=== See also ===

* [[Signals]]
* [[Presignals]]

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

User:GLOKatherin

2013-12-19T08:07:01Z

Benny: spam

{{delete|spam}}

42 yrs old Corporate General Manager Oren Lisenby from Duvernay, loves to spend time golf, sale pages and cosplay. Have been recently planing a trip to Itsukushima Shinto Shrine.

User:EmoryCabral

2013-12-19T08:06:47Z

Benny: spam

{{delete|spam}}

Civil Executive Draftsperson Keith Grigg from Saint-Janvier, likes to spend time origami, sale pages and crossword puzzles.

Gets inspiration by making a journey to Kluane / Wrangell-St. Elias / Glacier Bay / Tatshenshini-Alsek.

User:EstelaWinder

2013-12-19T08:06:40Z

Benny: spam

{{delete|spam}}

33 year old Naval Architect Byron Cuesta from Nelson House, has interests such as shark fishing, sale pages and operating in a food pantry. Wants to travel and was inspired after taking a trip to Western Ghats.

Main Page/editcopy

2013-12-17T10:07:34Z

Benny: Changed signals and two-way eol links

__NOTOC__
{| style="width: 100%;" cellspacing="5" cellpadding="0"
| colspan="3" | <div style="width: 75%; margin: auto; background:#f5faff; border: 1px solid #AAA;"><div style="background:#f5faff; border: 1px solid #7BC; padding: 5px; margin: 3px; font-weight: bold; text-align: center;">
Welcome to the #openttdcoop wiki,<br>the definitive source for cooperative building and design of transportation networks.</div></div>



|-
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Getting Started</div>
<div style="padding-left: 1em;">
; [[Quickstart]]
; [[Obtaining OpenTTD]]
: [http://nightly.openttd.org Nightly Builds]
: [[GRF|#openttdcoop GRF Pack]]
; [[Tutorial Savegame|#openttdcoop Tutorial]]
: [http://www.openttdcoop.org/wiki/images/6/6a/Tutorial.sav Download Savegame]
: [[Tutorial Savegame Mainline|Mainline]] • [[Tutorial Savegame Sideline|Sideline]]
: [[Tutorial Savegame Stations|Stations]] • [[Tutorial Savegame Feeder|Feeder]] • [[Tutorial Savegame Towns|Towns]]
; [[Cooperation]]
; [[Ruleset|Building Guidelines]]
; [[Communication]]
; [[Glossary]]
</div>
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Basic Building Concepts</div>
<div style="padding-left: 1em;">
; [[Game Start]]
: [[Planning]] • [[Moneymaker]]
; [[Line hierarchy|Basic Networking]]
: [[Mainline]] • [[Sideline]] • [[Signalling]]
: [[SLH]] • [[Priority]]
: [[Road stations]]
; [[Signals|Signals]] • [[Max_Curve_Speed|Curves (CL)]]
; [[Terraforming]]
; [[Orders]]
: [[Copy orders|Copying Orders]] • [[Shared Orders]]
; [[Game_types|Game types]]
: [[Cargo]] • [[PAX]] • [[Chaos]] • [[Refit]] • [[SRNW]] • [[SML]]

</div>
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Advanced Building Concepts</div>
<div style="padding-left: 1em;">
; [[Junctionary]]
: [[Junctionary - BBHs|BBH]] • [[Junctionary - SLHs|SLH]] • [[Junctionary - Stations|Stations]] • [[Junctionary_-_Mergers|Mergers]] • [[Junctionary_-_City_Networks|City Networks]] • [[Junctionary_-_Logic_and_Other|Logic and Other]]
; [[:Category:Advanced Networking|Advanced Networking]]
: [[BBH]] • [[Main station|Main stations]] • [[MSH]] • [[Merging_Tracks|Merging Tracks]]
; [[Shift_Mainlines|SML (Shift Mainlines)]]
; [[Self-regulating Network]]s
; [[Sbahn|S-Bahns]]
; [[Two-way end of line|Two-way end of line]]
; [[Logic|Logic]]
;

[[Advanced_Building_Revue|Advanced Building Revue (ABR)]]

</div>
|-
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Technical Info</div>
<div style="padding-left: 1em;">
; [[Servers|#openttdcoop Servers]]
: [[Public Server | (PS) Public Server]] ([[PublicServer:Archive|Archive]])
: [[Pro Zone | (PZ) ProZone Server]] ([[ProZone:Archive|Archive]])
: [[Member Zone| (MZ) Member Server]] ([[MemberZone:Archive|Archive]])
: [[Coopetition|Coopetition Server]] • [[Dev Server|Patched Server]]
; [[IRC]]
: [[IRC Commands]] • [[IRC Highlighting]]
; [[Teamspeak]]
; [[GRF|#openttdcoop GRF Pack]]
: [[GRF Table Current|Current GRF Table]] • [[GRF History|Version History]]
: [[GRF Dev Guide|Development Guide]] • [[GRF Table (Trunk)|Development Table]]
; [[Server Administration]] • [[Autopilot]] • [[Autostart]]
; [[Soap]]
</div>
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Development</div>
<div style="padding-left: 1em;">
; [[Gametypes]]
: [[Gametype:ICE SBahn|ICE/SBahn]] • [[Gametype:Chaos Theory|Chaos]] • [[Gametypes|more...]]
: [[Game Proposals|Proposals for Future Gametypes]]
; [[Map Preparation| Preparing good maps]] | [[Premade Scenarios| Proposed and prepared future games]]
; [[:Category:Coopetition|Coopetition]]
; [[OSQC|Scenario Quest/Competition (OSQC)]]
; [[WWOTTDGD|WorldWide OpenTTD Game Day (WWOTTDGD)]]
; [[Webbased configurator | Web-based Configurator]]
; [[:Category:Research|Current Research Projects]]
</div>
| class="frontpage_box" |
<div class="frontpage_bar"><div style="float: right;">[[Image|*]]</div>Community Info</div>
<div style="padding-left: 1em;">
We are maintaining [[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]]!<br />
<span style="margin-left: 2em;"><small>See...[[Special:Recentchanges|Recent changes]] | [[Special:Newpages|New pages]] | [[Special:Wantedpages|Missing pages]]</small></span>
; [http://www.openttdcoop.org/blog #openttdcoop Blog]
; [[Membership|Becoming an #openttdcoop Member]]
: Join the cooperative building community!
; [[Users|User List]]
: See the list of current members and active players
; [[History|History of #openttdcoop]]
; [[Contact|Contact Info]]
; [[#openttdcoop Wiki:Sandbox|Sandbox]]
</div>
|}

<div style="margin-right: 10px; text-align: right; font-style: italic; font-size: 85%;">Changes for the main page can be proposed [[Main Page/editcopy|here]].</div>

PBS

2013-12-17T09:51:48Z

Benny: Marked for deletion

{{delete|We don't need this, link to this instead: http://wiki.openttd.org/Signals#Path_signals}}

==Description==
PBS stand for Path Based Signaling, which is a different way of signaling trains when they can enter a certain track segment. Although primarily intended in OpenTDD (and in the real world) to provide bi-directional track, without the deadlocks that will occur with regular signaling. Besides that it can also be used to increase performance in certain situations.

At the time of writing, a new implementation of PBS has made its way into the development branch of OpenTTD and might thus be encountered on the #OpenTTDCoop server. The implementation, named [[YAPP]], adds two additional signals. Because PBS takes some getting used to we've collected some examples and hints to work with.

==How it works==
For an explanation on the basics of YAPP and some examples, please check [http://wiki.openttd.org/Yet_Another_PBS_Patch the YAPP page] on the OpenTTD site.

In short: PBS introduces a new type of signal, which comes in two flavors. The first type is a regular (or: two-way) PBS signal, the second a one-way PBS signal. When a train encounters a PBS signal it will attempt to reserve a path. This means that it will look ahead at the path it wants to go and determines whether there are any obstacles in the way, such as another train. It will only look as far as the next signal it encounters (any signal, no specific type). When a reservation can be made, the train will go past the signal along the reserved path, otherwise it'll wait until it can do so.

The advantage of PBS is that it allows multiple trains to enter a PBS guarded area, as long as their reserved paths do not cross each other. While a regular signal would stop the second train until the entire section of track is clear, using PBS signaling trains can overcome this limitation. An example can be shown below. Here, both trains will attempt to enter the crossing, both trains go straight ahead on their path. When the first train encounters PBS signal A, it will reserve a path up to signal C. Since there are no obstacles, the reservation is allowed and the train passes. Moments later, the second train encounters signal B and attempts to reserve a path to signal D. Since train 1 is not in the way, the reservation will be made as well and train 2 will continue as well. At that time, both trains are in the same PBS signaled section. If regular signals would be used in this case, one train would always have to wait.

[[Image:pbs_demo1_2trains.png]] [[Image:pbs_demo2_2trains.png]]

As said, there are two types of the PBS signal (regular and one-way). The regular signal is basically two way, but passing the signal from the back comes with a penalty in the pathfinder which will thus attempt to avoid it. This signal can be useful for situations where you want to allow trains to pass the signal from the back, but only when there's no other way. Applications include two way stations and two-way track, all of which can be found in the OpenTTD wiki. The one-way signal does not allow trains from the back is is used in situations where it's combined with regular one-way track, such as the examples below. It could be said that one should avoid regular PBS in one-way track, because trains that reverse might collide with the train behind them.

==Examples from #OpenTTDCoop games==

===Terminus station===
This is a normal [http://wiki.openttd.org/Railway_station#Terminus terminus station], except that PBS is used to allow more than one train to be in the signaling block in front of the station. The entry has a one-way PBS signal, each station track has a normal PBS signal facing the station. The exit has a regular one-way exit signal. The advantage of the station shown in the screenshot is that it allows a train to leave the station while another train enter it. This could improve throughput, depending on how large your station is. Please note that the exit signal has a gap, to avoid that a train waiting in front of that signal will block the track.

Below is and example of PBS signaling used at a terminus station. As you can see, one train leaves the station taking the left most track to the exit. At the same time a train is entering the station on the middle track. The is actually only 1 PBS signal, directly in front of the station one could place more PBS signals but these are not really needed. Also, in the example below there's a single tile track section in front of the station. Although not really needed, it provides trains with some breaking space so the train will spend less time on the switches. This may sometimes clear a path for the next train sooner, increasing performance.

[[Image:Pbs_terminus.jpg|center|thumb]]

===PBS bridges===
The bridges shown here have only one signal placed in front of them, with regular signals after them. As you can see from the screenshot, there is very little track in front of the bridge, because there are no signals needed in front of the bridge.

[[Image:Pbs_bridge.jpg|thumb|center|Second train is using the second bridge, with only a single signal.]]

===PBS depot===
This depot setup slightly improves the amount of trains that can be serviced. It basically allows for two trains to be on the same tile, for example to have one train exit the depot while the other enters it.

[[Image:Pbs_depot.jpg|center|thumb|PBS depot. Notice that one train enters the depot while the other leaves, sharing the same tile.]]

===Avoid PBS after junctions===

You have read about 'do not place signals after junctions'. This means that after a PBS signaled junction the exit pad should have its signals placed a little while after the junction, to avoid a train blocking the junction. The reason for this can be observed below. Again, two trains are approaching the same block. Train one goes from A to C, train two from B to D. Because train one is first, it'll enter the junction, choose its path and will have to wait for train number 3, which is currently waiting for something. In this situation, train two is blocked bij train one and has to wait.

todo: image

If we place the signal at C further down the line, train one will not be able to reserve a clear path when it reaches the junction and has to stop at signal A. Train two will reach the junction and is now able to go to D without a problem. Train one and three are still waiting, but train two can move on.

todo: image

As you can see, it's good to leave a signal gap in this situation as it will increase performance. The same gap can be observed in the terminus station example shown above, where it is equal to the size of the train length.

Note however that it may sometimes be better not to leave a signal gap, depending on the traffic and the direction it is going to. When there's a lot of traffic in the example above and there is very little traffic that has to switch lanes, a signal gap might negatively affect performance since trains have to wait for the gap to be clear.

===Hints for using PBS===
* Enable 'Show reserved tracks' in the OpenTTD patches to show ingame which tracks are being taken by trains entering sections. In the screenshots above you can see this, the track is a little darker.
* Avoid PBS after junctions, as shown above.
* Build one-way PBS signals if possible. #OpenTTDCoop games will rarely need the use of two-way PBS.

=== See also ===

* [[Signals]]
* [[Presignals]]

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

Oneway or Twoway Presignals

2013-12-17T09:49:39Z

Benny: Marked for deletion

{{Delete|We don't need this, link to this instead: http://wiki.openttd.org/Signals#Pre-signals}}

[[Presignal_Basics|<< Presignal Basics]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Priority|Priority >>]]
----

=<center>Oneway or Twoway Presignals?</center>=
Signals have two sides, in the basics part, the other side wasn't important, since trains can't turn back, etc. etc... But in more complex things, a badly placed twoway combo presignal can make errors in your network.

==Part 1: The Station entrance problem with two entries==

[[Image:Twoentry2.PNG|thumb|center|404px|The error]]
In this station the combo presignal can make errors, but can you notice why? If presignals F-H are green then upper-right side of combo presignal C is green too. Even if presignals D and E are red, presignal A remains green. The problem is simple: Presignals calculate signal blocks, not the choosable tracks: trains cannot reach platforms F-H from A through C, but presignals CANNOT see this!
[[Image:Twoentry.PNG|thumb|center|404px|Fix this error by making the combo a oneway signal]]
How to fix this? Just change the combo presignal C to oneway (shown above) or add an oneway combo presignal just after it, like below:
[[Image:Twoentry3.PNG|thumb|center|404px|Or add a oneway combo presignal is added after it]]
With this layout, entry presignal A won't be affected by the signals for platforms F-H.

----
[[Presignal_Basics|<< Presignal Basics]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Priority|Priority >>]]
[[Category:Guides]]

Presignal Basics

2013-12-17T09:49:00Z

Benny: Marked for deletion

{{delete|We don't need this, link to this instead: http://wiki.openttd.org/Signals#Pre-signals}}

[[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Oneway_or_Twoway_Presignals|Oneway or Twoway Presignals >>]]
----

=<center>Presignal Basics</center>=
The Presignal Basics is explained here: how they work, how they behave, and how does work a terminal station, and whats the use of the combo presignal.

==Part 1: Identify the signals==
There are six types of signals in OTTD. If you click on a normal signal with CTRL is held, these signals will appear:

'''Normal Signal''': It does not have any special alibity, it turns to red if the next signal block is blocked by any train.

'''Entry Presignal''': It works like a normal signal, plus it turns to red if all exit presignals, or combo presignals are red after it.

'''Exit Presignal''': It works same as normal signal, but it signs for the entry, or combo signals, if self is red.

'''Combo Presignal''': It has both Entry and Exit presignal alibities: It turns to red if all Exit/Combo are red after it, and it signs for the Entry/Combo Presignals, if the self is red.

'''PBS Signal ''': Not a Presignal, it enables more trains in one signal block, since PBS means Path Based Signaling. This type of signal is not explained here.

'''One-Way PBS Signal ''': It works like a PBS Signal, however, it prohibits passing through from the back side. This type of signal is not explained here.

[[Image:Signals_revised.png|thumb|center|388px|Different signal types]]

==Part 2: The Station Problem==
Stations without any presignals have a big problem: just have a look on the Image to the below. Signal A should be red...[[Image:Terminal1.png|270px|center|thumb|Problem at stations without Presignals]]
If you let one more train to enter into the station, it will block the exit, because A signal is green. This problem is solvable with presignals: Just turn A into Entry presignal, and turn B and C signals to exit signals. [[Image:Terminal2.png|276px|center|thumb|Station with Presignals]] How does it work? If Exit Presignals B, C are both red, then Entry Presignal A is red too. Then a third train cannot pass trough Signal A.

==Part 3: An Effective RoRo station==
Combo Presignals are mostly placed between Entry, and Exit presignals, because the Combo Presignals transmits the Exit presignal signs for the Entry Presignals. Combo presignals behave as an entry presignal and an exit presignal both.[[Image:RORO1.png|center|thumb|526px|RORO station]] In the Image above, signal A is Entry Presignal, signals B, C, D, E are Combo ones, and F-K are Exit Presignals.

If F and G Platforms are used, then Combo signal B uses its Entry Presignal alibity, and it will turn to red, because F, and G Exit Presignals are both red. But the Entry Presignal A is remains green. Exit presignals H-K are green, then Combo Presignals D, E is green, then Signal C is green too. With this Combo Presignal B is red and C is green, then the Entry Presignal A is remains green.[[Image:RORO2.png|center|thumb|526px|The Entry remains green]]

The Entry Presignal A will be red only, if all Platforms are used, Exit Presignals F-K are red. If F-K are red, then all Combo Presignals B-E are red too, then the Entry A will be red.[[Image:RORO3.png|center|thumb|520px|All Platforms red]]

----
[[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Oneway_or_Twoway_Presignals|Oneway or Twoway Presignals >>]]
[[Category:Guides]]
[[Category:Basic networking]]

Guides:Presignals

2013-12-17T09:45:37Z

Benny: Marked for deletion

{{delete|Page is just a mess of links and, in my opinion, useless.}}
[[Guides:Building|<< Building-Index]] | [[Guides|^^ Back to Guides-Index]] | [[Guides:Altering|Altering-Index >>]]

=A Presignal Guide=
(under construction)
A guide for newbies, about presignals. However, this is not only for beginners as there are many complex things concerning presignals. If you know how the presignals work, you should skip the "basics" Part.

==Part 1: Basics==
The Presignal Basics is explained here: how they work, how they behave, and how does a terminal station work, and what's the use of the combo presignal.

[[Presignal Basics]]

==Part 2: Oneway or twoway Presignals==
Signals have two sides. In the basics part, the other side wasn`t important, since trains can`t turn back, etc. However, in more complex situations, a badly placed two way Combo Presignal can cause errors in your network.

[[Oneway or Twoway Presignals]]

==Part 3: Priorities==
When you have to connect two tracks into one, the most used track should have more priority than the lesser-used track.
In this Part, junctions with priority are shown.

[[Priorities]]

==Part 4: Load Balancers==
How to make presignals on a Load Balancer.

[[Balancing|Load Balancers]]

==Part 5: Complex Junctions==

[[Complex Junctions]]


----
[[Guides:Building|<< Building-Index]] | [[Guides|^^ Back to Guides-Index]] | [[Guides:Altering|Altering-Index >>]]
[[Category:Guides]]
[[Category:Basic networking]]

Priority

2013-12-17T09:40:08Z

Benny: Small changes, added links/changed some sentences etc

Priorities, or prios, are a type of signal [[Logic|logic]] used in [[Merger|mergers]]. Priorities can be made in many ways, all which will be covered here.

==Using two-way signals==
This is the easiest way to create priority. Use it with care though; when you have multiple two-way combo signals in a row the entire row will be red if one further down the line is, which will cause trains behind the one triggering the prio to stop. This kind of prio should be limited to one combo signal and an exit signal, making it only useful for very short trains or to avoid obstacles in more advanced prios.

[[File:twoway_prio.PNG|684px|thumb|none|Showing the maximum length a prio of this kind should be]]

==Standard prios==
This type of priority can be made infinitely long without causing any delays. It works as follows: a train on the mainline triggers the first of the combo signals on the parallel prio track, which then triggers all combos in the row, effectively making trains on the sideline wait when a train on the mainline is within 9 tiles of the merging point.

[[File:standard_prio.PNG|684px|thumb|none|A standard priority using a parallel track; the most common in our games]]

Note that you don't actually have to connect the parallel track to every gap between the signals, as long as the gap between the connections is not longer than the shortest trains on the network you're fine.

==Standard prio and two-way signals combined==
If you run out of room, sometimes using two-way signals ''and'' standard priorities is necessary.

[[File:standard_prio_and_two-way.png|684px|thumb|none|A standard prio combined with two-way signals.]]

==Standard prio over a bridge==
When you're building compact hubs you'll often find this trick to come in handy.

[[File:standard_prio_bridge.PNG|684px|thumb|none|A standard prio over a bridge using a parallel track.]]

The risk using this construction is that the gap between the connections to the parallel track becomes longer than the train on the mainline, in which case the prio won't trigger. This makes it pretty much un-usable for networks with [[Train length|trainlengths]] shorter than 4.

==Presignal prio over a bridge==
Even though it uses about the same space as standard prio over bridge (mentioned above), it doesn't need third bridge to function and is also friendly to low TLs.

[[File:presig_bridge_prio.png|684px|thumb|none|A presignal prio over a bridge]]

==PBS prio==
[[PBS]] introduced some interesting ways to make prios. This prio does exactly the same as the pre-signalled one:

[[File:standard_prio_pbs.PNG|684px|thumb|none|A standard 9-tile long PBS prio]]

==Combined PBS and presignal prio==
Useful in very tight spaces where twoway signal combined with standard prio is still too large.

[[File:pbs_presig_prio.png|684px|thumb|none|A PBS prio combined with twoway signals]]

==PBS prio over bridge==
The most interesting prio PBS introduces is the prio over a bridge. Using this technique you don't need a parallel track to have priority over a bridge, also you don't have to worry about the long gap between the connections anymore. Don't forget to use twoway signals at bridge exit, because PBS is likely to fail when combining twoway signal with oneway one.

[[File:pbs_prio_bridge.PNG|684px|thumb|none|Using this mix of PBS and pre-signalling you can have prio over bridges without parallel tracks]]

==Limited space==
Facing limited space is proverbial daily bread when it comes to joining or merging lines. Here are two examples using knowledge explained above how to build priority while keeping space used at minimum.

[[File:Same side prio.png|684px|thumb|none|Priority built at the same side as the joining track using combo and exit pre-signals on the main track]]

[[File:Used tunnel prio.png|684px|thumb|none|Priority built over used tunnel using PBS and combo pre-signal]]

== See also ==

*[[Logic]]
*[[Two-way Prio]]

----
[[Oneway_or_Twoway_Presignals|<< Oneway or Twoway Presignals]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Balancing|Balancing >>]]
[[Category:Guides]]
[[Category:Basic networking]]

Sideline Hub

2013-12-17T09:28:28Z

Benny: Increased image sizes and added link to prio article

[[Image:Testing Grounds, 22nd Dec 1950-1.png|right|thumb|500px|A very simple SLH connected to a L_R mainline]]
[[Image:Testing Grounds, 22nd Dec 1950.png|right|thumb|500px|An example Sideline Hub connected to a LL_RR mainline]]
A sideline hub (SLH) is the most common type of [[Hub|hub]] used in #openttdcoop games. It's purpose is to connect a [[Sideline|sideline]] to a [[Mainline|mainline]]. We usually build sideline hubs using [[Priority|prioritized]] [[Merging_Tracks|mergers]] to avoid slowing down mainline traffic.

Examples of sideline hubs can be found in the [[Junctionary_-_New_SLHs|Junctionary]].

== See Also ==
* [[Sideline]]
* [[Basic Networking]]
* [[BBH]]
* [[MSH]]

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

Sideline

2013-12-17T09:25:48Z

Benny: Added BBH/MSH to see also

[[Image:SL_stations_example.png|right|500px|thumb|Two typical sideline-connected stations]]

Sidelines are used to link primary industries (like coal mines or forests) to the [[Mainline|mainline]], and are connected to the mainline with [[Sideline_Hub|sideline hubs]]. Sidelines usually have a single track per direction and service 1-10 industries in a local area. Some bigger sidelines might have two tracks per direction and up to 20 industries attached to them. New stations for industries can be connected directly to sidelines.

Things like using double bridges and curve lenghts are less important on sidelines.

==Sideline stations==

Primary industry stations are always connected to sidelines, and are probably the simplest things we build in #openttdcoop games. The number of platforms depends on the production rate of the farm/mine/forest, but we usually start with 2-3 platforms. Take care about the pickup rating at primary industry stations, it should be as close to 100 percent as possible to raise production.

You should always keep some space in front of the entrance to a sideline station, with space for at least 2-3 trains, but more doesn't hurt. If all platforms of the station are occupied, you might have a train which wants to enter but has to wait in front of the station until another train departs. If there is too little space between the station and the corresponding sideline for waiting trains, the trains may jam up the sideline.

==Sideline hub==

''Full article: http://wiki.openttdcoop.org/Sideline_Hub''

Sideline hubs connect sidelines to the mainline.

[[Image:SLH_example.png|thumb|500px|A typical SLH connected to a LL_RR mainline]]

===See Also===
* [[Basic Networking]]
* [[BBH]]
* [[MSH]]

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

User:SherleneBryan

2013-12-14T12:51:53Z

Benny: spam

{{delete|spam}}

My name is Orville (41 years old) and my hobbies are Basket Weaving and Equestrianism.

Two-way end of line

2013-12-09T10:44:23Z

Benny: Added link to full overflow article

=== Two-way end of line ===
''Two-way end of line'' is a setting in OpenTTD that can be altered to create interesting train behaviour. By default it is off, but it is activated on every openttdcoop server.
A red two-way signal directs train to a different route if one is available.

''While used in combination with the default YAPF pathfinder, two-way signals have a weird and often misunderstood property. This property, called rail_firstred_twoway_eol, means that if the first encountered signal is a red two-way, that signal is considered a dead end. Now to understand the impact of this, one must first understand the basics of YAPF. In a nutshell: YAPF calculates all possible routes, called paths, from the train's current position. Each path is evaluated to a single score, determined by the length of the path, obstacles like stations, roads and hills, and upcoming red signals and ofcourse the ability to reach the destination (station). The train then chooses the path with the lowest penalty score.

Consider the train is on a junction and has multiple exit possibilities. The issue with red two-way signals is that if the first signal on a path is a red two-way, that path is not evaluated at all as it is considered a dead end. You could say that the path gets a penalty score of infinity. This also means that any other possible path, if it exists, is automatically better than the two-way path. Even if the other possibility is a trivial, detouring or outright useless path.
What this means in practice is:
* If all possible paths start with red two-way signals, the paths are considered equal and a choice is made without considering the network after the signals.
* If there is a single path not starting with a red two-way signal, that path is automatically chosen without considering the usefulness of the path itself.
Most important is that a choice is made without looking ahead at all. This includes checking if the chosen path actually leads to the desired destination. This can cause massive problems in our games, with games detouring or even driving themselves into a station or actual dead end.

Now is the EOL property a setting that can be changed. However, on our servers it is always on, as it gives trains the ability of free choice. If two different paths share a destination, but are considered by the pathfinder to be very unequal penaltywise, with single signals a train might decide to take the path with the lowest penalty, even though that means waiting for a red light. With two-way signals this will never happen.

In short:
* Only use two-way signals when you understand their workings and use. Otherwise, use single signals.
* Only use two-way signals in situations where each path has the same destination but a possibly very unequal penalty, and where it is important for the train to make an indiscriminant choice. You can think of mergers and SLH joins. But please remember that you don't always have to use them. If you can avoid them, do so.
* Especially avoid two-way signals when not all of the exits are two-way, and not all paths lead to the same place. The most common error is combining a double bridging of a mainline with the exit of a track.
* The exception is ofcourse for track that actually has to be two-way, like the signals next to platforms in terminus stations.
* Two-way signals can also legitimately be used in logic systems and the creation of priorities.''

=== Pathfinder trap ===
The most use of this setting is found in our [[SRNW]] games, we control trains to either take an exit to the sideline or stay on the mainline. We also combine this signal with a certain station or shortcut to create pathfinder traps. Pathfinder traps give us options to trick trains, we can decrease the pathfinder penalties to an actual station and so create more balanced traffic or we can balance mainline mergers. There are occasions where the inner lane is preferred so much we will create a shortcut from each lane to the inner lane after a merger. We disable an exit with the pathfinder trap so the trains will not actually take this path and a merger gives us a balanced output.
{| align="center"
|| [[File:Pftrap.png|300px|thumb|center|Pathfinder trap in its raw form.]]
|| [[File:Pftraponmainline.png|300px|thumb|center|Pathfinder trap on mainline to create a shortcut that can never be used.]]
|}
=== Station with overflow ===
Full article: http://wiki.openttdcoop.org/Overflow

In our games we often use overflows and this setting can help us create easy to implement overflows for our primaries. One example of this is found in the picture below.

{| align="right"
|| [[File:Overflow primary.png|300px|thumb|center|Overflow on the a primary with reverser arrows.]]
|| [[File:TerminusPrimary.png|300px|thumb|right|Arrows on a primary station]]
|}

In the picture you can see the “ arrow” in the reverser. It is not eye-candy it actually has a use. The pathfinder sees that the other tracks are blocked and considers the reverser only a viable line if it has at least 2 options. This means we create a split in the reverser so the pathfinder thinks it has two options.

Similarly we advise you to also use this arrow on every reverser, and in every terminus station with pre-signals at the final X as seen in picture below. In theory only the track that has a straight line to the exit track should have one, but we still prefer using them on all platforms for a terminus station.

=== Setting up two-way end of line ===
To setup this behaviour in your own game you can do this in two ways: We at openttdcoop prefer you use the second way because it is permanent, stable and easier.

*Either in game trough the console command accessible with the “~” key. Follow this by sending the following command:
“set yapf.rail_firstred_twoway_eol 1”
*The second way of changing this setting is by editing your openttd config file. And please do this when the game is closed. The location of this file is a question Google has an answer to. In here you find the line “yapf.rail_firstred_twoway_eol = false” and change it to “yapf.rail_firstred_twoway_eol = true” Follow this by saving and closing the config file.

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

Overflow

2013-12-09T10:43:48Z

Benny: Added link to 2-way eol and changed from stub to update.

{{update|everything}}
[[Image:Overflow example.png|right|thumb|386px|An example showing the simplest and most commonly used overflow]]

Overflows are a sometimes-handy feature of our networks. When they are used, they can save us a lot of work. On the other hand they have (of course) their disadvantages.

==Purpose==

Why do we build an overflow – our station tends to catch wave traffic and sometimes it just jams. The primal source of this are usually just jams on the network, making trains come in random intervals, randomizing also their required count to take all the cargo. So the first reaction on jammed station shouldn’t be to add an overflow, but unjam the network first.
In some cases it is possible that the station gets trains just randomly even when our network isn’t jamming at all. The perfect examples are basically any conditional orders, where trains could jump to other orders, skipping/adding part of their journey, reaching random travel times.

==Disadvantages==

Overflows need space and sometimes additional logic. If they are built without a reverser, their depot is visible, which can ruin refit or train replacement games, and lead to problems in other games.

==See also==
*[[Two-way end of line]]

Blog articles:
* [http://blog.openttdcoop.org/2010/04/26/advanced-building-revue-04-overflows/ Advanced Building Revue 04]
* [http://blog.openttdcoop.org/2012/06/28/advanced-building-revue-12-overflows-iii/ Advanced Building Revue 08]
* [http://blog.openttdcoop.org/2010/11/07/advanced-building-revue-08-overflows-ii/ Advanced Building Revue 12]

[[Category:Stations]]
[[Category:Basic networking]]

User:Benny

2013-12-06T06:46:44Z

Benny: Small changes

'''Date of Birth:''' 16/3-95'

'''Location:''' Rogaland, Norway. {{Flag|no}}

'''Started playing OpenTTD:''' January 2007

'''Joined OpenTTDCoop:''' 10.10.08, First game I actually played in was Public Server Game 116.

'''Prefers:''' Traditional games, low TL, utilizing space well.

'''Specialist on:''' Nothing, I suck at this game.

'''Weakness:''' Main stations, 4-way hubs.

'''Dislikes:''' Shift mainlines, newGRFs with annoying sprites, Toyland.

Known as Bennythen00b on the web and formerly known as Bennythen00b on here.

Main station

2013-12-04T11:39:59Z

Benny: Added link to ABR

Our networks usually have a single drop station for every cargo type or even one for multiple cargo types combined. With thousand or more trains running you can figure these stations have to be efficient and high capacity. Over the years we developed many types of main stations, each suitable for another purpose. First we'll look into the function of main stations and the standards they should meet for different purposes, then we will look into some common designs more deeply.

Recommended article: [http://blog.openttdcoop.org/2010/09/28/advanced-building-revue-07-stations/ Advanced building reuve 07 - Stations]

== Drop & Pickup seperation ==
One of the most important jam-preventing measurements we take is to keep drop and pickup stations separated. If we would not do this the situation could appear where all platforms are taken by secondary goods trains waiting to fully load, which will obviously never happen when there is no platform left for primary trains to unload.

== Breaking & Accelerating space==
You should keep this in mind when building any mainline station. Trains slow down when they enter a station, if trains are very close to each other one might be stopped when the train before it enters a station. This can be solved by having a few empty tiles in front of the station. The amount of empty tiles you need depends on both trainlength and train speed, the longer the length and the higher the speed, the more tiles you need. For long maglevs the number of tiles needed will be close to the actual length of the train. For long steamers a third of the trainlength will do. For maximum efficiency you'll also want a few empty tiles after the station to allow the train to accelerate before merging with the other trains. It is advisable to make this at least as long as the actual train; this way a train will never block the platform it just left when it has to wait to merge in with the other trains.

==Different styles==
As said, there are many different styles of main stations. Below I'll introduce them and name some pros and cons and when to use them. Each station can be categorized in one of two main categories: RoRo or Terminus. RoRo stands for Roll-on-Roll-off, which means a train enters a platform at one side, loads/unloads and leaves the platform at the other side. Terminus stations terminate a line; a train leaves a platform at the same side it entered. RoRo stations have a higher capacity than terminus stations; even though terminus stations' capacity is dramatically increased thanks to some clever designs, RoRo stations will always have a higher capacity. That said, the increased capacity for RoRo stations sometimes doesn't weigh up against the extra space it consumes. In practice you'll often find that RoRo stations are used mostly in cargo games and termini are most common in pax games.

==RoRo with dedicated platforms per track==
This type of station has the highest capacity. Period. No need to argue; there is no way you'll ever create something more efficient than a station that has a dedicated set of platforms for every incoming track. This station will be the best design when you have dense traffic and plenty of space to build your station.

[[File:Roro_dedicated_plats.PNG|400px|thumb|none|Showing a RoRo station with 7 dedicated platforms per tracks. Note the breaking and accelerating space]]

[[File:Roro_dedicated_plats_121.PNG|400px|thumb|none|Showing the same type of station in action in [[PublicServer:Archive_-_Games_121_-_130#gameid_121|PublicServer Game 121]]. ]]

However, there are some downsides to this design. The most important one is that it does not use its platforms efficiently; most of the platforms will be empty most of the time, only at surge times all platforms for a single track might be taken.This can be greatly reduced by introducing all-to-all acces for the incoming tracks.

==All-to-all RoRo==

All-to-all means that trains coming in from any track will be able to chose from any platform. As it is unlikely that all tracks will experience their peak traffic levels at the same time this approach requires less platforms, however, the construction becomes more complex.

[[File:Roro_all-to-all.PNG|400px|thumb|none|An LL_RR RoRo station with all-to-all acces]]

[[File:Roro_all_to_all_pz05.PNG|400px|thumb|none|4-entry tracks all-to-all RoRo in the insane network that was [[ProZone:Archive_-_Games_1_-_10#gameid_5|ProZone Game 05]]. ]]

==Pre-balancing==

This is a technique that basically combines the two designs above. It is rarely seen, but deserves more attention. This technique allows you to dramatically decrease the complexity of the all-to-all construction. As long as the amount of tracks during the pre-balancing process is never less than the amount of input tracks you should not get into bottleneck issues.

[[File:Pre_balanced_roro.PNG|400px|thumb|none|A RoRo featuring pre-balancing]]

==Pre-signal bypass station==

This is an entry-style that bypasses the gaps pre-signalling can cause, especially on bigger drop stations with short, fast trains. The [[Presignal_Bypass_Station|article dedicated to PSB]] (not to be confused with PBS, Path-Based Signalling) provides more in-depth information about this style.

==Regular Terminus==
You'll probably know this station style; it's one of the most basic in OpenTTD. It consists of a number of platforms connected to a construction that serves as both entry and exit. Below you can see an example of this basic terminus.

[[File:basic_terminus.PNG|400px|thumb|none|A terminus station with two platforms]]

Pros for this design are that it is very easy to build and very small. However, there are some major cons; the most important one being very low efficiency and capacity. The cross in front of the station serves as both exit and entry for the station, because it consists of only one block trains leaving the station will block trains from entering and vice versa. Using PBS will make the capacity a bit higher but it will still be pretty poor and therefore only suitable for remote and low-usage pickup stations.
This design's efficiency decreases when more platforms share the same block. The one in the picture above has 2 platforms sharing a block, it's pretty easy to make a station with more platforms sharing a block but as said, this will decrease capacity. You should try to avoid using this type of station, especially ones with more than 3 platforms sharing a block.
A way to make this station more efficient is to have multiple sub-stations connected to each other by a non-blocking entry, like the one shown below.

[[File:basic_terminus_multi.PNG|400px|thumb|none|A terminus station consisting of sub-stations]]

This design is still pretty simple and has a small footprint, this makes it suitable for bigger primary pickup stations and especially suitable in passenger games, usually for medium traffic density stations. However, this design still has the major drawback all basic termini have; it has multiple platforms sharing the same block. If you still want the small footprint of a terminus station but one with a capacity close to a RoRo, you should go with dedicated entries and exits for each platform.

==Terminus with dedicated entries & exits==
This station design, originally invented by {{User|Osai}} combines the best of both terminus and RoRo stations. It has the high capacity typical for a RoRo and the small footprint that comes with terminus. However, as you might have expected, this design is complex and hard to build.

The main idea behind this is to have an entry and an exit track dedicated to a single platform, rather than sharing one with others like normal termini do. Below you can see a two-platform station using this design.

[[File:dedicated_terminus_2p.PNG|400px|thumb|none|Basic two-platform terminus with dedicated entries and exits]]

For maximum result you'll want trains to be able to completely leave a platform before there ever is a chance of getting blocked. The design below is Osai's first example of his concept. It makes clever use of bridges over tunnel entries to make long exits, also the incoming tracks split before they tunnel under the exit and form a waiting bay.

[[File:dedicated_terminus_4p.PNG|400px|thumb|none|Dedicated entry and exit terminus with 4 platforms]]

The cacacity of this design is very close to that of a RoRo, the only factor making it slightly less efficient is the one shared tile right in front of the platforms. Especially with longer trains, however, this flaw is to be neglected. Because of its small footprint and high efficiency this design is very suitable for high-throughput passenger terminals, such as the one below.

[[File:dedicated_terminus_japan.PNG|400px|thumb|none|Showing the pax terminal in [[PublicServer:Archive_-_Games_161_-_170#gameid_164|Public Server Game 164]].]]

== See also ==

*[[Presignal Bypass Station]]
*[[Overflow]]
*[[Sideline station]]

[[Category:Stations]]
[[Category:Advanced Networking]]

Backbone Hub

2013-12-04T11:34:44Z

Benny: Added link to ABR

[[Image:BBH.png|thumb|right|An example Backbone Hub]]
A backbone hub (BBH) is the largest type of [[Guides:Glossary:Hub|Hub]] that is built in #OpenTTDCoop. It usually consists of at least 3 cardinal directions of [[Basic_Networking#Mainline (ML)|mainline]] Track, and is also usually [[Balancing|balanced]] as well.

Recommended blog post: [http://blog.openttdcoop.org/2010/07/10/advanced-building-revue-06-hubs/ Advanced building revue 06 - Hubs]

== Function ==

A BBH connects [[Basic_Networking#Mainline (ML)|mainline]] segments to each other, most often in [[Junctionary_-_BBHs_-_4way|4-way]] or [[Junctionary_-_BBHs_-_3-way|3-way]] junction patterns.

== Requirements ==

A BBH must be:
* [[Balancing|Balanced]] - ie: each lane entering the BBH should be able to choose any lane leaving the BBH
* Efficient - Trains should not have to slow down
* Properly sized for the highest [[User:Tim/Tilelength|length]] trains in use

== Backbone Hub Building ==

Backbone hubs are complex structures and can be quite overwhelming at first. In this article I'll try to break down backbone hub construction in pieces in an attempt to make it easier to understand and give an idea on how to start. Note that this article does expect at least basic knowledge about pre-signalling and knows the #openttdcoop building standards, including doubled bridges, non-slowing down curves and balancing.

The BBH we're going to build here will be an LL5RR to LL5RR 3-way one. These are quite common and relatively easy to build. Below you can see the mainlines that are already in place, waiting for the BBH to be built.

[[File:BBH_building_1.PNG|400px|thumb|none|Unconnected mainlines waiting for the BBH we're going to build]]

A typical 3-way can be broken down into pieces; one ML crossing, one crossover, 3 exits and 3 joins. You'll want to start with the ML crossing, this is where the ML crosses an other ML. It is a common mistake to start with an exit or a join; don't do this. The ML crossing will be in the center of the hub, making it hard to add later.
The crossover is the point where the joining mainline cross each other, you will one or more of these in every BBH because they are needed to allow traffic to go to the other direction. In the image below the ML crossing and crossover are built. Also the locations for the joins and exits are signed, giving a general idea about the layout we'll have in the end. The first exit obviously was built together with the crossover.

[[File:BBH_building_2.PNG|400px|thumb|none|The first parts of our BBH are done]]

Now let's make the other 2 exits, this should be pretty straightforward as exits don't require balancing.

[[File:BBH_building_3.PNG|400px|thumb|none|The other exits are in place]]

Up next are the joins; these are harder than exits because they require balancing. At this point you can already see we won't have to worry about space limitations because we started building outwards from the center. Below shows our BBH with full-balanced non-blocking all-to-all joining.

[[File:BBH_building_4.PNG|400px|thumb|none|Balanced joins are added]]

The only thing left to do is finishing the signaling and adding priorities to our balancers. Note that you can hack in priorities in any place, so you don't have to worry about reserving space for them.

[[File:BBH_building_5.PNG|400px|thumb|none|Signals and prios are added, completing our BBH]]

[[Category:Guides]]
[[Category:Basic networking]]
[[Category:Advanced Networking]]

Hub

2013-12-04T11:33:43Z

Benny: Added link to ABR

A Hub, is the OpenTTD term for an intersection of multiple railroad tracks that go in different directions. It is very comparable to real life intersections on roads, from a crossroads to an interstate interchange.

Various types in #OpenTTDCoop include:
* [[Backbone Hub|Backbone Hub]]
* [[MSH|Main Station Hub]]
* [[Sideline Hub|Sideline Hub]]

=== See also ===

*[http://blog.openttdcoop.org/2010/07/10/advanced-building-revue-06-hubs/ Advanced building revue 06 - Hubs]

[[Category:Guides]]

Self-regulating Network

2013-12-04T11:17:58Z

Benny: Added train length splitters

== 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]]}}

== See also ==

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

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

Planning

2013-12-04T11:12:24Z

Benny: Removed guides links

Coordination is very important for cooperative gameplay since the goals and implementation tactics are meant to be shared among all participants. The planning stage of game is the time to lay a good foundation for prolonged and interesting gameplay, where the final result is achieved by combined activity of all players. Planning does take some skill and experience, and should be taken a serious task and with responsibility for future development. It should provide detailed description of what and how is to be achieved.

==Studying the map==
There is no basic "best strategy" for all situations. All games are very circumstantial, environment-dependent, and have different focuses. Even for targeted games, when a particular scenario or game preconditions are used, it still remains very open-ended and a successful result can be achieved by many ways. Thus, it is very important to explore the map and foresee future development and implementation, ensuring that it is possible to achieve the goals that are set. Some layouts are only applicable to certain cases and various types of networks deal with landscape in different fashions. It is very important to keep in mind that it is not that landscape is to be altered to fit the idea of the plan, but vice versa—the plan must adhere to circumstances.

==Defining main elements==
All plans have certain main elements which predefine the plan's foundation.

These are:
; Game type : Global [[Game types]] (i.e.: PAX, Cargo, SRNW etc.)
; Goals/focus : Narrowing down the type to a particular point (i.e.: ''flow'/capacity', ''speed'', ''second tier saturation'', ''connecting something'', etc.)
; Network type : Basic rules, describing type of lines used (perhaps: ''plain'', ''segregated'', ''distributed'', ''shifting'' ) and track width, along with details (such as: ''prioritised 2nd tier', ''none blocking mergers only'', ''expandable to ...'' etc.)
; Network layout : That controls shape of lines and defined by major stations' requirements. Should be done in some illustrated form or shape, providing enough details to show key points of particular layout.
; Perks : anything what is out of ordinary and not generally applicable to described conditions (i.e.: ''steam only'', ''no terraforming'', ''avoid coal'', ''save all trees'')

==Sharing ideas==
It is possible that there are already plans being discussed or that some are made, in which case it would make sense to comprehend them and understand key elements and differences. Presenting many plans with differences only in directions of tracks or train length used is quite pointless. It would be better to discuss with the author possible changes and make corrections to the existing plan if they are considered as useful after coming to consensus. Plans as well as the game itself can be result of collaboration and shaping the ideas based on experience of different players. However, please make sure to suggest changes rather than insist upon them.

==Planning==
Usually, there is a remote spot on the map somewhere with sign " !!NETWORK PLANS" next to it. This is designated for laying out proposed plans. If there is no area marked in this way, feel free to create one. Bear in mind that plans are meant to last the whole game and selecting densely populated areas makes very little sense; typically remote areas such as corners and edges of map, with even or gently rolling terrain are the best spots.

When creating a plan, allocate yourself enough space and try not to interfere with other people's work. Make sure to state as many details as possible to make the plan clear for others (separation between primary/secondary, type of network and width, train lengths etc.). Major elements design can also be noted in case if it is not clear from visual layout. Make sure the plan is comprehensive and covers all/most game aspects. Don't forget to title and sign it, as well as to add it to voting board if one is there already.

After the core of your plan is done, listen for critique and constructive comments, be patient for more plans to appear, and wait until voting is finished. It is quite common for the planning phase to take a long time simply because of different people's schedules and other limitations.

==Understanding complexity==
As an author of a plan you are responsible for covering many aspects in design and location of key elements (be it a hub station or the location of a drop). A good plan should present an opportunity for many players to have their input useful for achieving the goal. It should not be overly complex or simply impossible but have various challenges for a variety of skill levels. It should also withstand the test of time. In many cases planned expandability saves the day by turning tedious upgrades into a set of doable tasks with little to no interference to the existing network.

==Implementation==
In case if you plan is chosen (and that is bound to happen sometime), as author, you are encouraged to provide as much help as possible to execute the plan. The creator of the selected plan takes a guiding role of chief engineer, answering questions and being a source of wisdom when unforeseen challenges arise.

It greatly helps for proper implementation to have predefined locations for major nodes of the network as well as other important elements. Selecting placement for these, by putting signs in desired places, essentially charts the map to meet the plan's requirements. Being the author does not mean that it is totally up to you to create the whole network, but playing a key role in creation process is expected. At the same time let others help you to "get there:" it will be faster and more entertaining as the joint effort of many—that's what #openttdcoop is about, after all!

==Modification and corrections==
As time goes, it is quite possible that a need for reform or alteration is required due to change in environment, implementation limitations or unforeseen roadblocks. In the event that such drawbacks are observed, it is imperative to quickly react and modify the plan to satisfy new needs. Along with being ''proactive'' and trying to ensure the future of the game, authors should also try to be ''reactive'' to ongoing development. Other players can provide valuable input which can ease extreme challenges and help avoid known pitfalls. Sometimes there are several approaches that can be taken and it is up to author to consider alternatives and make wise choices and introduce corrections to the plan.

==Examples==
{|
|| [[Image:plan4.png|thumb|center|320px|]] || [[Image:plan1.png|thumb|center|320px|]]
|-
|| [[Image:plan2.png|thumb|center|320px|]] || [[Image:plan3.png|thumb|center|320px|]]
|-
|| [[Image:plan0.png|thumb|center|320px|]] || [[Image:plan5.png|thumb|center|320px|]]
|-
|| [[Image:plan6.png|thumb|center|320px|]] || [[Image:plan7.png|thumb|center|320px|]]
|-
|| [[Image:plan8.png|thumb|center|320px|]] || [[Image:plan9.png|thumb|center|320px|]]
|}

[[Category:Guides]]

Self-regulating Network

2013-12-04T11:11:33Z

Benny: Added see also

== 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]]}}

== See also ==

*[[Self-regulating SBahn]]
*[[SML]]

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

Self-regulating SBahn

2013-12-04T11:10:55Z

Benny: Added see also

==Definition==

[[Image:SRS_Overview.png|250px|thumb|right|SRS Overview]]
A self-regulating SBahn (hereafter referred to as an SRS) is a network that requires virtually no maintenance to ensure all of the connected stations are serviced in a very efficient manner.

Like any other SBahn, trains will be picking up cargo from a number of stations, and then transferring that cargo at an ICE (Inter-City Express) station, where the cargo is loaded onto another train for delivery to a remote location. For more information about that concept, review the [[Gametype:ICE_SBahn | ICE_SBahn]] article.

The self-regulating aspect is provided through use of each train's order list, and how the tracks are laid out.

== Trains and Orders ==

[[Image:SRS_TrainOrders.png|250px|thumb|right|SRS Train Orders]]

In an SRS, all of the stations are serviced by a single group of trains. Each train has a single order to visit the ICE station. Once they leave the ICE station, the only way back is through one of the numerous stations on the SBahn loop (the only exception being the use of the overflow line, detailed later). At these stations, the trains will load any available cargo before travelling back to the ICE station.

Depending on the catchment and amount of cargo generated at each station, there may be one or more platforms available, each with a waiting queue for zero or more trains. If a train reaches an exit on the SBahn loop where a platform and/or waiting queue space is available, it will take that exit, as the train will always look for the shortest unobstructed route to the next destination on its order list (in this case, the ICE station). If there are no platforms or waiting queue spaces available, the train will continue along the loop to the next exit.

If these trains contained specific stations in their order list, a player would be required to periodically inspect each station to ensure that they are all receiving enough attention. The lack of orders will ensure that each station receives trains regularly, provided enough trains are servicing the loop. To determine if there are enough trains, simply look at the cargo ratings for the last station on the loop. Good ratings indicate it is also being regluarly serviced. Poor ratings indicate that the trains are not reaching the station, which generally means there are not enough trains to handle the previous stations. In this case, more trains are needed (see the section on Injection below)

== Overflow ==

If a train passes the final exit on an SBahn loop, and has been unable to find a platform or waiting queue space, the train is considered to be on the overflow track. If trains enter the overflow track, it simply means that the network has more trains than are needed to service the network. In this case, the train can be sent back to the beginning of the loop (bypassing the ICE station), or it can be temporarily put into a holding pattern using a waiting area or depot.

== Injection ==

[[Image:SRS_Timer.png|250px|thumb|right|SRS Timer Train]]

Injection is the process by which new trains are added to the network.

Trains that have reached the overflow lane may be re-introduced into the SBahn loop by connecting the end of the loop back to the beginning. (Note that the overflow track is constructed separately from the SBahn loop exit tracks. The SBahn loop exit tracks visit the ICE station before re-entering the SBahn loop, while the overflow track bypasses the ICE station).

These trains can be injected automatically, or this injection can be done gradually through use of a timer. The timer is simply a single engine running on a separate loop. The timer train has timetable orders to sit at a station for a predetermined length of time. This station is in the same signal block as the overflow track, so while the timer train sits at the station, it blocks overflow trains from re-entering the SBahn loop. Once the timer train leaves the station, the signal block is cleared, allowing an overflow train to re-enter the SBahn loop. Due to the blocking nature of this timer, it is best to construct a depot to contain trains that are waiting to get back onto the SBahn loop. Otherwise, too many trains could cause a backup that blocks the later stations on the SBahn loop, and could potentially lead to deadlock in extreme cases.

The injection process is the only aspect of the SRS that requires periodic review. If no trains enter the overflow track, then the cargo generated on the SBahn loop may exceeed the capacity of the trains handling the loop. For this reason, it is best to have at least one or two trains available in the overflow track for injection into the network. Worst case, these trains immediately overflow and return back to the overflow track.

[[Image:demandinjection.PNG|800px|center|thumb|Showing a different injection-system possibiltity, this one actually looks at whether the network has enough trains or needs more. The idea behind it is to add a train if no train overflowed for 9 days. This system is used in the Selfregulating Network in PZG02]]

== Stations on the SBahn loop ==

[[Image:SRS_FullLoad.png|250px|thumb|right|SRS Loading Mechanism]]

Because the trains on the SBahn loop have a single order (to transfer at the ICE station), they will not wait at an SBahn loop station for a full load. To ensure these trains are loaded to capacity, it is required to have some sort of controlling mechanism at each of the SBahn loop stations to ensure that when a train arrives at the station, a full load of cargo is available. Once any available cargo has been loaded onto the train, it will immediately leave the station, not waiting for any more.

One mechanism that can be used is a feeder train on an isolated track at each station. This feeder train will block trains from entering the platform until it is fully loaded at an adjacent feeder station. Once that train is full, it will leave the feeder station and travel to the SBahn loop station. This movement will unblock the SBahn loop platform, allowing a train to enter. While it is entering, the feeder train transfers its cargo at the SBahn loop station, which is then picked up by the SBahn loop train.


(needs expansion, further explanation)

== Alternative Designs ==

By design, and SBahn is a loop. However, with some creativity, the design of this loop can vary greatly. Here are some additional examples of self-regulating SBahn networks:

[[Image:SRS_Linear.png|800px|thumb|center|SRS Linear Design - note how the terminus stations reduce the station size, and the overflow track tunnels under the stations to allow for more city buildings.]]

== See also ==

*[[SRNW]]

[[Category:Advanced Networking]]

Main station

2013-12-04T11:00:35Z

Benny: Added see also

Our networks usually have a single drop station for every cargo type or even one for multiple cargo types combined. With thousand or more trains running you can figure these stations have to be efficient and high capacity. Over the years we developed many types of main stations, each suitable for another purpose. First we'll look into the function of main stations and the standards they should meet for different purposes, then we will look into some common designs more deeply.

== Drop & Pickup seperation ==
One of the most important jam-preventing measurements we take is to keep drop and pickup stations separated. If we would not do this the situation could appear where all platforms are taken by secondary goods trains waiting to fully load, which will obviously never happen when there is no platform left for primary trains to unload.

== Breaking & Accelerating space==
You should keep this in mind when building any mainline station. Trains slow down when they enter a station, if trains are very close to each other one might be stopped when the train before it enters a station. This can be solved by having a few empty tiles in front of the station. The amount of empty tiles you need depends on both trainlength and train speed, the longer the length and the higher the speed, the more tiles you need. For long maglevs the number of tiles needed will be close to the actual length of the train. For long steamers a third of the trainlength will do. For maximum efficiency you'll also want a few empty tiles after the station to allow the train to accelerate before merging with the other trains. It is advisable to make this at least as long as the actual train; this way a train will never block the platform it just left when it has to wait to merge in with the other trains.

==Different styles==
As said, there are many different styles of main stations. Below I'll introduce them and name some pros and cons and when to use them. Each station can be categorized in one of two main categories: RoRo or Terminus. RoRo stands for Roll-on-Roll-off, which means a train enters a platform at one side, loads/unloads and leaves the platform at the other side. Terminus stations terminate a line; a train leaves a platform at the same side it entered. RoRo stations have a higher capacity than terminus stations; even though terminus stations' capacity is dramatically increased thanks to some clever designs, RoRo stations will always have a higher capacity. That said, the increased capacity for RoRo stations sometimes doesn't weigh up against the extra space it consumes. In practice you'll often find that RoRo stations are used mostly in cargo games and termini are most common in pax games.

==RoRo with dedicated platforms per track==
This type of station has the highest capacity. Period. No need to argue; there is no way you'll ever create something more efficient than a station that has a dedicated set of platforms for every incoming track. This station will be the best design when you have dense traffic and plenty of space to build your station.

[[File:Roro_dedicated_plats.PNG|400px|thumb|none|Showing a RoRo station with 7 dedicated platforms per tracks. Note the breaking and accelerating space]]

[[File:Roro_dedicated_plats_121.PNG|400px|thumb|none|Showing the same type of station in action in [[PublicServer:Archive_-_Games_121_-_130#gameid_121|PublicServer Game 121]]. ]]

However, there are some downsides to this design. The most important one is that it does not use its platforms efficiently; most of the platforms will be empty most of the time, only at surge times all platforms for a single track might be taken.This can be greatly reduced by introducing all-to-all acces for the incoming tracks.

==All-to-all RoRo==

All-to-all means that trains coming in from any track will be able to chose from any platform. As it is unlikely that all tracks will experience their peak traffic levels at the same time this approach requires less platforms, however, the construction becomes more complex.

[[File:Roro_all-to-all.PNG|400px|thumb|none|An LL_RR RoRo station with all-to-all acces]]

[[File:Roro_all_to_all_pz05.PNG|400px|thumb|none|4-entry tracks all-to-all RoRo in the insane network that was [[ProZone:Archive_-_Games_1_-_10#gameid_5|ProZone Game 05]]. ]]

==Pre-balancing==

This is a technique that basically combines the two designs above. It is rarely seen, but deserves more attention. This technique allows you to dramatically decrease the complexity of the all-to-all construction. As long as the amount of tracks during the pre-balancing process is never less than the amount of input tracks you should not get into bottleneck issues.

[[File:Pre_balanced_roro.PNG|400px|thumb|none|A RoRo featuring pre-balancing]]

==Pre-signal bypass station==

This is an entry-style that bypasses the gaps pre-signalling can cause, especially on bigger drop stations with short, fast trains. The [[Presignal_Bypass_Station|article dedicated to PSB]] (not to be confused with PBS, Path-Based Signalling) provides more in-depth information about this style.

==Regular Terminus==
You'll probably know this station style; it's one of the most basic in OpenTTD. It consists of a number of platforms connected to a construction that serves as both entry and exit. Below you can see an example of this basic terminus.

[[File:basic_terminus.PNG|400px|thumb|none|A terminus station with two platforms]]

Pros for this design are that it is very easy to build and very small. However, there are some major cons; the most important one being very low efficiency and capacity. The cross in front of the station serves as both exit and entry for the station, because it consists of only one block trains leaving the station will block trains from entering and vice versa. Using PBS will make the capacity a bit higher but it will still be pretty poor and therefore only suitable for remote and low-usage pickup stations.
This design's efficiency decreases when more platforms share the same block. The one in the picture above has 2 platforms sharing a block, it's pretty easy to make a station with more platforms sharing a block but as said, this will decrease capacity. You should try to avoid using this type of station, especially ones with more than 3 platforms sharing a block.
A way to make this station more efficient is to have multiple sub-stations connected to each other by a non-blocking entry, like the one shown below.

[[File:basic_terminus_multi.PNG|400px|thumb|none|A terminus station consisting of sub-stations]]

This design is still pretty simple and has a small footprint, this makes it suitable for bigger primary pickup stations and especially suitable in passenger games, usually for medium traffic density stations. However, this design still has the major drawback all basic termini have; it has multiple platforms sharing the same block. If you still want the small footprint of a terminus station but one with a capacity close to a RoRo, you should go with dedicated entries and exits for each platform.

==Terminus with dedicated entries & exits==
This station design, originally invented by {{User|Osai}} combines the best of both terminus and RoRo stations. It has the high capacity typical for a RoRo and the small footprint that comes with terminus. However, as you might have expected, this design is complex and hard to build.

The main idea behind this is to have an entry and an exit track dedicated to a single platform, rather than sharing one with others like normal termini do. Below you can see a two-platform station using this design.

[[File:dedicated_terminus_2p.PNG|400px|thumb|none|Basic two-platform terminus with dedicated entries and exits]]

For maximum result you'll want trains to be able to completely leave a platform before there ever is a chance of getting blocked. The design below is Osai's first example of his concept. It makes clever use of bridges over tunnel entries to make long exits, also the incoming tracks split before they tunnel under the exit and form a waiting bay.

[[File:dedicated_terminus_4p.PNG|400px|thumb|none|Dedicated entry and exit terminus with 4 platforms]]

The cacacity of this design is very close to that of a RoRo, the only factor making it slightly less efficient is the one shared tile right in front of the platforms. Especially with longer trains, however, this flaw is to be neglected. Because of its small footprint and high efficiency this design is very suitable for high-throughput passenger terminals, such as the one below.

[[File:dedicated_terminus_japan.PNG|400px|thumb|none|Showing the pax terminal in [[PublicServer:Archive_-_Games_161_-_170#gameid_164|Public Server Game 164]].]]

== See also ==

*[[Presignal Bypass Station]]
*[[Overflow]]
*[[Sideline station]]

[[Category:Stations]]
[[Category:Advanced Networking]]

Sideline station

2013-12-04T11:00:17Z

Benny: Redirected page to Sideline#Sideline stations

#REDIRECT[[Sideline#Sideline stations]]

Presignal Bypass Station

2013-12-04T10:56:43Z

Benny: Addde to advanced networking category

Building a large station, as is needed for pickups and drops for secondary industries, is a difficult task. There are many challenges due to the large capacity. The station must have sufficient flow to prevent jamming. Cities, industries, and other landmarks provide boundaries to a desired station layout.

A typical secondary station consists of about 20 platforms and is served by a [[Mainline|ML]] of 3-4 tracks. It requires a lot of skill to build a proper joiner after the station and it is even more difficult to build a splitter to allow the trains to efficiently access the platforms. This complexity typically requires lots of bridges, tunnels, and presignals.

==The Idea==

This idea proposes a station that can be extended from a small-scale station to a much larger-scale station by adding platforms in the same pattern, without needing to completely redesign the station as its capacity grows. The station is turned by 90 degrees relative to the track the trains come from. The trains pass through the station until they find a free spot, and then enter it. If the traffic is too heavy, the station can be extended with more platforms. After adding presignals, it works... for slow traffic. As a train in the presignal area will block the whole presignal block, other trains have to wait at the beginning, even if there are a lot of slots free.

[[Image:Blocking the presignal area.png]]

As you see, the train entering the station blocks the other train from joining the last slot. So I thought about some presignal stuff which transports the information "slot is free" from the slots at the end to the presignal at the beginning. I did this with a second line, similar to [[priorities]].

[[Image:Second presignal line.png]]

Notice how the free-slot information "travels" through the marked tiles around the train which blocks a segment. With these presignals, a new train can enter the presignals even if there already a train entering the platform.

==How to improve the layout==

Only a half of station's platforms are used and cannot be used from this side as the complex signaling blocks the entry. But they can be used from the other side.

[[Image:Use the other side.png]]

For an exit, the trains can go through tunnels under the presignal logic for the opposite entry.

[[Image:Station layout with tunnels.png]]

If the trains leave the station, they have enough space in the tunnel to wait if the exit isn't free yet. You can see the exit from the upper part goes east, the exit from the lower part goes west. This can be flipped/switched however you need it. You also see a disadvantage of this layout. This station and all tracks and signals with a TL of 5 are 23 tiles width. You need around 18+TL tiles space for the width. But - and thats the advantage - you can extend this layout as long as you need.

[[Image:Full station with a lot of slots.png]]

You see here again you can choose from where the trains come and where they go. This can be changed as whatever you want.

[[Image:Station diagramm layout.png]]

Thats how it looks in a real game

[[Image:Station goods drop.png]]

And that is how it looks on a real game in an openttdcoop-game

[[Image:Station goods drop ottdcoop.png]]

[[Image:Station coal_ore drop ottdcoop.png]]

[[Category:Stations]]
[[Category:Advanced Networking]]

Game Types

2013-12-04T10:55:17Z

Benny: Redirected page to Game types

#REDIRECT[[Game types]]

File:Overflow example.png

2013-12-04T10:39:06Z

Benny: uploaded a new version of "File:Overflow example.png": Derp derp fucking up signals whooo

An example showing the simplest and most common overflow used on the server

Valhalla's custom build

2013-12-04T10:23:19Z

Benny: Added to history category

{{obsolete}}
Current build based on r3271. New builds will be done when my computer works again :p

== Windows ==
Download build [http://nightly.openttd.org/win32/OTTD-win32-nightly-r3271.zip r3271] from the main release.
Download [[:Image:Custombuild.zip|the win32 custom build]] and overwrite openttd.exe with the one from this archive.

== Other OS'es ==
Sorry, no precompiled binaries ;)

Download the [http://nightly.openttd.org/source/OTTD-source-nightly-r3271.tar.gz r3271 source] or checkout r3271 from SVN. Download [[:Image:Custombuild.patch|the patch]], apply and build. Play!

[[Category:History]]

Openttdcoop News

2013-12-04T10:22:45Z

Benny: Added to history category

<noinclude>{{obsolete}}== Latest News ==</noinclude>

The latest News are now always communicated in our [[http://www.openttdcoop.org/blog/| blog]]

== August 2006 ==

'''05.08.2006''': The first [[Coopetition|Coopetition]] took place today! Read a short summary at [http://openttdcoop.ppcis.org/blog/2006/08/05/congratulations-mucht-and-osai/ our blog!]

'''01.08.06''' and a day with even more news:
*[[User:XeryusTC|XeryusTC]] is promoted to a full member now - now the lazy days are gone for you!
*[[User:Ammler|Ammler]] is joining us on the [[Main_Server]] now.
*[http://openttdcoop.ppcis.org/blog/ Our blog] is alive and will be maintained from now on!
* Our [[Sandbox_Server|Sandbox-bot]] is alive and kickin'!

'''31.07.06''': After having some discussions around our current system of '''wiki''' and '''blog''' we decided to redefine some things. More news on that coming soon - stay tuned!

<noinclude>
== July 2006 ==
'''24.07.06''': A day full of news:
* [[User:OwenS|OwenS]] joins our [[Main_Server|Mainserver]]-team! Congratulations!
* After some hard work on this wiki, many improvements are done. To have an idea of the ongoing improvements, check our whole-new [[Sandbox:Archive|Sandbox Archive]].
* [[User:Valhallasw|Valhallasw]] has made some mediawiki hacks to get new permission settings. Every registered user is now welcome to edit their [[Special:Mypage|user page]] and to discuss ideas on the talk page of every article. Experienced sandboxers are welcome to help on the wiki in the Sandbox: namespace, which, for example, hosts [[Sandbox:Archive|the Sandbox Archive]].
* The team is working on some whole new concepts for our community - stay tuned!

'''21.07.2006''': Due to some issues with the US-Stations-GRF we reworked our whole GRF-Set. We took the chance to implement the planeset so our games will become even more eyecandy in the future. Check our [[Guides:Glossary:GRF|related page]] to update your config file and get the new package of GRFs!

'''19.07.2006''': A [[Sandbox_Server|Sandbox game]] started - again. Our [[Community:Members|Sandboxers]] are very active today. They decided to create an [[Gametype:ICE_SBahn|ICE-game]] - with the recently developed 'S-Bahn'-Idea.

'''09.07.2006''': The [[Sandbox_Server|Sandbox game]] has been restarted. A new game is up.

'''08.07.2006''': The [[Main_Server|Main Server Game]] is developing fast - in the meantime, the [[Sandbox_Server|Sandbox game]] seems to be almost finished and one has to expect a new Sandbox map coming up the next days.

'''03.07.2006''': [[User:XeryusTC|XeryusTC]] has been invited to the mainserver - congratulations! Furthermore, the community started an all-new mainserver game based on the scenario "Bigriver".

== June 2006 ==
'''30.06.2006''': Right after the serverupgrade our Sandboxers started a news game. Join them in their efforts and visit [[Sandbox Server]] for further details.

'''30.06.2006''': #openttdcoop changes both [[Main Server]] and [[Sandbox Server]] to OTTD Nightly r5431. Additionally, we have chosen some GRFs we will use in order to enhance our gameplay. Get the whole information [[Guides:Glossary:GRF|here]].

'''08.06.2006''': #openttdcoop Servers are online again, check out [[Main Server]] and [[Sandbox Server]] for new ip addresses and further information

'''05.06.2006''': #openttdcoop decided to make use of additional grfs. These new grfs will enrich our gameplay and make our games more 'eyecandy'. Check [[Guides:Glossary:GRF|this page]] for further details.

'''05.06.2006''': #openttdcoop started a new game on the [[Main Server]]; join our IRC channel if you are interested in our games!

== Feburary 2006 ==
'''27.02.2006''': #openttdcoop welcomes [[User:csuke|csuke]] to our mainserver! After joining our sandbox some 3 months ago and proving his skills on loadbalancing as well as hub- and stationbuilding, csuke will support our team at the mainserver!

'''16.02.2006''': Our Sandboxers have started a new map! Have fun!

'''12.02.2006''': [[Community:Members|Userpages]] updated! Please check your own status + userpage and report at the IRC-Channel.

'''11.02.2006''': #openttdcoop started the [http://www.tt-forums.net/viewtopic.php?t=23437 Challenge the #openttdcoop] campaign.

'''10.02.2006''': [[User:Truelight|Truelight]] has been invited to the mainserver after playing several maps at the Sandbox!

'''05.02.2006''': [[User:e1ko|e1ko]] joined our team as a [[Membership|full member]]!

</noinclude>

[[Category:History]]

Collective Transport

2013-12-04T10:21:44Z

Benny: Added to history category

Collective Transport, also known as Collective Frankenstein, was a game in the [[Gametypes#Back To Basics|Back To Basics]] style. It was home to the [[Crazy Hubs|Frankenstein Hub]], which was later redone, and it was the game in which [[Ghetto Style Hubs|"Ghetto Style"]] hubs were introduced. Below are screenshots showing network development.

{|align="center"
|-
|[[Image:Collective_Transport%2C_27th_Feb_1950.png|thumb|center|1950]]
|[[Image:Collective_Transport%2C_26th_Oct_1952.png|thumb|center|1952]]
|[[Image:Collective_Transport%2C_23rd_Apr_1955.png|thumb|center|1955]]
|-
|-
|[[Image:Collective_Transport%2C_12th_Jul_1959.png|thumb|center|1959]]
|[[Image:Collective_Transport%2C_7th_Jun_1969.png|thumb|center|1969]]
|[[Image:Collective_Transport%2C_27th_Jan_1971.png|thumb|center|1971]]
|-
|-
|[[Image:Collective_Transport%2C_16th_Nov_1972.png|thumb|center|1972]]
|[[Image:Collective_Frankenstein%2C_8th_Aug_1973.png|thumb|center|1973]]
|[[Image:Collective_Frankenstein%2C_11th_Jan_1975.png|thumb|center|1975]]
|-
|-
|[[Image:Collective_Frankenstein%2C_26th_Jan_1979.png|thumb|center|1979]]
|[[Image:Collective_Frankenstein%2C_20th_Jun_1989.png|thumb|center|1989]]
|[[Image:Collective_Frankenstein%2C_9th_Aug_2038.png|thumb|center|2038]]
|-
|-
|[[Image:Collective_Frankenstein%2C_6th_Jan_2058.png|thumb|center|2058]]
|-
|}
Sorry for the uneven spacing of the years, couldn't find an intermittent saves...

[[Category:History]]

Two-way end of line

2013-12-04T10:16:33Z

Benny: typo

=== Two-way end of line ===
''Two-way end of line'' is a setting in OpenTTD that can be altered to create interesting train behaviour. By default it is off, but it is activated on every openttdcoop server.
A red two-way signal directs train to a different route if one is available.

''While used in combination with the default YAPF pathfinder, two-way signals have a weird and often misunderstood property. This property, called rail_firstred_twoway_eol, means that if the first encountered signal is a red two-way, that signal is considered a dead end. Now to understand the impact of this, one must first understand the basics of YAPF. In a nutshell: YAPF calculates all possible routes, called paths, from the train's current position. Each path is evaluated to a single score, determined by the length of the path, obstacles like stations, roads and hills, and upcoming red signals and ofcourse the ability to reach the destination (station). The train then chooses the path with the lowest penalty score.

Consider the train is on a junction and has multiple exit possibilities. The issue with red two-way signals is that if the first signal on a path is a red two-way, that path is not evaluated at all as it is considered a dead end. You could say that the path gets a penalty score of infinity. This also means that any other possible path, if it exists, is automatically better than the two-way path. Even if the other possibility is a trivial, detouring or outright useless path.
What this means in practice is:
* If all possible paths start with red two-way signals, the paths are considered equal and a choice is made without considering the network after the signals.
* If there is a single path not starting with a red two-way signal, that path is automatically chosen without considering the usefulness of the path itself.
Most important is that a choice is made without looking ahead at all. This includes checking if the chosen path actually leads to the desired destination. This can cause massive problems in our games, with games detouring or even driving themselves into a station or actual dead end.

Now is the EOL property a setting that can be changed. However, on our servers it is always on, as it gives trains the ability of free choice. If two different paths share a destination, but are considered by the pathfinder to be very unequal penaltywise, with single signals a train might decide to take the path with the lowest penalty, even though that means waiting for a red light. With two-way signals this will never happen.

In short:
* Only use two-way signals when you understand their workings and use. Otherwise, use single signals.
* Only use two-way signals in situations where each path has the same destination but a possibly very unequal penalty, and where it is important for the train to make an indiscriminant choice. You can think of mergers and SLH joins. But please remember that you don't always have to use them. If you can avoid them, do so.
* Especially avoid two-way signals when not all of the exits are two-way, and not all paths lead to the same place. The most common error is combining a double bridging of a mainline with the exit of a track.
* The exception is ofcourse for track that actually has to be two-way, like the signals next to platforms in terminus stations.
* Two-way signals can also legitimately be used in logic systems and the creation of priorities.''

=== Pathfinder trap ===
The most use of this setting is found in our [[SRNW]] games, we control trains to either take an exit to the sideline or stay on the mainline. We also combine this signal with a certain station or shortcut to create pathfinder traps. Pathfinder traps give us options to trick trains, we can decrease the pathfinder penalties to an actual station and so create more balanced traffic or we can balance mainline mergers. There are occasions where the inner lane is preferred so much we will create a shortcut from each lane to the inner lane after a merger. We disable an exit with the pathfinder trap so the trains will not actually take this path and a merger gives us a balanced output.
{| align="center"
|| [[File:Pftrap.png|300px|thumb|center|Pathfinder trap in its raw form.]]
|| [[File:Pftraponmainline.png|300px|thumb|center|Pathfinder trap on mainline to create a shortcut that can never be used.]]
|}
=== Station with overflow ===
In our games we often use overflows and this setting can help us create easy to implement overflows for our primaries. One example of this is found in the picture below.

{| align="right"
|| [[File:Overflow primary.png|300px|thumb|center|Overflow on the a primary with reverser arrows.]]
|| [[File:TerminusPrimary.png|300px|thumb|right|Arrows on a primary station]]
|}

In the picture you can see the “ arrow” in the reverser. It is not eye-candy it actually has a use. The pathfinder sees that the other tracks are blocked and considers the reverser only a viable line if it has at least 2 options. This means we create a split in the reverser so the pathfinder thinks it has two options.

Similarly we advise you to also use this arrow on every reverser, and in every terminus station with pre-signals at the final X as seen in picture below. In theory only the track that has a straight line to the exit track should have one, but we still prefer using them on all platforms for a terminus station.

=== Setting up two-way end of line ===
To setup this behaviour in your own game you can do this in two ways: We at openttdcoop prefer you use the second way because it is permanent, stable and easier.

*Either in game trough the console command accessible with the “~” key. Follow this by sending the following command:
“set yapf.rail_firstred_twoway_eol 1”
*The second way of changing this setting is by editing your openttd config file. And please do this when the game is closed. The location of this file is a question Google has an answer to. In here you find the line “yapf.rail_firstred_twoway_eol = false” and change it to “yapf.rail_firstred_twoway_eol = true” Follow this by saving and closing the config file.

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

Tilelength

2013-12-04T10:16:01Z

Benny: Added to basic networking category

==Introduction==
Whenever starting a new game, one of the first settings to be chosen is the used tilelength for your trains. This length can vary from supersmall trains with only three carriages (which would be tilelength 2) to huge mammoth trains with more than 20 carriages, which would make a tilelength greater than 10...

==Why Odd Tilelengths are better than Even Ones==
[[Image:Comparison_of_Tilelengths.png|thumb|300px|Comparison of TLs 3; 3,5; 4; 4,5 and 5]]
Most people probably play with the Patch-Option "When Dragging, place Signals every: X Tiles" set to 2, accordingly there will always be one tile with a [[signal]] on it, one without one, one with a signal and so on. In #openttdcoop games, this is an undiscussed standard. As we do not want to change this setting, we should see how we can fit the tilelength of our trains to it. A common situation is that one or more trains are waiting before a station which is currently full. Those waiting trains could jam back until the [[mainline]] of our network and block it. The jammed part of the mainline would jam too and block other parts of the mainline, until the mess is complete. To avoid a situation like this, you can take various measures like expanding the jammed station or the waiting space before it. But just by choosing an odd tilelength, you can already ease the situation.

[[Image:Diagonal_Comparison_of_Tilelengths.png|thumb|left|346px|Comparison of different Tilelengths on diagonal track]]

If you look at the picture to the right, you will see that with "Place signals every 2 Tiles", trains with different tilelengths use the given space quite differently. While the trains with "natural odd" Tilelengths (3 and 5) have almost no space between them, the trains with other Tilelengths such as 3,5; 4 or 4,5 have quite some space between them - space which could be used more efficiently! However, to achieve that, you would have to place a signal each 5 tiles (with the example of Tilelength 4), which you can't do with the patch-setting of "Place signals every 2 Tiles", you would have to set this setting to either 5 or 1, both are not very satisfying solutions.

However, this applies for straight tracks, if you look at diagonal tracks, the situation is almost the same. Here the trains with Tilelengths of 3,5 or 5,5 or 7,5... fit perfectly, while with TL 3 or 5 you have small gaps. Those are, however, still a lot smaller than those with TL 2 or 4 or 6.

---

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

Presignal Basics

2013-12-04T10:14:52Z

Benny: Added to basic networking category

[[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Oneway_or_Twoway_Presignals|Oneway or Twoway Presignals >>]]
----

=<center>Presignal Basics</center>=
The Presignal Basics is explained here: how they work, how they behave, and how does work a terminal station, and whats the use of the combo presignal.

==Part 1: Identify the signals==
There are six types of signals in OTTD. If you click on a normal signal with CTRL is held, these signals will appear:

'''Normal Signal''': It does not have any special alibity, it turns to red if the next signal block is blocked by any train.

'''Entry Presignal''': It works like a normal signal, plus it turns to red if all exit presignals, or combo presignals are red after it.

'''Exit Presignal''': It works same as normal signal, but it signs for the entry, or combo signals, if self is red.

'''Combo Presignal''': It has both Entry and Exit presignal alibities: It turns to red if all Exit/Combo are red after it, and it signs for the Entry/Combo Presignals, if the self is red.

'''PBS Signal ''': Not a Presignal, it enables more trains in one signal block, since PBS means Path Based Signaling. This type of signal is not explained here.

'''One-Way PBS Signal ''': It works like a PBS Signal, however, it prohibits passing through from the back side. This type of signal is not explained here.

[[Image:Signals_revised.png|thumb|center|388px|Different signal types]]

==Part 2: The Station Problem==
Stations without any presignals have a big problem: just have a look on the Image to the below. Signal A should be red...[[Image:Terminal1.png|270px|center|thumb|Problem at stations without Presignals]]
If you let one more train to enter into the station, it will block the exit, because A signal is green. This problem is solvable with presignals: Just turn A into Entry presignal, and turn B and C signals to exit signals. [[Image:Terminal2.png|276px|center|thumb|Station with Presignals]] How does it work? If Exit Presignals B, C are both red, then Entry Presignal A is red too. Then a third train cannot pass trough Signal A.

==Part 3: An Effective RoRo station==
Combo Presignals are mostly placed between Entry, and Exit presignals, because the Combo Presignals transmits the Exit presignal signs for the Entry Presignals. Combo presignals behave as an entry presignal and an exit presignal both.[[Image:RORO1.png|center|thumb|526px|RORO station]] In the Image above, signal A is Entry Presignal, signals B, C, D, E are Combo ones, and F-K are Exit Presignals.

If F and G Platforms are used, then Combo signal B uses its Entry Presignal alibity, and it will turn to red, because F, and G Exit Presignals are both red. But the Entry Presignal A is remains green. Exit presignals H-K are green, then Combo Presignals D, E is green, then Signal C is green too. With this Combo Presignal B is red and C is green, then the Entry Presignal A is remains green.[[Image:RORO2.png|center|thumb|526px|The Entry remains green]]

The Entry Presignal A will be red only, if all Platforms are used, Exit Presignals F-K are red. If F-K are red, then all Combo Presignals B-E are red too, then the Entry A will be red.[[Image:RORO3.png|center|thumb|520px|All Platforms red]]

----
[[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Oneway_or_Twoway_Presignals|Oneway or Twoway Presignals >>]]
[[Category:Guides]]
[[Category:Basic networking]]

File:Frankenstein Hub.png

2013-12-04T10:13:14Z

Benny: Added to history category

The one and only Frankenstein Hub.

[[Category:History]]

File:Bermuda.png

2013-12-04T10:13:00Z

Benny: Added to history category

Good Old Bermuda Hub.

[[Category:History]]

Crazy Hubs

2013-12-04T10:12:40Z

Benny: Added to history category

{{obsolete||Junctionary}}

==NOTE==

These are some of the most unique and memorable hubs we've built. However, you shouldn't take them to heart. They may have been ok at the time, but don't attempt to repeat them, they're not here for that. Instead they're here to show our, er, genius (madness anyone?) to everyone. Again, these are not the normal and appear very rarely, but when hubs like these do evolve, we remember them... They're infamous to say the least.

==List of Crazy Hubs==

*[[:Image:Bermuda.png|Bermuda Hub]]
*[[:Image:jpu.png|Just Plain Ugly (JPU)]]
*[[:Image:Frankenstein_Hub.png|Frankenstein Hub]]

[[Category:History]]

Guides:Advanced Signals

2013-12-04T10:11:45Z

Benny: Marked for deletion

{{obsolete}}
{{delete|Old, outdated term and we already have a PBS article}}

=Introduction to Advanced Signals=

Advanced signals, also known as path-based signals, allow the creation of segments of track that behave much differently than was possible before. As such, here is a tutorial to the proper use of this type of signals. Although advanced signals are very powerful, their misuse can lead to jammed networks. Even using advanced signals the way you would use regular signals is incorrect.

==What Advanced Signals Are==

Advanced signals cause trains to reserve a path through the block before entering. As long as their reserved paths do not intersect, multiple trains can enter a block with advanced signals at the same time. This can lead to much more compact signaling than was possible, while maintaining efficiency.

[[Image:Pbs-example.png|thumb|center||Multiple trains in an advanced signal block]]

==What Advanced Signals Are Not==

Advanced signals are not an excuse for you to join before split, or for you to join '''during''' split, as is very easy to do with their basic structure. Always remember that the principle of track management is to join tracks '''after''' splitting.

'''Never''' place a regular signal or an advanced signal facing the same direction at the exit of an advanced signal block. Trains can wait at any signal facing them, blocking the whole signal area. You must leave a gap of the train length after any advanced signal block.

=Track Switchover=

The simplest use of advanced signals is to create a track switchover, allowing trains coming from two inputs to leave at either of two outputs.

[[Image:Pbs-simple-crossover.png|thumb|center||Simple track switchover]]

In the example above, trains entering at either A or B can pass to either exit, A' or B'. A train can pass from A to A' at the same time that another train is passing from B to B'. However, if a train is moving from A to B' or from B to A', any train on the other track must wait. This leads to the most important consideration of this switchover: only use it if almost all the trains will proceed straight through without switching tracks. As always, leave a gap at the end of the block to allow trains to clear the intersection.

=Terminus Station=

One nice use of advanced signals is to create a slightly more efficient terminus station. In some circumstances trains can enter and exit at the same time. It is a marginal improvement over the standard presignaled terminus, but an improvement nonetheless. See below for the proper implementation.

[[Image:Pbs-terminus.png|thumb|center||A terminus station using advanced signals]]

=Multiple-input Ro-Ro Stations=

Another application of advanced signals is to design a quick-and-dirty multiple-input station. Simply drop one-way advanced signals at the front of each entrance to the tracks, and run criss-cross tracks to each station platform. Please note that this is no replacement for a properly designed and implemented solution like a decent mix-o. Efforts to use advanced signals in a mix-o station are still under development.

[[Image:Pbs-multi-in.png|thumb|center||A simple multiple-input ro-ro station]]

[[Category:Guides]]

Category:History

2013-12-04T10:10:34Z

Benny: Created category

Articles that are kept only because of historical purposes.

These articles shouldn't really be updated, but rather be used to see how openttdcoop has changed over the years.

Flat Hubs

2013-12-04T10:09:16Z

Benny: Added to history category

{{obsolete}}

[[Image:Ghetto_hub.png|thumb|right|The Original]]
Ghetto Style Hubs, are not a recommended hub design. However, they are useful in certain situations...
* When you don't have a lot of money (in the beginning of a game for a [[cashmaker]])
* You need a quick hub
* You're short on space
* You need a temporary hub
* All of the above
It should be noted, that Ghetto Style Hubs are very prone to jamming, and should be used in low traffic situations only. The original Ghetto Style Hub is shown on the right. It was used in the 1950s of the [[Collective Transport]] game, and is something that is pretty much unique to #OpenTTDCoop.

[[Category:History]]

Dodging unremovables

2013-12-04T10:08:36Z

Benny: Added to basic networking category

When building Line's it's unavoidable that you will encounter at some point an Un-Removable object such as an Antenna. There are multiple ways to avoid these and some are more effective than others. Here are a few examples:

== Going Around ==

Going around is a simple and efficient way as long as the line is not too wide and the turns aren't too short. The curve around must be wide enough that trains do not slow down from encountering a tight turn, we call this curve length, or CL for short. The curve must also not force trains to change direction more than two times in the train length, or TL for short. Here is an example of a track curving around a transmitter antenna:

[[Image:dodge-around.png]]

== Going under ==

Going under is just as simple. Dig 2 hole's and place tunnels. Of course tunnels can't be signaled so for busy line's Multiple tunnels for every track could be required. Here is an example of a track using double tunnels to go under a power station, notice the track is offset on either side so the path through either tunnel is the same length, 7 straight tiles and two diagonal:

[[Image:dodge-under.png]]

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

Basic Junctions

2013-12-04T10:08:09Z

Benny: Added to basic networking category

[[Sideline_stations|<< Sideline stations]] | [[Guides:Building|^^ Back to Building Guides Index]] | [[Mainline_Junctions|Mainline Junctions >>]]
----

In this part we build our first basic junction (in #openttdcoop we always call it "hub"). Since we always build multi-track-junctions, a junction is a bit more complicated than you may have done it before. We try to build ''efficient'' and ''fast'' railways and therefore we need ''efficient'' and ''fast'' junctions as well. For the start we will analyse a so-called [[Sideline_Hub|Sideline Hub]] - or '''SLH''' for short.

[[Image:BasicJuntions1.png|center|thumb|600px|A very basic [[Sideline_Hub|Sideline Hub]] - Note the lack of [[Balancing|load balancing]] ]]

We find several important things in the image above:
* A [[Basic_Networking|'''mainline''']] (also known as "Axis") goes from south to north (you can find it quite easy, mainlines have at least two tracks in each direction). The '''SLH''' has to connect a sideline to a mainline. This is the simplest case of a hub in our games. It is usually called '''"T-Hub"''' (just lean your head right and you will notice why).
* There are no [[Balancing|load balancers]] constructed for trains coming from the Sideline and entering the Mainline. The Loadbalancers will be explained later on.
* [[priorities|Priorities]] are missing on the mainline, so that trains entering the mainline slow down the trains on the mainline.
* Tunnels/ bridges are not doubled. Doubling is done based upon traffic load once a tunnel or bridge shows slowdowns for trains then it is needed to double. Unless it is a mainline or the tunnels/ bridges are longer then the distance between trains.

[[Image:BasicJuntions2.png|center|thumb|480px|An early [[Balancing|Loadbalancer]] - recent concepts are far better but this one already improves the balancing somewhat]]

On the image above, you see the idea of the balancing: if a Mainline-track is used (which means: a train is on the part the Sideline-Train wants to enter) the signal state is red - and the Sideline-Train chooses the other Mainline-track. A basic [[priorities|priority]] is used to accomplish this.

But for now, let us come back to our topic - basic junctions.I know what you are thinking: "Why are they doing these weird things?". The answer is: because it is the simplest thing in the end. Make a clean and intelligent building right from the start - it saves you and others later on.

Just imagine a game with 300+ trains and 100+ stations and every station has its own connection to a mainline with high traffic. All these entering/leaving trains will slow down other trains - it's some kind of chain reaction. [[Sideline_Hub|'''SLH's''']] are intended to be ''fast connection points'' from sidelines to mainlines. Traffic from stations are bundled to sidelines and via a SLH they are bundled to a massive mainline. This - in the end - ensures a fast and comprehensive network!

'''Name the HUB'''<br>
Every hub has a [[Naming_conventions|name]]! Not only because we are gifted writers but also because of finding all these hubs in the future. On a typical 512x512 map we end up with at least four "Backbone Hubs" (explained later on) and at least eight or even more Sideline Hubs.

[[Image:BasicJuntions3.png|center|thumb|357px|The signlist - click on a sign and you will get to the spot]]

Since #openttdcoop has something to deal with both communication and coordination it has proven that "Look at SLH 3" is easier to communicate rather than "Look at this hub east to the hub which is west of the eastern one". This ought to be obvious.

'''Things to keep in mind while constructing'''
* '''Close signaling!''' Always place signals as close as possible to a track split. This prevents unnecessary red-signal-times when a train passes a split.
[[Image:BasicJunction4.png|right|thumb|199px|The signals set as close as possible]]
* '''Think big!''' Our trains have a certain length (depending on the current game). If it is too long to enter a Sideline it therefore blocks not only the Sideline itself but also the Mainline. On a good junction the Sideline-entry is long enough for one whole train to wait.
* '''You can get from each direction to any other direction!''' Since we want to make our railline expandable, we don't want to rethink all the old hubs in the future. It is better to build a hub with as many features as possible right at the start rather than heaving a headache in the future.
* '''A clean building style!''' You are not at your own - and this is probably the best thing about #openttdcoop! Unfortunately, most of us can't read your mind and therefore it is best to make a clean building style everyone understands. To be more concrete: don't do unnecessary tracks, make comments (by using signs) of your ideas. Signs do not cost anything at all - except some pressed keys on your keyboard.
* '''Curve Radius'''. Depending on the game, we use a certain trainlength. Imaging a map with 3-tile-long-trains. This means: If you build curves with 3 tiles length each, the trains won't slow down! For monorail or maglev it's very important to remain at full speed. Just ask some experts around for the minimum radius for full [[Max_Curve_Speed|speed-curves]]. ''Note: for larger trainlengths, the radius is always smaller than the trainlength.''

[[Image:BasicJunction5.png|center|thumb|650px|Different trainlengths afford different curve radiuses for full speed]]

* Finally, one thing is left to say: '''the Mainline always has the highest priority!''' Keep this in your mind for the next chapters!

----
[[Sideline_stations|<< Sideline stations]] | [[Guides:Building|^^ Back to Building Guides Index]] | [[Mainline_Junctions|Mainline Junctions >>]]
[[Category:Guides]]
[[Category:Basic networking]]

Moneymaker

2013-12-04T10:06:47Z

Benny: Removed guides links

Moneymaker is the transport infrastructure built during the [[planning]] phase of a [[Public Server]] game to provide early-game income. Makeshift train networks were mostly used for this traditionally, but have since been replaced by airplanes. An exeption to this is games where the starting date does not allow for planes, making the plane approach impossible.

=== Moneymaker using trains ===

In previous games, we booted games using trains. It remains here as documentation for games where the starting year doesn't allow building airplanes.

[[Game Start with Trains]]

=== Moneymaker using airplanes ===

The new and current approach to boot games in #openttdcoop is to use airplanes. It's the recommended way to boot a game.

[[Game Start with Airplanes]]

==History==
In the earlier days of Openttdcoop, unorganized short-term train networks were built as a moneymaker. Coal was typically the cargo of choice because of its tolerability to delays and generally high payment rates. Very few terrain-changes were made and the tracks kept relatively simple to save money. Hubs were typically quick-and-dirty (see [[Ghetto Style Hubs]]), and general building codes often overlooked for the sake of simplicity.

[[Category:Guides]]

Dodging unremovables

2013-12-04T10:02:25Z

Benny: Removed guides links

Removing a city

2013-12-04T10:01:43Z

Benny: Removed guides links

Sometimes when building the main line, side line or a station you come across some towns. Sometimes you have to remove them so there is more room for our networks. (Please note that this isn't cheap and only perform this when there enough money. Otherwise place a sign and wait until there is more money).

Removing is done in several steps:

==== Removing the first buildings ====
First check the rating of the authorities of the town. If it's '''Very Good''' or better start with removing some buildings like a football station, church or offices. These all need a rating of Very good or better. Removing a simple houses will be done later. Repeat the process until the rating drops to '''Appaling''', then move on to the next step.

If you don't know which kind of building everything is, use the "Land area information tool". It's the last button in the topside buttons bar (with pause, settings, save, map etc.). If you still don't know if a building can only be removed with Very good rating or higher start with the buildings that look the most expensive.

==== Planting trees ====
You've been removing quite a bit and your rating has dropped to Appaling and local authorities will not allow further demolition. It's time to raise the town rating.
Remove everything in between a range of about 10 to 20 tiles from the town center (mind any laid out tracks, stations or purchased land). When you've removed everything from these tiles plant trees on the bare tiles. Just one tree per tile is enough (only drag and drop once). Repeat this until you have reached a '''Good''' or higher town rating and continue with the next step. Do not use the bribe option, which is expensive and will lead to being discovered and an unwilling town.

==== Removing some (cheap) buildings ====
Now that your rating is increased to '''Good''' or better it is again time to remove buildings and roads. Start with removing houses at first and when that is not possible anymore try removing some roads. It appears that you can demolish up to 7/ 8 road pieces or 2 houses + 1 road tile at a time. When the town rating has dropped to '''Appaling''' again repeat the tree planting step. Do so until there are only buildings left that can't be removed (statues for instance).

==== Removing the last buildings ====
If it wasn't a very big town, the result you have now must be only a few buildings left. Now it's time for the expensive part: '''Bribing'''. To save money, make sure your rating now is '''Good''' and if it is not the case plant some trees. Bribe to get an excellent or outstanding rating and remove the final buildings. If your ratings has dropped again try to increase it first by planting trees otherwise attempt another bribe. Now the town is removed completely. If town growth is turned on purchase the tiles around the center to prevent future growth, a rectangle of 10 by 10 tiles will do.

[[Category:Guides]]