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:

• PSG#121
• PSG#131
• PSG#180
• PZG#13

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

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)

To be continued...