#openttdcoop wiki - User contributions [en]

Guides:Glossary

2010-06-11T20:35:04Z

OwenS: Add destructive interference (Todo: Should this not be a category?)

__NOTOC__
The Glossary contains definitions for all words used in cooperative games

===A===
*[[Mainline|Axis]]

===B===

*[[Backbone Hub|Backbone Hub (BBH)]]
===C===

*[[Cashmaker|Cashmaker]]
*[[City_grow_guide|City growth guide]]
*[[Coop_Index|Coop Index]]
*[[Copy orders|Copy Orders]]

===D===
*[[Destructive Interference]]

===E===
*[[Destructive Interference|Evil Mode]] (Synonym)

===G===

*[[Ghetto Style Hubs|Ghetto Style Hub]]
*[[GRF|GRF]]

===H===

*[[Hub|Hub]]

===I===

*[[IRC|IRC]]
*[[IRC Highlighting|IRC Highlighting]]
*[[IRC Commands|IRC Channel Commands]]

===J===
*[[Jargon]] (more words used for communications)
===L===

*[[Line hierarchy]]
*[[Loadbalancer|Loadbalancer]]
*[[Load Balancing|Level Balancing]]

===M===

*[[Mainline|Mainline (ML)]]
*[[Mergers|Mainline Mergers]]
*[[Moneymaker|Moneymaker (MM)]]

===N===

*[[Naming_conventions|Naming Conventions]]

===P===

*[[Pax|Pax]]
*[[Priorities|Priority Line]]
*[[PBS]]

===R===
*[[RBC|Round Based Coop (RBC)]]

===S===

*[[Server_Administration|Server Administration]]
*[[Shared Orders|Shared Orders]]
*[[Sideline|Sideline]]
*[[Sideline Hub|Sideline Hub (SLH)]]
*[[SML|Shift Mainline (SML)]]
*[[SRO|Self Regulating Orders (SRO)]]
*[[Destructive Interference|Slow Mode]] (Synonym)

===T===

*[[Terminus_Station | Terminus Station]]
*[[Terraforming|Terraforming]]
*[[Teamspeak|ts / Teamspeak]]

===Y===

*[[YAPP]]

===W===
*[[WWOTTDGD|World Wide OpenTTD Game Day]]

Destructive Interference

2010-06-06T23:19:22Z

OwenS: /* Solution */ Elaborate on pessimism

''Destructive Interference'' describes the situation where trains exiting a double-bridge or tunnel interfere with each other's progression in a manner destructive to their throughput. It is also referred to as ''Slow mode'' or ''Evil mode''

= Overview =
[[File:Destructive1.png|center]]

The above picture shows a number of typical double bridges and tunnels. There is nothing wrong with them; they are our standard way of dealing with the inability to place signals on bridges or inside of tunnels.

However, there is an issue whenever we use multiple bridges or tunnels in order to handle the traffic of one line; namely, that they must eventually be merged together. At the merging point, a situation can occur where the two tracks each release a train in turn from a stand still, and these trains then proceed to destructively interfere with each other. This requires, of course, that the track leaving the merge is temporarily blocked.

Once destructive interference starts, the chain of events is quite simple:
* One track releases a train from standstill.
* Another train arrives at the merge just before the first train clears it. It is forced to stop.
* The second train is released from standstill
* Another train arrives at the merge from the first track just before the second train clears it. It is also forced to stop.

As can be seen, as long as traffic is sufficiently high, destructive interference can continue indefinitely.

= Contributing Factors =
The following factors, while not causing the occurrence of destructive interference outright, strongly increase its probability and/or longevity
* Proximity to merges (Particularly priority-less merges or those prioritized against the bridged track) or other situations which can cause the output line to become blocked
* Long bridges - in particular, those 1.5x the train length or longer
* High train holding capacity within the doubled system - approximately two or three trains per track or higher

Situations involving only one of these rarely exhibit symptoms; those involving two do only occasionally. Those involving three or more do regularly, particularly under high load.

= Solution =
There is no perfect solution. That which does exist has side effects. However, it is mercifully simple, and in practice works quite well.
[[File:Destructive2.png|center]]

The above picture modifies the central double bridge in order to prevent destructive interference from beginning. What has been done?
* One track off the bridge has been given priority
* A signal has been removed so that the priority has sufficient look-ahead.

The fix works by allowing one of the tracks to empty at full speed, rather than causing both tracks to slow to a crawl.

Some important considerations:
* The prio lookahead length is crucial. It must be ensured that trains entering the double bridge system cannot continually block the de-prioritized track, as this will cause the system to effectively revert to being a single bridge. '''In particular, the lookahead cannot exceed the length of the longest bridge in the system.'''
* The experimentally observed ideal prio length is two tiles, that is, an exit signal, one empty track tile, normal signal.

As mentioned, this fix is not without a side effect: any blockages will cause the deprioritized track to lose synchronization with the prioritized track and queue until there is a sufficient gap for it to join without blocking the prioritized track. In particular, this fix is pessimistic about whether a train can join without blocking the prioritized track, and this pessimism grows with the length of the lookahead.

Not all situations require this fix. In particular, those without contributing factors probably do not. '''If in doubt, don't apply it.''' This is doubly good advice as, if destructive interference becomes a problem, the fix is rather trivial to apply

Destructive Interference

2010-06-06T23:17:55Z

OwenS: Created page with '''Destructive Interference'' describes the situation where trains exiting a double-bridge or tunnel interfere with each other's progression in a manner destructive to their throu…'

''Destructive Interference'' describes the situation where trains exiting a double-bridge or tunnel interfere with each other's progression in a manner destructive to their throughput. It is also referred to as ''Slow mode'' or ''Evil mode''

= Overview =
[[File:Destructive1.png|center]]

The above picture shows a number of typical double bridges and tunnels. There is nothing wrong with them; they are our standard way of dealing with the inability to place signals on bridges or inside of tunnels.

However, there is an issue whenever we use multiple bridges or tunnels in order to handle the traffic of one line; namely, that they must eventually be merged together. At the merging point, a situation can occur where the two tracks each release a train in turn from a stand still, and these trains then proceed to destructively interfere with each other. This requires, of course, that the track leaving the merge is temporarily blocked.

Once destructive interference starts, the chain of events is quite simple:
* One track releases a train from standstill.
* Another train arrives at the merge just before the first train clears it. It is forced to stop.
* The second train is released from standstill
* Another train arrives at the merge from the first track just before the second train clears it. It is also forced to stop.

As can be seen, as long as traffic is sufficiently high, destructive interference can continue indefinitely.

= Contributing Factors =
The following factors, while not causing the occurrence of destructive interference outright, strongly increase its probability and/or longevity
* Proximity to merges (Particularly priority-less merges or those prioritized against the bridged track) or other situations which can cause the output line to become blocked
* Long bridges - in particular, those 1.5x the train length or longer
* High train holding capacity within the doubled system - approximately two or three trains per track or higher

Situations involving only one of these rarely exhibit symptoms; those involving two do only occasionally. Those involving three or more do regularly, particularly under high load.

= Solution =
There is no perfect solution. That which does exist has side effects. However, it is mercifully simple, and in practice works quite well.
[[File:Destructive2.png|center]]

The above picture modifies the central double bridge in order to prevent destructive interference from beginning. What has been done?
* One track off the bridge has been given priority
* A signal has been removed so that the priority has sufficient look-ahead.

The fix works by allowing one of the tracks to empty at full speed, rather than causing both tracks to slow to a crawl.

Some important considerations:
* The prio lookahead length is crucial. It must be ensured that trains entering the double bridge system cannot continually block the de-prioritized track, as this will cause the system to effectively revert to being a single bridge. '''In particular, the lookahead cannot exceed the length of the longest bridge in the system.'''
* The experimentally observed ideal prio length is two tiles, that is, an exit signal, one empty track tile, normal signal.

As mentioned, this fix is not without a side effect: any blockages will cause the deprioritized track to lose synchronization with the prioritized track and queue until there is a sufficient gap for it to join without blocking the prioritized track. In particular, this fix is pessimistic about whether a train can join without blocking the prioritized track.

Not all situations require this fix. In particular, those without contributing factors probably do not. '''If in doubt, don't apply it.''' This is doubly good advice as, if destructive interference becomes a problem, the fix is rather trivial to apply

File:Destructive2.png

2010-06-06T23:10:50Z

OwenS: uploaded a new version of "File:Destructive2.png": Bugfixed the junction

How to fix destructive interference

File:Destructive2.png

2010-06-06T22:44:02Z

OwenS: How to fix destructive interference

How to fix destructive interference

File:Destructive1.png

2010-06-06T22:26:24Z

OwenS: uploaded a new version of "File:Destructive1.png": Remove chat! Grr!

2007-06-09T00:42:36Z

OwenS: Did some rewording

2006-08-07T23:10:12Z

OwenS:

Template:R&D content

2006-08-07T23:08:08Z

OwenS:

! align="left" |{{{1}}}
!{{{2}}}
!class="{{{3}}}" | {{{4}}}
!class="{{{5}}}" | {{{6}}}
!class="{{{7}}}" | {{{8}}}
!class="{{{10}}}" | {{{9}}}
|-

LBR Mainlines

2006-08-07T23:06:48Z

OwenS:

''by [[User:OwenS|OwenS]]

== Overview ==
LBR Mainlines are arranged in a 3x1 configuration, of:

Left | Bidirectional | Right

'''Current stage: ''' Examination - Watch traffic on the first live test track
'''Pros:'''
* Takes up less track than an LL_RR mainline and can be compressed more
* Downgrades to LR more easily where needed
* Allows both over and undertaking
* Relatively easy to upgrade to LL_RR in future (Although the junction limitations remain)

'''Cons:'''
* More complex signalling
* Lower capacity than LL_RR
* Junction positions are restricted

'''Minimum width:''' 5 tiles: Primarily (L__B__R), Connectors (L_L_R_R)

{{R&D_header|R&D Overview}}
{{R&D_content|LBR Mainlines|[[User:OwenS|OwenS]]|checked|Done|checked|Done|checked|Done||checked|Suitable and works well for moderate traffic}}
{{R&D_content|L_L_R_R Overtaking Mainlines|[[User:OwenS|OwenS]]|checked|Done|checked|Done|checked|Done|checked|Works well for high volumes of traffic}}
{{R&D_content|Multi speed trains with LBR and L_L_R_R Mainlines|[[User:OwenS|OwenS]]|checked|Done|checked|Done|checked|Done|checked|Works well with closely spaced overtaking points}}
{{R&D_footer}}

== Initial Observation Log ==
=== 29th July 2006 ===
With some signalling tweaks, trains are using it to overtake. They are also, however, using it to cut corners. Cheeky trains....
We do not have enough traffic to determine it it's complexity and additional size will pay off.

Also, I am adding a new peice of work to go with this: Determine if, using the LBR system, it is possible to run differing speed trains on the same network without aversely affecting the faster train's speed. Currently, we have several different speed locomotive sets:
* ICE-3: Fastest
* ICE-1: Seccond fastest (Used to GOB, since it was originally ''just'' the town drop)
* BR182: Electrified freighter
* ICE-TD: To TNT, which isn't electrified
* DE-AC33C: For non-electrified freight

Currently, there are no noticable problems with this configuration.

We have also developed the first junction for this design.

=== Final observation ===
This system did allow overtaking, but some things should be specially noted:
* Closer diverging points should exist, since trains can wait a while or stop
* L_L_R_R should be done and is easily possible in busy points of the network
* LBR (L__B__R) is easily upgradable to L_L_R_R when there isn't stuff in the way

Overall, it allowed a higher volume of traffic than a normal LR mainline would have handled. It in comparison to an LL_RR mainline has not been done; However it could be assumed that with well designed junctions it would be similar
[[Category:Research]]

Advanced joiners

2006-08-02T12:31:37Z

OwenS: Advanced joiners moved to R&D:Advanced joiners

''by [[User:XeryusTC|XeryusTC]]
== Overview ==
Advanced joiners are joiners that are more complex then the regular joiners used. The regular joiners are 2 to 1, 3 to 2 or 4 to 2, those are commonly used in our games. The advanced joiners on the other hand aren't regulary used, it is even possible that they are designed for a specific situation. The advanced joiners can also be based on the regular joiners but have additions or the regular joiners are just a small part of the entire joiner.

== The joiners ==
=== 5 to 4 way joiner, completely choosable A.K.A. Hugeass joiner ===
''by [[User:XeryusTC|XeryusTC]]

[[Image:5-to-4---fully-choosable.png|thumb|right|200px|The joiner concept]]
[[Image:5-to-4-finished.png|thumb|right|200px|The current implementation in the network]]
It was originally meant as a joiner right after a BackBone Hub and infront of a principle station, this makes it use quite limited, except from using it at a SideLine Hub in one-way networks. You can see the use of bouncers (the "BOUNCE" sign), this is because trains from the line the bouncers are in wanted to take the route with the bouncers, but that caused a high load on the western lanes and it jammed from time to time.

'''Pros:'''
* Trains can get from everywhere to everywhere.
* Can be devided into multiple parts so it can be addapted to the landscape easier.
* Trains can come from a few different directions.

'''Cons:'''
* Merge before split.
* Very big.
* It can only be used in big mainlines or for a principle station which has a drop and a pickup station.
* It is designed to be used in only a specific game, but it can be adapted to other games.

[[Category:R&D]]

Openttdcoop News

2006-08-01T18:14:23Z

OwenS: s/Februar/Feburary

<noinclude>== Latest News ==</noinclude>
'''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!

'''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!

<noinclude>
== July 2006 ==
'''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>

LBR Mainlines

2006-07-30T15:27:41Z

OwenS:

LBR Mainlines

2006-07-29T21:50:19Z

OwenS:

LBR Mainlines

2006-07-29T21:49:44Z

OwenS:

Template:R&D-Head

2006-07-29T21:45:44Z

OwenS:

<center>
<table border="1">
<tr><th colspan='6'>'''R&D Overview'''</th></tr>
<tr><th>Idea</th><th>Player</th><th>Draft of idea</th><th>Testing</th><th>Completed</th><th>Remarks</th></tr>
{{{1}}}
</table>
</center>

2006-07-29T21:38:57Z

OwenS: /* = 29th July 2006 */

2006-07-24T18:18:27Z

OwenS:

'''Born:''' gettimeofday();
'''Home:''' /mnt/nfs/neuk/home/oshepherd
'''Email:''' owen dot shepherd at humgun dot com
'''Started playing TTD:''' Sometime 2004 I think?
'''Joined #openttdcoop:''' May - June 06, I forgot which
'''Specialist on:''' Towns & Station exits
'''Prefers:''' ICE & S-Bahn or high capacity main stations