|
|
| (8 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | ==Shift Mainline Premise==
| + | #REDIRECT[[Shift Mainline]] |
| − | ''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 are a new concept that has only recently been developed.
| + | |
| − | | + | |
| − | Shift Mainlines remove much of the complexity of building junctions on a traditional mainline by only requiring that trains be injected into the outermost lanes. The design causes YAPF to prefer the inner lanes. As such, if the inner lane is free, then YAPF will cause the train to shift right.
| + | |
| − | | + | |
| − | 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, and this is repeats getting further out for as many lanes as exist. The outer lane should now be mostly free, which should result in minimum waiting at prios by trains.
| + | |
| − | | + | |
| − | 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 resoults 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]]
| + | |
