Difference between revisions of "User:Vitus"
From #openttdcoop wiki
m (That's all for now I think :)) |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 39: | Line 39: | ||
*[[Media:Train_stopper.sav|Savegame]] (r20279) | *[[Media:Train_stopper.sav|Savegame]] (r20279) | ||
*[[User:Vitus/Train_Stopper|Detailed description]] | *[[User:Vitus/Train_Stopper|Detailed description]] | ||
| + | |||
| + | |||
| + | ==Fail-safe NOT/OR gate== | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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). | ||
| + | |||
| + | 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). | ||
| + | |||
| + | This logic gate has been used as a part of waveproof system of PZG13. | ||
| + | |||
| + | Resources: | ||
| + | *[[Media:Failsafe_gate.sav|Savegame]] (r20279) | ||
| + | |||
| + | |||
| + | ==Green burst converter== | ||
| + | |||
| + | 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. | ||
| + | |||
| + | This tool can be used for precise train counters and possibly some advanced logic systems. | ||
| + | |||
| + | Resources: | ||
| + | *[[Media:Green_burst_counter.sav|Savegame]] (r20594) | ||
| + | |||
| + | |||
| + | ==LED calculator== | ||
| + | |||
| + | 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. | ||
| + | |||
| + | Resources: | ||
| + | *[[Media:Calc2.sav|Savegame]] (r19523) | ||
| + | |||
| + | |||
| + | ==Tri-level designs== | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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). | ||
| + | |||
| + | Resources: | ||
| + | *[[Media:Tri_level_4.sav|Savegame]] (r20594) | ||
| + | |||
| + | |||
| + | ==Simple fail-safe conditional overflow & injection== | ||
| + | |||
| + | 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). | ||
| + | |||
| + | 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. | ||
| + | |||
| + | Resources: | ||
| + | *[[Media:Simple_failsafe_overflow.sav|Savegame]] (r20279) | ||
| Line 48: | Line 100: | ||
| − | Some examples of how to deal with very high train speeds are included in savegame. The | + | 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. |
Resources: | Resources: | ||
| Line 64: | Line 116: | ||
*[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896) | *[[Media:Pf_problem_v5.sav|Savegame]] (r20279; fixed PBS overflows to work with >r19896) | ||
| − | |||
| − | |||
[[Category:Usual Suspects]] | [[Category:Usual Suspects]] | ||
Latest revision as of 12:34, 24 August 2010
Born: 10.9.1991
Home: Most, Czech Republic 
Contact: ICQ# 273 963 212
My (O)TTD(coop) history:
- Started playing TTD: about 1997 (got it as part of Tycoon Pack)
- Started playing OpenTTD: 2008/09 (first version I played was 0.6.3)
- Discovered #openttdcoop: Feb/Mar 2009, PSG#131 was first coop game I saw (of course I was shocked!)
- Joined #openttdcoop: Apr 2010 (really that late), participated in PSG#180
Specialist on:
- Train logic
- Pathfinder
- CL problems
Weaknesses:
- Rebuilding stuff
Favourite games:
Contents
Ideas, concepts & other junk
On-demand train stopper
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.
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.
Resources:
- Savegame (r20279)
- Detailed description
Fail-safe NOT/OR gate
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 this blog article, but is greatly improved.
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).
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).
This logic gate has been used as a part of waveproof system of PZG13.
Resources:
- Savegame (r20279)
Green burst converter
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.
This tool can be used for precise train counters and possibly some advanced logic systems.
Resources:
- Savegame (r20594)
LED calculator
Long time ago, I got an idea to combine my previous calculator (simple adder) with 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.
Resources:
- Savegame (r19523)
Tri-level designs
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.
The first two termini stations aren't new designs and you can already find them in many PSGs (e.g. PSG#180 or 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).
Resources:
- Savegame (r20594)
Simple fail-safe conditional overflow & injection
Conditional overflows with conditional injection (unlike classic timer-based injection) are relatively new design, invented by V453000 and used for the first time in larger scale in 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).
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.
Resources:
- Savegame (r20279)
Logic Engine 0.6 parameters
Just random note: Circular NOT gates with two trains
- at TL1 stop working with parameter 3816 or higher
- at TL0.5 do not work, due to insane train acceleration
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.
Resources:
- Savegame (r20279)
Pathfinder behaviour
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.
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!
Resources:
- Forum thread
- Savegame (r20279; fixed PBS overflows to work with >r19896)
