https://wiki.openttdcoop.org/api.php?action=feedcontributions&feedformat=atom&user=Vitus#openttdcoop wiki - User contributions [en]2026-04-28T16:59:36ZUser contributionsMediaWiki 1.25.2https://wiki.openttdcoop.org/index.php?title=File:PSG185.png&diff=11819File:PSG185.png2010-09-09T18:24:29Z<p>Vitus: uploaded a new version of "File:PSG185.png":&#32;Cleaner picture</p>
<hr />
<div>One of the busiest transfer stations</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:PSG192.png&diff=11802File:PSG192.png2010-08-29T20:26:12Z<p>Vitus: </p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=PublicServer:Archive_-_Games_191_-_200&diff=11801PublicServer:Archive - Games 191 - 2002010-08-29T20:14:27Z<p>Vitus: PSG192 entry (needs image and description)</p>
<hr />
<div><noinclude>{{PublicServerArchiveMenu}}</noinclude><br />
<br />
{{Archive_PublicServer|Public Server Game 192|19.8.10-29.8.10| {{User|V453000}}, {{User|fmauNeko}}, {{User|kriokamera}}, {{User|uliko}}, {{User|Benny}}, {{User|avdg}}, {{User|sharpy}}, {{User|Vitus}}, {{User|slaca}}, {{User|imus}}, {{User|Paltala}}, {{User|Sylf}}, {{User|Chris Booth}}, {{User|TheRisen}}, {{User|Intexon}} | PAX | TL3 | 256 x 512 Temperate| r20594 [[GRF|#openttdcoop-GRF-Pack 7.3]] | Description to follow |192|File:PSG192.png| Image description}}<br />
<br />
{{Archive_PublicServer|Public Server Game 191|1.8.10-19.8.10| {{User|Combuster}}, {{User|Vitus}}, {{User|V453000}}, {{User|KyleS}}, {{User|thgergo}}, {{User|avdg}}, {{User|HanziQ}}, {{User|VVG}}, {{User|Hippidy}}, {{User|Ramsus}}, {{User|Eoin}}, {{User|fmauNeko}}, {{User|kriokamera}}, {{User|Paltala}}, {{User|Planetmaker}}, {{User|Macha}} | [[Gametype:Cargo_Concept|Cargo]] / Scenario | TL4 | 512 x 512 Sub-tropical| r20279 [[GRF|#openttdcoop-GRF-Pack 7.3]] | A scenario where supplies had to be harvested from enemy territory. The plan was to keep to the desert as much as possible and collect resources from the edge of the rainforest to avoid encounters and ambushes. Most of the network was designed with sufficient capacity, but the war factory turned out to have much more traffic than the refinery, requiring an expansion from two lanes to 4 in each direction. |191|File:PSG191.png| Trains being routed with military precision. The forests are said to be even more beautiful, but nobody seemed to have returned with imagery.}}<br />
<br />
----<br />
<br />
----</div>Vitushttps://wiki.openttdcoop.org/index.php?title=Priority&diff=11799Priority2010-08-29T15:24:34Z<p>Vitus: image size; presignal prio over bridge and combined PBS prio</p>
<hr />
<div>[[Oneway_or_Twoway_Presignals|<< Oneway or Twoway Presignals]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Balancing|Balancing >>]]<br />
----<br />
<br />
Priorities, or prios, are constructions we use to give an important track priority over another, less important track. Priority can be made in many ways, all which will be covered here.<br />
<br />
==Using two-way signals==<br />
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.<br />
<br />
[[File:twoway_prio.PNG|684px|thumb|none|Showing the maximum length a prio of this kind should be]]<br />
<br />
==Standard prios==<br />
This is the preferred way to make prios; it 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.<br />
<br />
[[File:standard_prio.PNG|684px|thumb|none|A standard priority using a parallel track; the most common in our games]]<br />
<br />
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.<br />
<br />
==Standard prio and two-way signals combined==<br />
If you run out of room, sometimes using two-way signals ''and'' standard priorities is necessary.<br />
<br />
[[File:standard_prio_and_two-way.png|684px|thumb|none|A standard prio combined with two-way signals.]]<br />
<br />
==Standard prio over a bridge==<br />
When you're building compact hubs you'll often find this trick to come in handy.<br />
<br />
[[File:standard_prio_bridge.PNG|684px|thumb|none|A standard prio over a bridge using a parallel track.]]<br />
<br />
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 trainlengths shorter than 4.<br />
<br />
==Presignal prio over a bridge==<br />
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.<br />
<br />
[[File:presig_bridge_prio.png|684px|thumb|none|A presignal prio over a bridge]]<br />
<br />
==PBS prio==<br />
PBS introduced some interesting ways to make prios. This prio does exactly the same as the pre-signalled one:<br />
<br />
[[File:standard_prio_pbs.PNG|684px|thumb|none|A standard 9-tile long PBS prio]]<br />
<br />
==Combined PBS and presignal prio==<br />
Useful in very tight spaces where twoway signal combined with standard prio is still too large.<br />
<br />
[[File:pbs_presig_prio.png|684px|thumb|none|A PBS prio combined with twoway signals]]<br />
<br />
==PBS prio over bridge==<br />
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.<br />
<br />
[[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]]<br />
<br />
==Limited space==<br />
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. <br />
<br />
[[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]]<br />
<br />
[[File:Used tunnel prio.png|684px|thumb|none|Priority built over used tunnel using PBS and combo pre-signal]]<br />
<br />
----<br />
[[Oneway_or_Twoway_Presignals|<< Oneway or Twoway Presignals]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Balancing|Balancing >>]]<br />
[[Category:Guides]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Pbs_presig_prio.png&diff=11798File:Pbs presig prio.png2010-08-29T15:23:56Z<p>Vitus: Combined presignal and PBS prio</p>
<hr />
<div>Combined presignal and PBS prio</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Presig_bridge_prio.png&diff=11797File:Presig bridge prio.png2010-08-29T15:23:20Z<p>Vitus: A presignal priority over bridge</p>
<hr />
<div>A presignal priority over bridge</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Used_tunnel_prio.png&diff=11796File:Used tunnel prio.png2010-08-29T14:57:27Z<p>Vitus: uploaded a new version of "File:Used tunnel prio.png":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Same_side_prio.png&diff=11795File:Same side prio.png2010-08-29T14:56:27Z<p>Vitus: uploaded a new version of "File:Same side prio.png":&#32;Smaller image</p>
<hr />
<div>Screenshot showing and example of the priority built on the same side as the joining track.</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Pbs_prio_bridge.PNG&diff=11794File:Pbs prio bridge.PNG2010-08-29T14:55:25Z<p>Vitus: uploaded a new version of "File:Pbs prio bridge.PNG":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Standard_prio_pbs.PNG&diff=11793File:Standard prio pbs.PNG2010-08-29T14:54:55Z<p>Vitus: uploaded a new version of "File:Standard prio pbs.PNG":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Standard_prio_bridge.PNG&diff=11792File:Standard prio bridge.PNG2010-08-29T14:54:07Z<p>Vitus: uploaded a new version of "File:Standard prio bridge.PNG":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Standard_prio_and_two-way.png&diff=11791File:Standard prio and two-way.png2010-08-29T14:52:53Z<p>Vitus: uploaded a new version of "File:Standard prio and two-way.png":&#32;Smaller image</p>
<hr />
<div>A two-way prio and standard prio mixed.</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Standard_prio.PNG&diff=11790File:Standard prio.PNG2010-08-29T14:52:07Z<p>Vitus: uploaded a new version of "File:Standard prio.PNG":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoway_prio.PNG&diff=11789File:Twoway prio.PNG2010-08-29T14:50:25Z<p>Vitus: uploaded a new version of "File:Twoway prio.PNG":&#32;Smaller image</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=Community:Members&diff=11785Community:Members2010-08-25T10:35:07Z<p>Vitus: </p>
<hr />
<div>__NOTOC__<br />
==Active Members of #openttdcoop [20]==<br />
*{{User|Ammler|ch}}, the one who dances with the newgrfs '''*''' <br />
*{{User|Combuster|nl}} joins and parts the whole day '''*'''<br />
*{{User|Hylje|fi}}, the silent guy always and never around.<br />
*{{User|KenjiE20|uk}}, the master of puppets, pulling your strings '''*'''<br />
*{{User|Kommer|nl}}, we lost his exclusive love to openttd<br />
*{{User|Mucht|at}}, the oldie who controlls our community from background.'''*'''<br />
*{{User|ODM|nl}}, the innocent ''black'' lamb of #openttdcoop '''*'''<br />
*{{User|Osai|de}}, doctor of the web and autopilot, who can hit back, if needed '''*'''<br />
*{{User|Phazorx|iru}}, what does a communist in the tycoon world?<br />
*{{User|planetmaker|de}}, Make(file) newgrfs and patch packs '''*'''<br />
*{{User|Progman|de}}, builds bigger networks on his Pentium2 at home, than 20 members on publicserver. '''*'''<br />
*{{User|SmatZ|cz}}, pest-controller on all levels of OpenTTD(coop) '''*'''<br />
*{{User|^Spike^|nl}}, the last Dutchy<br />
*{{User|StarLite|nl}} master of the magic roundabout that everybody fears ;-)<br />
*{{User|thgergo|hu}}, the one who builds bridges<br />
*{{User|Thraxian|us}}, makes some little members<br />
*{{User|tneo|nl}}, the spelling angel '''*'''<br />
*{{User|V453000|cz}}, the network construction consultant<br />
*{{User|valhallasw|nl}}, BOFH, Wiki-god and mainly werkloos '''*'''<br />
*{{User|XeryusTC|nl}}, Rebellous doing-stuff-differently-from-convention type of guy '''*'''<br />
''Note: '''*''' Admins have shell access to our servers, all others have rcon access''<br />
<br />
==Honorary Members of #openttdcoop [3]==<br />
*{{User|Brianetta|uk}} (our amiable host who is responsible for making #openttdcoop to such a vital community it is today) '''*'''<br />
*{{User|Phoenix the II|nl}} (our host for the most busy [http://www.openttdcoop.org/blog/public-server/ PublicServer], thanks to him, we don't need to finish a game, because of the server limits.)<br />
*{{User|TrueLight|nl}} (for being a bugfixer over ... a long time ;-) )<br />
<br />
==Currently Inactive Members of #openttdcoop [8]==<br />
*{{User|Adm.Spock|nl}}<br />
*{{User|dp|de}}<br />
*{{User|e1ko|cz}}<br />
*{{User|Guru3|se}}<br />
*{{User|Mark|nl}} Currently on a trip around the world, expecting to be back in 2012. Currently also known as {{User|Aussi-Mark|au}}<br />
*{{User|ottd-king|uk}}<br />
*{{User|Piratejerk|ca}}<br />
*{{User|xahodo|nl}}<br />
<br />
==The usual suspects around the Public Server [38]==<br />
<br />
{|<br />
|-<br />
| valign="top" |<br />
*{{User|Avdg|be}}<br />
*{{User|Barbaar|nl}}<br />
*{{User|Benny|no}}<br />
*{{User|Chris booth|uk}}<br />
*{{User|Damalix|fr}}<br />
*{{User|DCritic|us}}<br />
*{{User|DJNekkid|no}}<br />
*{{User|draconnier|lu}}<br />
*{{User|einKarl|de}}<br />
*{{User|F223|us}}<br />
*{{User|Farden|fr}}<br />
*{{User|Floffe|se}}<br />
*{{User|fmauNeko|fr}}<br />
<br />
<br />
<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
|valign="top" |<br />
*{{User|Fuco|sk}}<br />
*{{User|Gleeb|uk}}<br />
*{{User|HanziQ|cz}}<br />
*{{User|jondisti|fi}}<br />
*{{User|Intexon|cz}}<br />
*{{User|Kolo|pl}}<br />
*{{User|LittleMikey|au}}<br />
*{{User|LordAzamath|ee}}<br />
*{{User|Macha|ie}}<br />
*{{User|Mazur|nl}}<br />
*{{User|mrruben5|nl}}<br />
*{{User|narc|ro}}<br />
*{{User|Nickman|be}}<br />
<br />
<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
|valign="top" |<br />
<br />
*{{User|OwenS|uk}}<br />
*{{User|Petert|us}}<br />
*{{User|pugi|de}}<br />
*{{User|Sedontane|uk}}<br />
*{{User|Thijs|nl}}<br />
*{{User|thomashauk|uk}}<br />
*{{User|Vitus|cz}}<br />
*{{User|Wouterr|be}}<br />
*{{User|Yso|ch}}<br />
*{{User|ZarenorDarkstalker|us}}<br />
*{{User|Zerpa|dk}}<br />
*{{User|Zuu|se}}<br />
<br />
<br />
|}<br />
''And of course all the others above!''<br />
<br />
== Exsuspects & retired members [84] ==<br />
If you are on the ex-suspects list and you start playing again, please move yourself up to the suspects list !<br />
If you are still active and on the ex-suspects list, sorry for the moving :) we sometimes cannot find an IRC log of you while you are still active<br />
<br />
{|<br />
|-<br />
| valign="top" |<br />
*{{User|A3aan|nl}}<br />
*{{User|Addi|ch}}<br />
*{{User|Alanin|de}}<br />
*{{User|Alendo|no}}<br />
*{{User|AlexanderB|nl}}<br />
*{{User|Andyp|us}}<br />
*{{User|AntB|uk}}<br />
*{{User|Bob27|us}}<br />
*{{User|ChrisM|de}}<br />
*{{User|Cipri|nl}}<br />
*{{User|Clifs|us}} <br />
*{{User|csuke|uk}}<br />
*{{User|Dark_Link|se}}<br />
*{{User|Davil|at}}<br />
*{{User|dihedral|de}}<br />
*{{User|Doke|de}}<br />
*{{User|Dopefish|de}}<br />
*{{User|eJoJ|no}}<br />
*{{User|Elske|nl}}<br />
*{{User|EmiT|cz}}<br />
*{{User|Franco|hu}}<br />
*{{User|Gamer|nl}}<br />
*{{User|Giles|uk}}<br />
*{{User|Godde|no}}<br />
*{{User|Green-devil|dk}}<br />
*{{User|Hans|nl}}<br />
*{{User|hdp|us}}<br />
*{{User|h3rzb1ut|de}}<br />
*{{User|hzzzln|de}}<br />
<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
|valign="top" |<br />
*{{User|Ichi|nl}}<br />
*{{User|Ihmemies|fi}}<br />
*{{User|itsnotvalid|hk}}<br />
*{{User|Jinx|be}}<br />
*{{User|John|sk}}<br />
*{{User|Juustro|fi}}<br />
*{{User|Kejhic|cz}}<br />
*{{User|Kirov|ar}}<br />
*{{User|Kolbur|de}}<br />
*{{User|Kul|nl}}<br />
*{{User|Levi|de}}<br />
*{{User|Logix|us}}<br />
*{{User|MDGrein|se}}<br />
*{{User|mensi|ch}}<br />
*{{User|Microshit|nl}}<br />
*{{User|mitooo|fr}}<br />
*{{User|mixrin|ru}}<br />
*{{User|MooUK|uk}}<br />
*{{User|N101|au}}<br />
*{{User|Nazirro|pl}}<br />
*{{User|Nitehawk|us}}<br />
*{{User|Pikita|uk}}<br />
*{{User|Phil|uk}}<br />
*{{User|RaWt|no}}<br />
*{{User|Red|us}}<br />
*{{User|RichK|uk}}<br />
*{{User|RMJ|dk}}<br />
*{{User|Rob|us}}<br />
<br />
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
|valign="top" |<br />
*{{User|Satyap|in}}<br />
*{{User|sbn|be}}<br />
*{{User|SerriaRomeo|us}}<br />
*{{User|Shader|pl}}<br />
*{{User|Sian|dk}}<br />
*{{User|Skasi|at}}<br />
*{{User|Skidd13|de}}<br />
*{{User|S m w|de}}<br />
*{{User|Spectre100|us}}<br />
*{{User|Stoffe|se}}<br />
*{{User|strstrep|us}}<br />
*{{User|Talonius|uk}}<br />
*{{User|Tautrimas|lt}}<br />
*{{User|Teddy|no}}<br />
*{{User|Tim|de}}<br />
*{{User|Torben Paw|dk}}<br />
*{{User|Tussengas|nl}}<br />
*{{User|UnderBuilder|ar}}<br />
*{{User|Vinni3|uk}}<br />
*{{User|Volny|cz}}<br />
*{{User|Walle|be}}<br />
*{{User|welterde|de}}<br />
*{{User|Zakjan|cz}}<br />
*{{User|Zavior|fi}}<br />
<br />
|}</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11781User:Vitus2010-08-24T12:34:11Z<p>Vitus: That's all for now I think :)</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst converter==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Converter which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc2.sav|Savegame]] (r19523)<br />
<br />
<br />
==Tri-level designs==<br />
<br />
The aim of this savegame is to provide some examples of tri-level designs, so they are easily accessable without having to go through many other savegames. The collection isn't currently complete, though.<br />
<br />
The first two termini stations aren't new designs and you can already find them in many PSGs (e.g. [[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]] or [[PublicServer:Archive_-_Games_181_-_190#gameid_182|PSG#182]]). The next two are however new designs. Tri-level balancer reduces width of full (everything-to-everything) n->3 balancer by third and tri-level train reverser has enough capacity to keep ML flow undisrupted, while saving valuable space (for TL14, full turn might take as much as 46x42 tiles, while train reverser for such TL takes ''just'' 33x8).<br />
<br />
Resources:<br />
*[[Media:Tri_level_4.sav|Savegame]] (r20594)<br />
<br />
<br />
==Simple fail-safe conditional overflow & injection==<br />
<br />
Conditional overflows with conditional injection (unlike classic timer-based injection) are relatively new design, invented by [[User:V453000|V453000]] and used for the first time in larger scale in [[PublicServer:Archive_-_Games_181_-_190#gameid_188|PSG#188]]. Typical RoRo overflows (with one entry track) are fail-safe by design and don't need any further improvements to keep them working. On the other side, terminus overflows aren't fail-safe by design and need special approach: they require either waiting space (overflow with trains in waiting space) or waiting space alongside with fail-safe construction (trains do not use waiting space unless they would get stuck at entry signal). The second approach is better, because we want trains to wait either in station or in overflow depot (that's the main point of overflow, after all), however, this approach also involves tons of fail-safe tracks (which can get very confusing with large stations) and few flaws (waiting space is not prioritized, which can result in unwanted release of train in overflow).<br />
<br />
This new design makes sure we do not need fail-safe tracks (because the overflow is fail-safe by design), waiting spaces are completly prioritized and (like in the fail-safe approach mentioned above) only used if the entering train would get stuck.<br />
<br />
Resources:<br />
*[[Media:Simple_failsafe_overflow.sav|Savegame]] (r20279)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11780User:Vitus2010-08-24T12:29:19Z<p>Vitus: Fail-safe overflow</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst converter==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Converter which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc2.sav|Savegame]] (r19523)<br />
<br />
<br />
==Tri-level designs==<br />
<br />
The aim of this savegame is to provide some examples of tri-level designs, so they are easily accessable without having to go through many other savegames. The collection isn't currently complete, though.<br />
<br />
The first two termini stations aren't new designs and you can already find them in many PSGs (e.g. [[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]] or [[PublicServer:Archive_-_Games_181_-_190#gameid_182|PSG#182]]). The next two are however new designs. Tri-level balancer reduces width of full (everything-to-everything) n->3 balancer by third and tri-level train reverser has enough capacity to keep ML flow undisrupted, while saving valuable space (for TL14, full turn might take as much as 46x42 tiles, while train reverser for such TL takes ''just'' 33x8).<br />
<br />
Resources:<br />
*[[Media:Tri_level_4.sav|Savegame]] (r20594)<br />
<br />
<br />
==Simple fail-safe conditional overflow & injection==<br />
<br />
Conditional overflows with conditional injection (unlike classic timer-based injection) are relatively new design, invented by [[User:V453000|V453000]] and used for the first time in larger scale in [[PublicServer:Archive_-_Games_181_-_190#gameid_188|PSG#188]]. Typical RoRo overflows (with one entry track) are fail-safe by design and don't need any further improvements to keep them working. On the other side, terminus overflows aren't fail-safe by design and need special approach: they require either waiting space (overflow with trains in waiting space) or waiting space alongside with fail-safe construction (trains do not use waiting space unless they would get stuck at entry signal). The second approach is better, because we want trains to wait either in station or in overflow depot (that's the main point of overflow, after all), however, this approach also involves tons of fail-safe tracks (which can get very confusing with large stations) and few flaws (waiting space is not prioritized, which can result in unwanted release of train in overflow).<br />
<br />
This new design makes sure we do not need fail-safe tracks (because the overflow is fail-safe by design), waiting spaces are completly prioritized and (like in the fail-safe approach mentioned above) only used if the entering train would get stuck.<br />
<br />
Resources:<br />
*[[Media:Simple_failsafe_overflow.sav|Savegame]] (r20279)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Simple_failsafe_overflow.sav&diff=11779File:Simple failsafe overflow.sav2010-08-24T12:28:45Z<p>Vitus: Simple fail-safe overflow & injection (>r20279)</p>
<hr />
<div>Simple fail-safe overflow & injection (>r20279)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11778User:Vitus2010-08-24T12:00:39Z<p>Vitus: Tri-level designs</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst converter==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Converter which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc2.sav|Savegame]] (r19523)<br />
<br />
<br />
==Tri-level designs==<br />
<br />
The aim of this savegame is to provide some examples of tri-level designs, so they are easily accessable without having to go through many other savegames. The collection isn't currently complete, though.<br />
<br />
The first two termini stations aren't new designs and you can already find them in many PSGs (e.g. [[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]] or [[PublicServer:Archive_-_Games_181_-_190#gameid_182|PSG#182]]). The next two are however new designs. Tri-level balancer reduces width of full (everything-to-everything) n->3 balancer by third and tri-level train reverser has enough capacity to keep ML flow undisrupted, while saving valuable space (for TL14, full turn might take as much as 46x42 tiles, while train reverser for such TL takes ''just'' 33x8).<br />
<br />
Resources:<br />
*[[Media:Tri_level_4.sav|Savegame]] (r20594)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Tri_level_4.sav&diff=11777File:Tri level 4.sav2010-08-24T12:00:08Z<p>Vitus: Some tri-level stuff (>r20594)</p>
<hr />
<div>Some tri-level stuff (>r20594)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11776User:Vitus2010-08-23T21:22:36Z<p>Vitus: Keep the naming consistent</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst converter==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Converter which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc2.sav|Savegame]] (r19523)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11775User:Vitus2010-08-23T21:13:48Z<p>Vitus: broken link</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst convertor==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Convertor which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc2.sav|Savegame]] (r19523)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11774User:Vitus2010-08-23T21:13:17Z<p>Vitus: LED calculator</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst convertor==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Convertor which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==LED calculator==<br />
<br />
Long time ago, I got an idea to combine [http://www.tt-forums.net/viewtopic.php?t=42480&p=774856| my previous calculator] (simple adder) with [http://www.tt-forums.net/viewtopic.php?f=29&t=37902| LED counter]. The main point was to see, if such calculator would be possible to build and because of that, the calculator itself is fairly ''simple'' - it can add numbers up to 9 + 9. However, it is fully working and totally fail-safe (i.e. all logic gates are fail-safe). Most of the calculator is LED -> binary and binary -> LED converter, the adder is just small array of half bit adders at the bottom. Just note that the savegame isn't commented.<br />
<br />
Resources:<br />
*[[Media:Calc.sav|Savegame]] (r19523)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Calc2.sav&diff=11773File:Calc2.sav2010-08-23T21:13:15Z<p>Vitus: LED calculator (>r19523)</p>
<hr />
<div>LED calculator (>r19523)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11772User:Vitus2010-08-23T20:51:59Z<p>Vitus: Converter</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Green burst convertor==<br />
<br />
This tool is supposed to convert red signal of any length into few ticks of green signal. It is based on Fail-safe NOT/OR gate (mentioned above), but the distribution of prioritized lines is changed to provide green output only if the train is moving (i.e. when we can be sure the train isn't going to say in signal block for longer period). There are two possibilities on when to trigger burst of green signal - either at the beginning or at the end (of red state of input presignal). Convertor which provides green burst at the end (of duration) is much easier to build, however, in some cases we need green burst at the beginning (and it is also more logical). This layout then becomes pretty complicated, because we either have to use some tricks with priority or use a logic gate. See savegame for examples.<br />
<br />
This tool can be used for precise train counters and possibly some advanced logic systems.<br />
<br />
Resources:<br />
*[[Media:Green_burst_counter.sav|Savegame]] (r20594)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Green_burst_counter.sav&diff=11771File:Green burst counter.sav2010-08-23T20:51:40Z<p>Vitus: Green burst converter (>r20594)</p>
<hr />
<div>Green burst converter (>r20594)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=Oneway_or_Twoway_Presignals&diff=11770Oneway or Twoway Presignals2010-08-22T20:07:47Z<p>Vitus: </p>
<hr />
<div>[[Presignal_Basics|<< Presignal Basics]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Priority|Priority >>]]<br />
----<br />
<br />
=<center>Oneway or Twoway Presignals?</center>=<br />
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.<br />
<br />
==Part 1: The Station entrance problem with two entries==<br />
[[Image:Twoentry.PNG|thumb|center|404px|A RoRo station with two Entries]]<br />
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!<br />
[[Image:Twoentry2.PNG|thumb|center|404px|The Error: Signal A remains green]]<br />
How to fix this? Just change the combo presignal C to oneway (shown in first picture) or add an oneway combo presignal just after it, like in the next picture:<br />
[[Image:Twoentry3.PNG|thumb|center|404px|Now an oneway combo presignal is added after it]]<br />
With this layout, entry presignal A can't look for platforms F-H.<br />
<br />
----<br />
[[Presignal_Basics|<< Presignal Basics]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | [[Priority|Priority >>]]<br />
[[Category:Guides]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoentry3.PNG&diff=11769File:Twoentry3.PNG2010-08-22T19:58:17Z<p>Vitus: uploaded a new version of "File:Twoentry3.PNG":&#32;Better sign placement & fixed signal</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoentry2.PNG&diff=11768File:Twoentry2.PNG2010-08-22T19:57:43Z<p>Vitus: uploaded a new version of "File:Twoentry2.PNG":&#32;Fixed version</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoentry.PNG&diff=11767File:Twoentry.PNG2010-08-22T19:57:07Z<p>Vitus: uploaded a new version of "File:Twoentry.PNG":&#32;Fixed version</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoentry2.PNG&diff=11766File:Twoentry2.PNG2010-08-22T19:47:00Z<p>Vitus: uploaded a new version of "File:Twoentry2.PNG":&#32;Better sign placement</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Twoentry.PNG&diff=11765File:Twoentry.PNG2010-08-22T19:45:56Z<p>Vitus: uploaded a new version of "File:Twoentry.PNG":&#32;Better sign placement</p>
<hr />
<div></div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11746User:Vitus2010-08-13T20:20:05Z<p>Vitus: broken link</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Media:Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11745User:Vitus2010-08-13T20:19:19Z<p>Vitus: Fail-safe NOT/OR gate</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Fail-safe NOT/OR gate==<br />
<br />
As the name suggests, this logic gate can be used as both NOT and OR gate. Its design is similar to NOT and OR gates described in [http://blog.openttdcoop.org/2009/01/18/optimization-of-logic-logic-gates-part-ii/ this blog article], but is greatly improved.<br />
<br />
The NOT gate "part" might not be that useful, because circular NOT gates tend to have better reaction time (at low speeds), it is however speedproof (works well with high Logic Engine parameters) and cheaper to maintain (TL0.5 variant uses just one engine, while circular NOT gates have to use 4).<br />
<br />
Compared to the OR gate mentioned in blog article, it includes two key features: it works without waypoint and it is fail-safe. Normal OR gate has little chance (about 8-10%) to backfire everytime we change its input to red: if the train chooses inner circle (because the signal was green at the moment) and the signal changes to red before the train passes it, we'll likely get stuck train and wrong output (see savegame). It can be compared to previous (i.e. non fail-safe) SMLs - if we trigger priority while the train is shifting, we'll get stuck train and possible jam. It works without waypoint due to some PF magic. Normal OR gate can be changed in that regard too (also in savegame).<br />
<br />
This logic gate has been used as a part of waveproof system of PZG13.<br />
<br />
Resources:<br />
*[[Failsafe_gate.sav|Savegame]] (r20279)<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The speedproof concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Failsafe_gate.sav&diff=11744File:Failsafe gate.sav2010-08-13T20:19:17Z<p>Vitus: Fail-safe NOT/OR gate</p>
<hr />
<div>Fail-safe NOT/OR gate</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11743User:Vitus2010-08-13T19:32:56Z<p>Vitus: </p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
Some examples of how to deal with very high train speeds are included in savegame. The "speedproof" concept isn't very useful, because normally used parameter (3500) is usually enough to keep reaction time very low and higher values rarely improve this time. High parameter however greatly reduces reaction time of single-train based logic gates (up to some speed, of course). On the other side, the need for unnecessarily more complicated NOT gates likely outweighs the actualy gain.<br />
<br />
Resources:<br />
*[[Media:Speedproof.sav|Savegame]] (r20279)<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Speedproof.sav&diff=11742File:Speedproof.sav2010-08-13T19:31:12Z<p>Vitus: Speedproof logic gates</p>
<hr />
<div>Speedproof logic gates</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11737User:Vitus2010-08-12T17:09:57Z<p>Vitus: The parameter wasn't that high :)</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter 3816 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11736User:Vitus2010-08-11T21:21:21Z<p>Vitus: Better formating</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
=Ideas, concepts & other junk=<br />
<br />
==On-demand train stopper==<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
==Logic Engine 0.6 parameters==<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter at 5828 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
==Pathfinder behaviour==<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11735User:Vitus2010-08-11T21:17:12Z<p>Vitus: Added pathfinder savegame</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
==Ideas, concepts & other junk==<br />
<br />
'''On-demand train stopper'''<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
'''Logic Engine 0.6 parameters'''<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter at 5828 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
'''Pathfinder behaviour'''<br />
<br />
While pathfinder behaves pretty straightforward when it ''can'' find way to its current target, it might behave slightly unexpected with regards of lost (resp. orderless) trains. This savegame shows some problems and unexpected behaviour to be aware of. The savegame itself is little bit older and some problems aren't that strange (resp. are better understood) from today's point of view.<br />
<br />
After trying to understand how the pathfinder work in such special cases, I came up to simple conclusion. If the train can find route, use pathfinder debug to find the problem; if it cannot, it's better to "try & fail" (until you find some reasonable solution). Pathfinder is full of surprise!<br />
<br />
Resources:<br />
*[http://www.tt-forums.net/viewtopic.php?t=48678 Forum thread]<br />
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896)<br />
<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Pf_problem_v5.sav&diff=11734File:Pf problem v5.sav2010-08-11T21:16:39Z<p>Vitus: Collection of PF problems</p>
<hr />
<div>Collection of PF problems</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11733User:Vitus2010-08-11T15:48:45Z<p>Vitus: note about Logic Engine</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
==Ideas, concepts & other junk==<br />
<br />
'''On-demand train stopper'''<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description]]<br />
<br />
<br />
'''Logic Engine 0.6 parameters'''<br />
<br />
Just random note: Circular NOT gates with two trains <br />
*'''at TL1''' stop working with parameter at 5828 or higher<br />
*'''at TL0.5''' do not work, due to insane train acceleration<br />
<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus/Train_Stopper&diff=11732User:Vitus/Train Stopper2010-08-11T15:39:51Z<p>Vitus: note about fail-safe</p>
<hr />
<div>=On-demand train stopper=<br />
<br />
Train stoppers can generally be used in every case where we need exactly same starting conditions for all incoming trains. Such starting conditions can be either full speed (use cyclotron in this case) or zero speed, i.e. stopped train. While cyclotron is great tool, because (unlike train stopper) it keeps train's momentum, it has few major drawbacks - namely huge space requirements (the more with large TLs) and high percentage of missed join opportunities (can be improved by using cyclotron for two or more trains). On the other hand, on-demand train stopper is quite compact and percentage of missed opportunities is low (happens only while the train is slowing down). However, train stopper needs at least two additional trains to work (one for delay and at least one for NOT gate) and the NOT gate might require fast(er) train(s) to work without large delays.<br />
<br />
On-demand train stopper must be able to handle two different situations:<br />
*Train approaching at full speed<br />
*Queue of trains<br />
<br />
<br />
'''Relevant savegame:''' [[File:Train_stopper.sav]] (r20279)<br />
<br />
==Description==<br />
<br />
[[Image:Ts_01.png|825px|thumb|center|General description]]<br />
<br />
# '''Entry priority''' - makes sure the delay triggers soon enough; connected to NOT gate; used to stop trains approaching at full speed<br />
# '''NOT gate''' - stops (train in) delay unless there's train approaching to train stopper; used to stop trains approaching at full speed <br />
# '''Delay stopper''' - prevents delay from triggering again while the train is still waiting for join opportunity; also used to handle train queues<br />
# '''Delay''' - delays the green signal state to make sure train stops completly (by modifying input - generally high-speed priority)<br />
<br />
<br />
==Mechanism==<br />
<br />
[[Image:Ts_working_01.png|825px|thumb|center|Fig. 1]]<br />
<br />
Approaching train triggered entry priority, trains in NOT gate stop, delayer gets green signal and train (in delay) is released.<br />
<br />
<br />
[[Image:Ts_working_02.png|825px|thumb|center|Fig. 2]]<br />
<br />
Train in delay modifies state of input (high-speed priority in this case) and approaching train is forced to stop (note the red entry presignal which stops incoming train). Delay stopper is also triggered, preventing train in delay to start another circle (note the red entry presignal in delay).<br />
<br />
Once the joining train is gone, NOT gate starts working again, keeping train in delay stopped.<br />
<br />
<br />
[[Image:Ts_working_03.png|825px|thumb|center|Fig. 3]]<br />
<br />
This is example of handling train queues. NOT gate produces only green signal in this case (there's at least one train in entry priority), so delay stopper handles both triggering priority and stopping train in delay. In the picture above, joining train just left train stopper. NOT gate is green and there's no train in delay stopper, thus train in delay gets green signal and is released. While the second train slows down, delay stopper becomes blocked again, which in turn stops train in delay.<br />
<br />
The two-way path signal between delay stopper and entry priority just makes sure the delay stopper stays green long enough to properly trigger delay; can also be replaced with presignal system (not shown).</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus/Train_Stopper&diff=11731User:Vitus/Train Stopper2010-08-11T15:30:40Z<p>Vitus: Yet another train stopper</p>
<hr />
<div>=On-demand train stopper=<br />
<br />
Train stoppers can generally be used in every case where we need exactly same starting conditions for all incoming trains. Such starting conditions can be either full speed (use cyclotron in this case) or zero speed, i.e. stopped train. While cyclotron is great tool, because (unlike train stopper) it keeps train's momentum, it has few major drawbacks - namely huge space requirements (the more with large TLs) and high percentage of missed join opportunities (can be improved by using cyclotron for two or more trains). On the other hand, on-demand train stopper is quite compact and percentage of missed opportunities is low (happens only while the train is slowing down). However, train stopper needs at least two additional trains to work (one for delay and at least one for NOT gate) and the NOT gate might require fast(er) train(s) to work without large delays.<br />
<br />
On-demand train stopper must be able to handle two different situations:<br />
*Train approaching at full speed<br />
*Queue of trains<br />
<br />
<br />
'''Relevant savegame:''' [[File:Train_stopper.sav]] (r20279)<br />
<br />
==Description==<br />
<br />
[[Image:Ts_01.png|825px|thumb|center|General description]]<br />
<br />
# '''Entry priority''' - makes sure the delay triggers soon enough; connected to NOT gate; used to stop trains approaching at full speed<br />
# '''NOT gate''' - stops (train in) delay unless there's train approaching to train stopper; used to stop trains approaching at full speed <br />
# '''Delay stopper''' - prevents delay from triggering again while the train is still waiting for join opportunity; also used to handle train queues<br />
# '''Delay''' - delays the green signal state to make sure train stops completly (by modifying input - generally high-speed priority)<br />
<br />
<br />
==Mechanism==<br />
<br />
[[Image:Ts_working_01.png|825px|thumb|center|Fig. 1]]<br />
<br />
Approaching train triggered entry priority, trains in NOT gate stop, delayer gets green signal and train (in delay) is released.<br />
<br />
<br />
[[Image:Ts_working_02.png|825px|thumb|center|Fig. 2]]<br />
<br />
Train in delay modifies state of input (high-speed priority in this case) and approaching train is forced to stop (note the red entry presignal which stops incoming train). Delay stopper is also triggered, preventing train in delay to start another circle (note the red entry presignal in delay).<br />
<br />
Once the joining train is gone, NOT gate starts working again, keeping train in delay stopped.<br />
<br />
<br />
[[Image:Ts_working_03.png|825px|thumb|center|Fig. 3]]<br />
<br />
This is example of handling train queues. NOT gate produces only green signal in this case (there's at least one train in entry priority), so delay stopper handles both triggering priority and stopping train in delay. In the picture above, joining train just left train stopper. NOT gate is green and there's no train in delay stopper, thus train in delay gets green signal and is released. While the second train slows down, delay stopper becomes blocked again, which in turn stops train in delay.</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Ts_working_03.png&diff=11730File:Ts working 03.png2010-08-11T15:30:04Z<p>Vitus: Mechanism of train stopper (fig. 3)</p>
<hr />
<div>Mechanism of train stopper (fig. 3)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Ts_working_02.png&diff=11729File:Ts working 02.png2010-08-11T15:29:45Z<p>Vitus: Mechanism of train stopper (fig. 2)</p>
<hr />
<div>Mechanism of train stopper (fig. 2)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Ts_working_01.png&diff=11728File:Ts working 01.png2010-08-11T15:29:22Z<p>Vitus: Mechanism of train stopper (fig. 1)</p>
<hr />
<div>Mechanism of train stopper (fig. 1)</div>Vitushttps://wiki.openttdcoop.org/index.php?title=File:Ts_01.png&diff=11727File:Ts 01.png2010-08-11T15:28:51Z<p>Vitus: Description of train stopper</p>
<hr />
<div>Description of train stopper</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11726User:Vitus2010-08-10T23:00:46Z<p>Vitus: comment about savegame version</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
==Ideas, concepts & other junk==<br />
<br />
'''On-demand train stopper'''<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]] (r20279)<br />
*[[User:Vitus/Train_Stopper|Detailed description (WIP)]]<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitushttps://wiki.openttdcoop.org/index.php?title=User:Vitus&diff=11725User:Vitus2010-08-10T22:17:40Z<p>Vitus: Train stopper</p>
<hr />
<div>'''Born:''' 10.9.1991<br />
<br />
'''Home:''' Most, Czech Republic {{Flag|cz}}<br />
<br />
'''Contact:''' ICQ# 273 963 212<br />
<br />
'''My (O)TTD(coop) history:''' <br><br />
*Started playing TTD: about 1997 (got it as part of Tycoon Pack)<br />
*Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)<br />
*Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)<br />
*Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180<br />
<br />
<br />
'''Specialist on:'''<br />
*Train logic<br />
*Pathfinder<br />
*CL problems<br />
<br />
<br />
'''Weaknesses:'''<br />
*Rebuilding stuff<br />
<br />
<br />
'''Favourite games:'''<br />
*[[PublicServer:Archive_-_Games_121_-_130#gameid_121|PSG#121]]<br />
*[[PublicServer:Archive_-_Games_131_-_140#gameid_131|PSG#131]]<br />
*[[PublicServer:Archive_-_Games_171_-_180#gameid_180|PSG#180]]<br />
*[[ProZone:Archive_-_Games_11_-_20#gameid_13|PZG#13]]<br />
<br />
==Ideas, concepts & other junk==<br />
<br />
'''On-demand train stopper'''<br />
<br />
Train stoppers are perfect tools to make sure trains have same starting conditions. This becomes very practical for high-speed joins. Trains entering such join at full speed are likely to cause slowdowns on ML (if the line is densly packed, it can lead to huge chain reaction). This can be solved either by enlarging current priority (and that might lead to many missed join opportunities) or by using train stopper.<br />
<br />
On-demand train stopper is (currently) only kind of train stopper that is 100% reliable (i.e. stops train in every case). While I didn't really expect this concept to be used in "normal" games, it actually proved very useful in PZG13.<br />
<br />
Resources:<br />
*[[Media:Train_stopper.sav|Savegame]]<br />
*[[User:Vitus/Train_Stopper|Detailed description (WIP)]]<br />
<br />
<br />
To be continued...<br />
<br />
[[Category:Usual Suspects]]</div>Vitus