#openttdcoop wiki - User contributions [en]

File:Grundinghead Cross Transport, 10th Nov 1981.png

2008-08-27T10:35:57Z

BenTotterdell: Bow Tie

Bow Tie

Shift Mainlines

2008-07-17T20:45:28Z

BenTotterdell: Add on for Sophisticated situation switcher

==Shift Mainline Premise==
''By [[user:Phazorx|PhazorX]], written up by [[user:OwenS|OwenS]], this is a development from the concept LBR mainlines''
[[Image:Shift_Mainline.png|thumb|right|200px|Design of a junction]]

Shift Mainlines is a ML concept which removes much of the complexity of building junctions on a traditional mainline. Shift ML hubs require only that trains are injected into the outermost lanes. The design described here causes YAPF to prefer the inner lanes for trains on the ML. As such, if the inner lane is free, then YAPF will cause the train to shift inwards.

Trains in the second innermost lane are shifted into the innermost lane first, to ensure trains in the outer lanes get a chance to shift into the inner lanes. This is repeated outward for as many lanes as exist. The outer lane should now be mostly free, which should result in minimum waiting at prios by trains incoming from the SL.

This is especially good for games in which very fast trains are used, like the default Maglevs. Instead of holding up the flow, or requiring ridiculous prios, they instead go into the outer lane which should be mostly free. In addition, trains get a chance and will always try to move into a more inner lane to avoid them.

This ensures that both flow and speed on the network are increased dramatically.

{{R&D_header|Switch Mainlines}}
{{R&D_content|Use first implementation|PhazorX and OwenS|done|See above|claimed|Waiting for a plan to be chosen in public server game #44|unclaimed|Waiting for plan|N/A}}
{{R&D_footer}}

===Shift Mainline Implementation===

by [[User:Phazorx|Phazorx]] 03:49, 20 June 2007 (UTC)

The save of the game is [http://openttdcoop.ppcis.org/blog/files/phazorx/ShiftML_test.sav available], it is based on [http://openttdcoop.ppcis.org/wiki/index.php/PublicServer:Archive_-_Games_41_-_50#gameid_44 Public Server Game #44].

Shift Mainline, designed as expandable high capacity network backbone offers many benefits while remaining easy to comprehend. The main idea is to separate lane switching and lane merging network constructions thus creating a maximum-speed, high-capacity train stream. As a byproduct it greatly simplifies SLH merger construction. By design, minimal width of Shift ML is 2 lanes. One of these lanes is arbitrarily selected as the '''merge lane''' and the other lanes are '''switch lanes'''. In order to permit sideline trains to enter the mainline without delays a new mainline network element is introduced - a '''switcher'''. Incentive for trains to switch lanes is created by placing station platforms in the way of a train, immediately following the intersection, allowing it to switch to station-free lane. The pathfinder sees the platform as an obstacle, assigning a significant penalty to the path, and, if possible, will choose a way to avoid it and switch lanes. However in the case that it is not possible (exit to other lane is red) it would keep same lane.

Merge lane is used for entering sideline traffic, it requires full sized priority window to reduce/eliminate chance of mainline being blocked. Ideally - any entering sideline train should be going full speed at time when end of it passes tracks intersection point, hence acceleration room is needed.

'''Note:''' making lengthy acceleration part past choice point within merger is not recommended since it would mean sideline trains catching up to end of previous mainline train and slowing down.

<br style="clear:both;" />

A switcher allows mainline trains, going full speed, to switch lanes in order to give more room for sideline trains entering at next SLH. Switcher helps to move trains to lanes furthest from the merge lane. Switch only affects 2 lanes and is priority-based - a train should switch '''only''' if there is room for entry without disrupting that lane's traffic. Since all trains are going at or near full speed, the priority window design for the switcher is based exclusively on train length and in general should be TL + link length + 2 signal lengths i.e. 10 tiles for TL:5 or 12 for TL:7. Longer oncoming traffic detection window will not help in any way and can only force trains to wait for longer gaps between trains and increase sideline wait time. In order to avoid deadlocks created by change is situation after a train has decided to switch lane. The '''bypass''' splits from ML lane exactly TL + 1 tiles after the entry switch signal, this would prevent trains from using bypass for any other reasons than passing stuck train.

'''Note:''' reducing the part of the link between entry and exit-to-other-lane signals will minimize chance of one train getting stuck for a while after making the wrong choice.

'''Note:''' entry signal for lane-switching part is not necessary and can be removed for eliminating chance of slowing down second train if it is following another train to closely (if both exit signals are red, the entry will be red too, making signal distance twice the size and delaying the second train). Second advantage is that you can make bypass at least 1 tile smaller (possible to make it 2 tiles shorter). Sad, that sometimes other players will "fix" your shifter with a entry light and so the line is blocked. :(

'''Note:''' the pre-signal on the link between the two ML has to be a double one or trains will wait there even on a red signal instead of going straight.

<br style="clear:both;" />

Any SLH within SML concept would consist of 3 parts: splitter, switcher group, and merger. The order is relevant, since first trains should exit the mainline, then shuffle to make more room on merge lane and then sideline trains enter merge lane as conditions permit. The splitter part is a regular all-lane splitter.

'''Note:''' as the capacity of the mainline can be rapidly increased, it is recommended to make longer exit ramps at the splitter for lowering the chance of exiting strains blocking each other and the mainline.

====Two lane mainline====
[[Image:SML2-SLH.PNG|thumb|200px|SLH]]
[[Image:SML2-Shifter.PNG|thumb|200px|Shifter]]
This is a very simple case and a relatively weak solution, but it can be done very fast, making the network functional earlier in game. Spacing mainline lanes one tile apart will make it much easier to integrate switchers and is generally recommended for SML. The shifter can and should be placed as close as possible to the merger. The red platform indicates a penalty station for forcing trains to switch away from the merge lane, and the white one is to deprioritize bypass. The example pictures are intended for TL:5 which is evident in the 10-tile priority window and 6 tiles between bypass and link track junctions. Merger prio is usually a result of experimentation with given track type, engine, train length and weight. For adequately-powered medium-speed trains it is around 2-3 train lengths. Please refer to the [http://openttdcoop.ppcis.org/blog/2007/04/28/non-blocking-sl-to-ml-mergers/ non-blocking mergers] blog article for an in-depth explanation of lengths of the prio and the acceleration track.
<br style="clear:both;" />

====Three lane implementation and further expansion====
[[Image:SML3-SLHa.PNG|thumb|right|200px|Fast SLH]]
[[Image:SML3-SLHb.PNG|thumb|right|200px|Slow SLH]]
[[Image:SML3-2xShifter.PNG|thumb|right|200px|Shifter Tandem]]
Three-lane (and wider) SML inherits the same principles of the two-lane plan, and usually is the result of traffic growth. At some point in time, two-lane SML will not be enough for the amount of trains and the need for expansion will become apparent. Adding a third lane would imply: laying a lot of tracks, adding exit ramps and putting an extra switcher before current switcher-merger for all SLHs. The merger is not touched and the upgrade can be easily done on the fly without stopping traffic. Empirical tests show that a merger balancing between several lanes is less efficient that one with a queue of trains waiting to enter a single merge lane and I would not recommend expanding the merge lanes along with the mainline in any way. For every added lane to the mainline, a new switcher shifting traffic toward a new lane should be created. This merger should also be placed before existing ones to amplify the effect of multiple lanes and promptly free up the merge lane. In case of three lanes, 1 being the merge lane, 2 the middle lane (formerly the only shift lane) and 3 the last lane: when lane 3 is added, a new switcher is created between 2 and 3 placed earlier on the train path than the switcher between 1 and 2. This would shift trains from lane 2, freeing it up for trains shifting from lane 1 further down the road. This same principle applies to every following lane.

<br style="clear:both;" />

====Usage & Expandability====
Unfortunately, SML as-is does not simplify BBH design, meaning they would be prone to be bottlenecks unless are designed with extra capacity in advance. This implies that loop based networks without any BBHs are best cases for SML. However, it does not mean that regular star, cross or any other layouts are more problematic, they are just as complex as usual while rest of network elements are easier. Reducing the number of BBHs and designing them capable of dealing with expandable mainlines is the key to ease of expandability. Despite unbalanced nature of the network tests proved that it does not create any statistically significant bias in lane preference of trains. Simple SLH design encourages using that element often and in general it is a good idea, one SLH per 100 tiles of ML track is probably as often as recommended. Tighter packing might affect expandability when switcher groups grow close to splitter or splitters would be right after previous SLH. Separation of merger lane and rest the of the traffic as well as deprioritizing SL traffic makes SML more tolerant for faster trains such as maglevs. However in case of very fast trains, such as the default maglev, the question of power becomes more crucial: while being extremely fast, these trains tend to be not very powerful for these speeds and with "realistic acceleration" enabled, it takes a lot of time for these trains to gain maximum speed. This dramatically affects merger priority window design making it extremely large. In the test case I replaced chimaeras with pegasus maglev engines. For oil or lumber tropical cargo 7 tile trains weigh around 1000t, requiring 60000hp to accelerate reasonably well.

{| border="1" style="text-align:center" cellpadding=0 cellspacing=5
|-
! Engine type !! Quantity !! Total Power !! Full Weight !! Capacity !! Max Speed !! Acceleration Distance
|-
| Chimaera || 1x2 || 20000hp || 882t || 444,000L oil || 643km/h || 59 tiles
|-
| Chimaera || 2x2 || 40000hp || 910t || 370,000L oil || 643km/h || 23 tiles
|-
| Chimaera || 3x2 || 60000hp || 938t || 296,000L oil || 643km/h || 15 tiles
|-
| Pegasus || 4 || 60000hp || 1130t || 370,000L oil || 482km/h || 11 tiles
|-
| Chimaera || 1x2 || 20000hp || 536t || 336,000L rubber || 643km/h || 30 tiles
|-
| Chimaera || 2x2 || 40000hp || 590t || 280,000L rubber || 643km/h || 15 tiles
|-
| Pegasus || 3 || 45000hp || 709t || 308,000L rubber || 482km/h || 9 tiles
|}

'''Note:''' when adding a new lane to SML, it is least disruptive to add the track in the OPPOSITE direction of train travel. This way, trains taking the new track will not have to stop at the end of the mainline where your construction is taking place.

====Resume====
{{R&D_header| Shift Mainline }}
{{R&D_content| Conceptualy different ML layout with aim on expandability and simplicity of design | Phazorx | done) | See above | checked | Test case based on PS Game #44 | done | 4 Lane Shift ML between two massive stations 2000 tiles apart, carrying 950 trains | Applicable to certain games; Large cargo games will benefit the most}}
{{R&D_footer}}

Pending research: Expandable BBH and station entrance design to meet structural requirements of SML.

===Inside-out Shift Mainline (two-way)===
[[User:Phazorx|Phazorx]] 23:34, 5 November 2007 (UTC)
[[Image:iSML1.png|thumb|left|300px|Inside Out SML 1+1]]
[[Image:iSML2.png|thumb|right|300px|Inside Out SML 2+2]]
[[Image:iSML3.png|thumb|right|300px|Inside Out SML 3+3]]
Loop design of SML along with benefit of ease of use has limitations enforced by loop idea - it is a necessary to complete a full loop journey for any train route (a complete start to end and back to start route would use 100% of the loop). That adds to travel time and reduces overall capacity of the network in some cases. A two-way loop would address this limitation at cost of added hub and station design complexity.

In order to maintain scalability of mainline while offering reduced travel distance which comes with two way hubs following design is recommended: Inner lanes of both directions are designated as merge lanes and more lanes are added outwards as needed. The images on right side show examples for full balanced, multiple lane, bidirectional hubs. Which are extreme cases of complexity and in reality it is more feasible to have half hubs that exit from one and join another direction. That usually would require network plan that is compatible with such separation of directions. Inner merge lanes would have incoming sidelines (in case if areas from both sides of ML need to be connected - combined sidelines) and other lanes of ML could either jump over SL or work their way around the merge point.

If from start point some precautions are taken and parts of hub structural elements are spaced accordingly - it would be relatively easy to expand them as time goes w/o disrupting existing ML functionality. It is also important to leave space in the middle at least 2 tiles between directions so it is possible to create devices at same time on both directions.

Stations connected to such ML would require special attention too, in most cases trains coming from one direction should be returned onto ML heading the other. Easiest functional station would have 2 independent parts for each direction. On the other hand - a shared solution with 2 alternative exits that preferably do not block each other will work fine as well. Combination of above (some shared + some per direction dedicated) is also possible.

==Situation switcher==
''Concept by [[user:XeryusTC|XeryusTC]]''
[[Image:Shift_mainline.png|thumb|right|200px|Alternate design]]
Don't use stations to force trains on other lines, use the current situation instead. This type of shifting forces a train on line A to go to line B when there is no upcoming train AND there is a train joining the mainline on line A at that moment.
Prio 1 should be considered as a normal prio but doesn't have to be as long to prevent the train from joining when there are upcoming trains. Prio 2 only has to be as long as the TL plus enough space to allow the train on line A to go over the 2 tile diagonal switch line. This way no train will ever block the other line while switching when all trains are at top speed.

The benefit of this approach is that you don't force trains to go onto the other line under usual circumstances, you will get a properly balanced ML. You also don't need to have a big priority line for every lane as in a normal balancer, but 2 smaller ones instead.

{{R&D_header|XeryusTC's switcher}}
{{R&D_content|Use first implementation|XeryusTC|done|See above|wip|First implementation build, waiting for trains to go over it|claimed|Testing|Will be taken a look at later}}
{{R&D_footer}}

==Sophisticated situation switcher==
''Concept by [[user:barnex|barnex]]''
[[Image:Shift_mainlines_with_presignal_logic.png|thumb|right|200px|Design with NOT and AND gates]]
Maybe even beter results could be achived with [http://www.openttdcoop.org/blog/2008/06/17/the-insane-led-counter-logic-gates-part-1/ presignal logic]. In the picture you can see ugly design of such switcher. If there is a train waiting on sideline, B is true (red). When there's no train at ML 1, A is false. Therefore NOT A is true (red). So, if there is free space at ML1 and train on sideline (B AND NOT (A) = true) train riding ML2 will be forced to change lane. This design, unlike forgoing, is very complex and takes lot of space to build, but could be more efficient.
[[Category:Research]]

==Sophisticated situation switcher #2==
''Concept by [[user:Ben Totterdell|Ben Totterdell]]''
[[Image:OTTDC%2C_Inc%2C_13th_Aug_2096.png|thumb|right|400px|SLH Situation Switcher]]
This SLH was developed from scratch during the planning of public server game 104, it was developed because i wanted to find a way of making trains switch tracks in relation too what was happening on other tracks. I started planning on a L_L Mainline when a Sideline was joining it, and i wanted to see how i could least disrupt the flow of the ML but also add a SL and make it Balanced all at the same time. as you can see in the picture, there are three lines in this ML A,B,C and a Busy Sideline. There are Two Switches in this SLH, A>B and B>C, and as a result if A wants to Switch to B but there is a train on B already, B will move onto C to create space, and as a result no speed is lost. Although To Prevent Trains Switching without being forced to by all the prios, there are penalties, how ever in this game the penalties don't make a difference to the speed, because all trains have 'non stop' in their orders. In order to solve the issue, if all Lines are full, there is no where for the trains from the SL to go, there are prio's on all lines which will stop the SL if all lanes are blocked. This has been my first invention as a OTTD Coop player, and i hope i will be able to make more in the future,

File:OTTDC, Inc, 13th Aug 2096.png

2008-07-17T20:30:04Z

BenTotterdell: SLH Situation Switcher

SLH Situation Switcher

PublicServer:Archive - Games 101 - 110

2008-07-14T11:59:04Z

BenTotterdell: Added Photo

<noinclude>{{PublicServerArchiveMenu}}</noinclude>

{{Archive_PublicServer|Public Server Game 103|06.06.08 - 14.07.08|{{User|Ben}}, (add yourself) |Cargo |TL5| 512*1024 Temperate|r13677+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| Planetmaker had the winning plan for a game which involved the use of many different industies, as a result over 20 Major Stations had to be built with 8 BBH's. This took alot of time, and with the interuption of the wottdgd mid game the game was almost finished for a long time and only a few changes had to be made on the last day. Overall there was 750 trains, with no strain on the network, which is a good sign that the hubs network was produced to a high standard or not enough trains... How ever that point aside, Ottd Coopers managed to build a good solid network even through the confusion of having different (more Realistic) industires. |103|Image:COOP%27ies_Transport%2C_3rd_Dec_2236.png| Image Showing BBH 04, which was a brilliant piece of work, giving a good impression of the Fast flowing network, which stopped all jams.}}

{{Archive_PublicServer|Public Server Game 102|28.06.08 - 05.07.08|{{User|Mark}}, {{User|planetmaker}}, {{User|andyp}}, {{User|Levi}}, {{User|Ammler}}, {{User|Addi}}, (add yourself) |Cargo |TL3| 512*512 Temperate|r13607+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| Mark created the winning plan for a cargo game using erail and TL3. We had all the secondary stations in the corners, connected to the ML with 4 BBHs, and 4 SLHs for the primary industries. The network developed very well, except for one SLH, which was turned to chaos by people adding lots of bits to the original construction done by Mark. |102|Image:PSG102.png|Showing the steel mill station with some nice eyecandy, and a lot of trains loading; due to TL3, there were always a lot of trains on the move}}

{{Archive_PublicServer|Public Server Game 101|13.06.08 - 28.06.08|{{User|Mark}}, {{User|Powell}}, {{User|planetmaker}}, {{User|andyp}}, {{User|Levi}}, (add yourself) |Multipoint to Multipoint Passenger |TL4| 512*512 Temperate|r13607+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| The plan chosen involved the goal to connect all 104 (!) towns, this seemed like an impossible thing to achieve at first but we managed to connect all of them toward the end of the game. Lots of big cities, nice stations and clean building everywhere. Overall a very well developed game. |101|Image:PSG101.png|Showing a station nicely imbedded in cities, giving a pretty good impression of what this game looked like.}}

File:COOP'ies Transport, 3rd Dec 2236.png

2008-07-14T11:54:29Z

BenTotterdell: Game 103 - BBH 04

Game 103 - BBH 04

File:TTD.bmp

2008-07-14T11:48:29Z

BenTotterdell: Image of Game 103 BBH 04

Image of Game 103 BBH 04

PublicServer:Archive - Games 101 - 110

2008-07-14T11:40:15Z

BenTotterdell: Added summary for game 103

<noinclude>{{PublicServerArchiveMenu}}</noinclude>

{{Archive_PublicServer|Public Server Game 103|06.06.08 - 14.07.08|{{User|Ben}}, (add yourself) |Cargo |TL5| 512*1024 Temperate|r13677+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| Planetmaker had the winning plan for a game which involved the use of many different industies, as a result over 20 Major Stations had to be built with 8 BBH's. This took alot of time, and with the interuption of the wottdgd mid game the game was almost finished for a long time and only a few changes had to be made on the last day. Overall there was 750 trains, with no strain on the network, which is a good sign that the hubs network was produced to a high standard or not enough trains... How ever that point aside, Ottd Coopers managed to build a good solid network even through the confusion of having different (more Realistic) industires. |103|Image:PSG102.png| ???}}

{{Archive_PublicServer|Public Server Game 102|28.06.08 - 05.07.08|{{User|Mark}}, {{User|planetmaker}}, {{User|andyp}}, {{User|Levi}}, {{User|Ammler}}, {{User|Addi}}, (add yourself) |Cargo |TL3| 512*512 Temperate|r13607+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| Mark created the winning plan for a cargo game using erail and TL3. We had all the secondary stations in the corners, connected to the ML with 4 BBHs, and 4 SLHs for the primary industries. The network developed very well, except for one SLH, which was turned to chaos by people adding lots of bits to the original construction done by Mark. |102|Image:PSG102.png|Showing the steel mill station with some nice eyecandy, and a lot of trains loading; due to TL3, there were always a lot of trains on the move}}

{{Archive_PublicServer|Public Server Game 101|13.06.08 - 28.06.08|{{User|Mark}}, {{User|Powell}}, {{User|planetmaker}}, {{User|andyp}}, {{User|Levi}}, (add yourself) |Multipoint to Multipoint Passenger |TL4| 512*512 Temperate|r13607+ [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| The plan chosen involved the goal to connect all 104 (!) towns, this seemed like an impossible thing to achieve at first but we managed to connect all of them toward the end of the game. Lots of big cities, nice stations and clean building everywhere. Overall a very well developed game. |101|Image:PSG101.png|Showing a station nicely imbedded in cities, giving a pretty good impression of what this game looked like.}}

PublicServer:Archive - Games 91 - 100

2008-05-31T19:50:14Z

BenTotterdell:

<noinclude>{{PublicServerArchiveMenu}}</noinclude>

{{Archive_PublicServer|Public Server Game 97|23.05.08 - 26.05.08| {{User|BenTotterdell}}(add yourself) |[[Gametype:Cargo_Concept| 512*512 Temperate|r13269 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| In this game we had a very interesting ML Layout, we had a RRRR Diagonal ML Loop running across the map from the SW to the NE, this was a very interesting and Complex network planned by combuster, there was a low Terra rule although sometimes it was over looked, it did however make the mainlines look messy and there were many 'Ghetto' Style hubs, which didn't help matters and which eventually became a big problem with too many trains to handle, however there were fewer new players this game, and towards the end of the game the hubs became clearer and priorities were used more often and the network then moved better and the game became a success. |97||.}}

{{Archive_PublicServer|Public Server Game 96|23.05.08 - 26.05.08| {{User|Mark}}, {{User|Combuster}}, {{User|Rob}}, {{User|Satyap}}, {{User|Walle}},{{User|BenTotterdell}},(add yourself) |[[Gametype:ICE_SBahn|S-Bahn + ICE]] |TL3 S-Bahn Trains, TL9 ICE-Trains| 1024*256 Arctic|r13210 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| In this game we started off with a plain map which had only 3 cities on it. After the S-Bahns were built town growth was enabled and the cities started growing rapidly. We ended up with a total population of more than 2 million and moving many millions of passengers each year. |96|Image:PSG96.png|The shopping mall at Shanghai, situated between the two main traffic lines through the city.}}

{{Archive_PublicServer|Public Server Game 95|17.05.08 - 23.05.08| {{User|BenTotterdell}}, {{User|Rob}}, {{User|tneo}}, {{User|pm}}, {{User|Mark}}, {{User|Satyap}}, {{User|Tim}}, {{User|Narc}}, {{User|Combuster}}, (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL5 for primaries, TL9 for Goods/Food| 1024*256 Arctic|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had all trains going down a LLLL10RRRR ML. Included in the game were two refit area's, one at each end of the map. The goods/food trains refit from one to the other with every trip, and ran on a timetable. As a consequence we could reduce the amount of trains on the mainline, but maintain a high and smooth cargo delivery rate. During the start of the game there was confusion regarding station design. All stations were meant to be terminus, but that was not clearly signed, creating lot of confusion when several stations needed to rebuilt to conform to the plan. The problems were eventually solved, and the network ended running very smooth. |95|Image:PSG95.png|Showing a BBH that caused a lot of problems. In the upper right you can see one of the refit areas where empty food trains were refitted to pick up goods.}}

{{Archive_PublicServer|Public Server Game 94|11.05.08 - 17.05.08| {{User|Satyap}}, {{User|mixrin}}, {{User|Combuster}}, {{User|ninjamask}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL20 for ML trains, various for feeders| 1024*1024 Temperate|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had small feeders feeding the huge 20-Tile Mainline Trains. A misunderstanding in the beginning of the game, along with the unspecified engine to be used for the ML trains, lead to the ML being designed for a curve length of 4, and unable to handle the fastest engines. ''(The fastest engine would have taken about 8 engines to handle TL20, anyway, if not more.)'' The challenge of designing the stations for TL 20 was very difficult. Surges in traffic could easily overlaod the waiting space and block the ML. |94|Image:PSG942.png|Showing one of the feeders.}}

{{Archive_PublicServer|Public Server Game 93|30.04.08 - 11.05.08| {{User|Mark}}, {{User|mixrin}}, {{User|Addi}}, {{User|satyap}}, {{User|Rob}}, {{User|tneo}}, {{User|ninjamask}}, (Add yourself)|[[Gametype:Chaos Theory|Chaos]] + [[Gametype:Cargo_Concept|Cargo]] + Pax |Various ''(TL8 for inter-island transfer)'' | 256*2048 Temperate|r13016 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|A game making use of a new concept in which players got their own piece of map to manage locally. Later on the areas were connected with a Mainline network. |93|Image:PSG93.png|Venice of the South-West: well-serviced town with a station squeezed into available space}}

{{Archive_PublicServer|Public Server Game 92|27.04.08 - 30.04.08| {{User|Addi}}, {{User|Ammler}}, {{User|XeryusTC}}, {{User|Combuster}}, {{User|Skasi}}, {{User|boes}}, {{User|ninjamask}}, {{User|Ehtirno}}, {{User|Altaree}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 256*1024 Arctic (alpine)|r12906 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|The next three tiles train with a big LLL RRR ring around the whole map and a LL RR line in the middle. There were never bottlenecks anywhere on the whole network since the beginning. Therefore would the network handle more trains, but the maximum of 1000 trains has been reached.|92|Image:PSG92.png|One of the two BBHs in the game}}

{{Archive_PublicServer|Public Server Game 91|23.04.08 - 27.04.08| {{User|pm}}, {{User|Ammler}}, {{User|Mark}}, {{User|SmatZ}}, {{User|Combuster}}, {{User|XeryusTC}}, {{User|Rob}}, {{User|Altaree}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 512*512 sub-tropic|r12805 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|It was a massive game with a number of new players and in the end over 950 trains. The backbone consisted of two ML rings, one for empty, one for full trains. It proved fluent up to about 750 trains, after that jams started to show. - [http://www.openttdcoop.org/blog/2008/04/27/review-psg-91/ Review at blog] |91|Image:PSG91.png|Combined factory and refinery station, serving over 750 trains, 550 of them delivering stuff.}}

PublicServer:Archive - Games 91 - 100

2008-05-31T19:47:00Z

BenTotterdell: Wrote the archieve for the public game 97

<noinclude>{{PublicServerArchiveMenu}}</noinclude>

{{Archive_PublicServer|Public Server Game 97|23.05.08 - 26.05.08| {{User|BenTotterdell}}(add yourself) |[[Gametype:Cargo_Concept| 512*512 Temperate|r13269 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| In this game we had a very interesting ML Layout, we had a RRRR Diagonal ML Loop running across the map from the SW to the NE, this was a very interesting and Complex network planned by combuster, there was a low Terra rule although sometimes it was over looked, it did however make the mainlines look messy and there were many 'Ghetto' Style hubs, which didn't help matters and which eventually became a big problem with too many trains to handle, however there were fewer new players this game, and towards the end of the game the hubs became clearer and priorities were used more often and the network then moved better and the game became a success. |97||}}

{{Archive_PublicServer|Public Server Game 96|23.05.08 - 26.05.08| {{User|Mark}}, {{User|Combuster}}, {{User|Rob}}, {{User|Satyap}}, {{User|Walle}},{{User|BenTotterdell}},(add yourself) |[[Gametype:ICE_SBahn|S-Bahn + ICE]] |TL3 S-Bahn Trains, TL9 ICE-Trains| 1024*256 Arctic|r13210 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]| In this game we started off with a plain map which had only 3 cities on it. After the S-Bahns were built town growth was enabled and the cities started growing rapidly. We ended up with a total population of more than 2 million and moving many millions of passengers each year. |96|Image:PSG96.png|The shopping mall at Shanghai, situated between the two main traffic lines through the city.}}

{{Archive_PublicServer|Public Server Game 95|17.05.08 - 23.05.08| {{User|BenTotterdell}}, {{User|Rob}}, {{User|tneo}}, {{User|pm}}, {{User|Mark}}, {{User|Satyap}}, {{User|Tim}}, {{User|Narc}}, {{User|Combuster}}, (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL5 for primaries, TL9 for Goods/Food| 1024*256 Arctic|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had all trains going down a LLLL10RRRR ML. Included in the game were two refit area's, one at each end of the map. The goods/food trains refit from one to the other with every trip, and ran on a timetable. As a consequence we could reduce the amount of trains on the mainline, but maintain a high and smooth cargo delivery rate. During the start of the game there was confusion regarding station design. All stations were meant to be terminus, but that was not clearly signed, creating lot of confusion when several stations needed to rebuilt to conform to the plan. The problems were eventually solved, and the network ended running very smooth. |95|Image:PSG95.png|Showing a BBH that caused a lot of problems. In the upper right you can see one of the refit areas where empty food trains were refitted to pick up goods.}}

{{Archive_PublicServer|Public Server Game 94|11.05.08 - 17.05.08| {{User|Satyap}}, {{User|mixrin}}, {{User|Combuster}}, {{User|ninjamask}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL20 for ML trains, various for feeders| 1024*1024 Temperate|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had small feeders feeding the huge 20-Tile Mainline Trains. A misunderstanding in the beginning of the game, along with the unspecified engine to be used for the ML trains, lead to the ML being designed for a curve length of 4, and unable to handle the fastest engines. ''(The fastest engine would have taken about 8 engines to handle TL20, anyway, if not more.)'' The challenge of designing the stations for TL 20 was very difficult. Surges in traffic could easily overlaod the waiting space and block the ML. |94|Image:PSG942.png|Showing one of the feeders.}}

{{Archive_PublicServer|Public Server Game 93|30.04.08 - 11.05.08| {{User|Mark}}, {{User|mixrin}}, {{User|Addi}}, {{User|satyap}}, {{User|Rob}}, {{User|tneo}}, {{User|ninjamask}}, (Add yourself)|[[Gametype:Chaos Theory|Chaos]] + [[Gametype:Cargo_Concept|Cargo]] + Pax |Various ''(TL8 for inter-island transfer)'' | 256*2048 Temperate|r13016 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|A game making use of a new concept in which players got their own piece of map to manage locally. Later on the areas were connected with a Mainline network. |93|Image:PSG93.png|Venice of the South-West: well-serviced town with a station squeezed into available space}}

{{Archive_PublicServer|Public Server Game 92|27.04.08 - 30.04.08| {{User|Addi}}, {{User|Ammler}}, {{User|XeryusTC}}, {{User|Combuster}}, {{User|Skasi}}, {{User|boes}}, {{User|ninjamask}}, {{User|Ehtirno}}, {{User|Altaree}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 256*1024 Arctic (alpine)|r12906 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|The next three tiles train with a big LLL RRR ring around the whole map and a LL RR line in the middle. There were never bottlenecks anywhere on the whole network since the beginning. Therefore would the network handle more trains, but the maximum of 1000 trains has been reached.|92|Image:PSG92.png|One of the two BBHs in the game}}

{{Archive_PublicServer|Public Server Game 91|23.04.08 - 27.04.08| {{User|pm}}, {{User|Ammler}}, {{User|Mark}}, {{User|SmatZ}}, {{User|Combuster}}, {{User|XeryusTC}}, {{User|Rob}}, {{User|Altaree}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 512*512 sub-tropic|r12805 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|It was a massive game with a number of new players and in the end over 950 trains. The backbone consisted of two ML rings, one for empty, one for full trains. It proved fluent up to about 750 trains, after that jams started to show. - [http://www.openttdcoop.org/blog/2008/04/27/review-psg-91/ Review at blog] |91|Image:PSG91.png|Combined factory and refinery station, serving over 750 trains, 550 of them delivering stuff.}}

PublicServer:Archive - Games 91 - 100

2008-05-23T10:33:50Z

BenTotterdell: Added summary for game 95

<noinclude>{{PublicServerArchiveMenu}}</noinclude>

{{Archive_PublicServer|Public Server Game 95|17.05.08 - 23.05.08| {{User|BenTotterdell}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL20 for ML trains, various for feeders| 1024*1024 Temperate|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had all trains going down the mainline, the mainline was LLLL 10 RRRR. Included in the game were 2 refit area's these were used to make the most effective use of the trains and as a consequence we could reduce the amount of trains on the mainline, but maintain a high cargo delivery rate. During the start of the game there was alot of confusion regarding station design, all stations were mean't to be terminus' but that was not clearly signed, this created alot of confusion and anger when peoples work had to be destoryed cause the sign was not clear. Also towards the end of the game at the wood drop station there was a lack of co-operation that mean't the station took along time to build and by various people, which mean't alot of problems were caused to the rest of the network. But eventually the problems were solved and the network runs more smoothly. |95|Image:PSG94.png|Add Description}}

{{Archive_PublicServer|Public Server Game 94|11.05.08 - 17.05.08| {{User|Satyap}}, {{User|mixrin}}, {{User|Combuster}}, {{User|ninjamask}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |TL20 for ML trains, various for feeders| 1024*1024 Temperate|r13032 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|In this game we had small feeders feeding the huge 20-Tile Mainline Trains. A misunderstanding in the beginning of the game, along with the unspecified engine to be used for the ML trains, lead to the ML being designed for a curve length of 4, and unable to handle the fastest engines. ''(The fastest engine would have taken about 8 engines to handle TL20, anyway, if not more.)'' The challenge of designing the stations for TL 20 was very difficult. Surges in traffic could easily overlaod the waiting space and block the ML. |94|Image:PSG94.png|Add Description}}

{{Archive_PublicServer|Public Server Game 93|30.04.08 - 11.05.08| {{User|Mark}}, {{User|mixrin}}, {{User|Addi}}, {{User|satyap}}, {{User|Rob}}, {{User|tneo}}, {{User|ninjamask}}, (Add yourself)|[[Gametype:Chaos Theory|Chaos]] + [[Gametype:Cargo_Concept|Cargo]] + Pax |Various ''(TL8 for inter-island transfer)'' | 256*2048 Temperate|r13016 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|A game making use of a new concept in which players got their own piece of map to manage locally. Later on the areas were connected with a Mainline network. |93|Image:PSG93.png|Venice of the South-West: well-serviced town with a station squeezed into available space}}

{{Archive_PublicServer|Public Server Game 92|27.04.08 - 30.04.08| {{User|Addi}}, {{User|Ammler}}, {{User|XeryusTC}}, {{User|Combuster}}, {{User|Skasi}}, {{User|boes}}, {{User|ninjamask}}, {{User|Ehtirno}}, {{User|Altaree}}, {{User|Rob}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 256*1024 Arctic (alpine)|r12906 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|The next three tiles train with a big LLL RRR ring around the whole map and a LL RR line in the middle. There were never bottlenecks anywhere on the whole network since the beginning. Therefore would the network handle more trains, but the maximum of 1000 trains has been reached.|92|Image:PSG92.png|One of the two BBHs in the game}}

{{Archive_PublicServer|Public Server Game 91|23.04.08 - 27.04.08| {{User|pm}}, {{User|Ammler}}, {{User|Mark}}, {{User|SmatZ}}, {{User|Combuster}}, {{User|XeryusTC}}, {{User|Rob}}, {{User|Altaree}} (Add yourself)|[[Gametype:Cargo_Concept|Cargo]] |3 | 512*512 sub-tropic|r12805 + [[Guides:Glossary:GRF|#openttdcoop-GRF-Pack 7.0]]|It was a massive game with a number of new players and in the end over 950 trains. The backbone consisted of two ML rings, one for empty, one for full trains. It proved fluent up to about 750 trains, after that jams started to show. - [http://www.openttdcoop.org/blog/2008/04/27/review-psg-91/ Review at blog] |91|Image:PSG91.png|Combined factory and refinery station, serving over 750 trains, 550 of them delivering stuff.}}