|
|
| (15 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| − | ''By [[user:Phazorx|PhazorX]], written up by [[user:OwenS|OwenS]], this is a development from the concept LBR mainlines''
| + | #REDIRECT[[Shift Mainline]] |
| − | ==Shift Mainlines==
| + | |
| − | [[Image:Shift_Mainline.png|thumb|right|200px|Design of a junction]]
| + | |
| − | Shift Mainlines are a new concept that has only recently been developed. '''Warning: It has not been tested thoroughly yet - It is currently being tested in a game on the public server'''
| + | |
| − | | + | |
| − | Shift Mainlines remove much of the complexity of building junctions on a traditional mainline by only requiring that trains be injected into the left most lanes. The design causes YAPF to prefer the inner lanes, and as such if the inner lane is free YAPF will cause the train to shift right.
| + | |
| − | | + | |
| − | Trains in the second inner most lane are shifted into the inner most lane first, to ensure trains in the outer lanse get a chance to shift into the inner lanes, and this is repeates 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 rediculous 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
| + | |
| − | | + | |
| − | ''More text will be added as the research continues''
| + | |
| − | | + | |
| − | {{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 contructions thus creating maximum speed high capacity train stream. As a byproduct it greatly simplifies SLH merger contructions. By design, minimal width of Shift ML is 2 lanes. one of which arbitraty selected as '''merge lane''' and other (in case of ML being wider - others) are "switch lanes". In order to permit SL trains to enter the ML without delays a new ML network element is introduced - a '''switcher'''. Incensetive for trains to switch lanes is created by placing station platfoms on a way of a train, imediatly following the intersection, allowing it to switch to station-free lane. Pathfinder sees the platform as an obstacle and, if possible, will choose a way to avoid it (and switch lanes) however in case if it is not possible (exit to other lane is red) it would keep same lane. | + | |
| − | | + | |
| − | Merge lane is used for entering SL traffic, it requires full sized priority window to reduce/eliminate chance of ML being blocked. Ideally - any entering SL 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 recoomended since it would mean SL trains catchibg up to end of previous ML train and slowing down.
| + | |
| − | | + | |
| − | <br style="clear:both;" />
| + | |
| − | | + | |
| − | A switcher allows ML trains, going full speed, to switch lanes in order to give more room for SL trains entering at next SLH. Switcher helps moving train to lanes most further from merge lanes. Switch only affects 2 lanes and is prioeity based - a train sould switch ''only'' if there is room for entry without disrupting that lane's traffic. Since all trains are going with speed, the priority widnow design for switcher is based exclusively on train length and in general should be TL + link length + 2 singnal 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 gap sbetween trains and increasing SL 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 part of link between entry and exit-to-other-lane signals will minimize chance of one train getting stcuk for a while after making wrong choice
| + | |
| − | Note: enty signal for lane switching part is not necessary and can be removed for eliminationg chance of slowing down second train if it is following another train to closely (if both exit signals are red - enry will eb red too, making signal distance twice the size and delaing second train)
| + | |
| − | Note: putting station platform on bypass is also recommended to reduce chance of trains taking bypass for no reason
| + | |
| − | | + | |
| − | <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 ML, then shuffle to make more room on merge lane and then SL trains enter merge lane as conditions permit. Splitter part is plain regular all lane splitter
| + | |
| − |
| + | |
| − | Note: Since capacity of ML can be rapidly increased it is recommended to make longer exit ramps at splitter for lowering the chance of exiting strains blocking each other and ML
| + | |
| − | | + | |
| − | ====Two lane mainline====
| + | |
| − | [[Image:SML2-SLH.PNG|thumb|200px|SLH]]
| + | |
| − | [[Image:SML2-Shifter.PNG|thumb|200px|Shifter]]
| + | |
| − | This is a very simple case and relatively weak soltion, but can be done very fast, making network functional earlier in game. Spacing ML lanes one tile aprat will make it much easier to integrate switchers and is generaly recommended. The shifter can and shoukld be placed as close as posible to the merger. Red platform indicates penalty station for forcing trains to swicth away from merge lane and white one is to deprioritize bypass. The example pictures are inteded for TL:5 which is apparent from 10 tile priority window and 6 tiles between bypass and link track junctions. Merger prio is usualy a result of experimentation with given track type, engine, train length and weight. For adequatly powered mediaum speed trains it is around 2-3 train lengths (please refer to [http://openttdcoop.ppcis.org/blog/2007/04/28/non-blocking-sl-to-ml-mergers/ Non-blocking mergers] article for in depth explanation of lengths of prio and acceleration track)
| + | |
| − | <br style="clear:both;" />
| + | |
| − | | + | |
| − | ====Three lane implementation and further expantion====
| + | |
| − | [[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 and more lane wide SML inherit same priciples of two lane one and usualy are result of traffic growth. At some point of time two lane SML will not be enough for amount of trains and need for expantion will become apparent. Adding a third lane would imply: laying a lot of trackx, adding exit ramps and putting an extra switcher before current switcher-merger for all SLHs. Merger is not touched and the upgrade can be easily done on a fly w/o stopping traffic. Emperical test shown than a merger balancing between several lanes is less efficient that one with a queue of trains waiting to enter single merge lane and i would not recommend expanding merge along with ML in any way. For every added lane to ML a new switcher shifting traffic towards new lane should be created, it should also be placed before existing ones to ammplify the effect of multiple lanes and promtly free up the merge lane. In case of three lanes, 1 being merger, 2 middle and 3 last lane; when lane 3 is added, a new switcher put between 2 and 3 placed earlier on train path than 1->2, would shift trains from lane 2, freeing it up for trains shifting from lane 1 further down the road. Same appliys to ever next lane / switcher
| + | |
| − | | + | |
| − | <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 number of BBHs and designing them capable of dealing with expandable ML is the key to ease of expandability. Despite unbalanced nature of the network tests proved that it does not create any statisticaly 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 recomemnded, tighter packing might affect expandability when switcher groups would grow close to splitter or splitters would be right after previous SLH. Separation of merger lane and rest of the traffic as well as deprioritising SL traffic makes SML more tollerant for faster trains such as maglevs However in case of very fast trains, such as default maglev, question of power becomes more crucial, while being extremily fast these trains tend to be not very powerfull for these speeds and with "realistic acceleration" enabaled it takes a lot of time for these trains to gain maximum speed, this dramatically affects merger priority widnow 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 weight 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: addition of new line to SML started at end of ML direction towards begining would be least disruptive.
| + | |
| − | | + | |
| − | ====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 entrace design to meet structural requirements of SML
| + | |
| − | | + | |
| − | ==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 upcomming 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 upcomming 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}}
| + | |
| − | | + | |
| − | [[Category:Research]]
| + | |
