How to double
A doubled bridge should always be as short as is possible so the signal gap is as small as possible and the least amount of disturbance to the trains is caused. Because of this you should also keep your split and join as close to the bridges as possible. This means that right before and after your bridges you have one straight piece of track for your signals and right before/after that you have the split or join. Any extra track counts towards the signal gap and is thus undesirable. Waiting bays in front of the double bridges are of no use and should be avoided. The double bridge is a special case of the normal track and it should be considered as normal track and not as a traffic balancer. I know this sounds counter intuitive but it is what it is and when you look at the history (see the introduction) you’ll see why.
If you need to cross two lines after each other it is important to note that your double bridges should never influence trains with regards to corner lengths. I don’t join and re-split tracks when the distance of the join/split is shorter than the train length + 2. If you consider the first screenshot below then it would technically be fine to use it with TL3 or shorter but I personally prefer to do this only for TL1 because the train fits in between the presignal and the signal which marks the end of the double bridges. For TL5 this should not be done as it is slow for one of the paths. Which length you prefer is up to you but if the distance between the join and the split is more than train length + 2 then you should always join in between! If it is not then you should not rejoin and keep two different tracks side by side, note that you should view these lines as bridges with signals and it is prefered not to make any other splits or joins on them. This is shown in the second screenshot below(note that this is a special case as no proper joining and splitting can be inserted here).

The pathfinder way
Since the introduction of YAPF (Yet Another Path Finder) we’ve had the auto-balancer. This balances trains over two or more tracks depending on the status of the first 10 signals on those tracks. This is very useful for doubled bridges as the occupied bridge has a higher penalty and is less likely to be chosen. Naturally this is the most simple and the easiest solution, it does have a big drawback though. Trains can enter the split while both bridges are occupied and thus wait longer than necessary. In normal traffic this isn’t much of a problem but at places where the traffic is likely to stop, at a merger for example, or during a jam this can become a big problem. This is why it is preferred never to use this type of bridge doubling.

The presignal/PBS way
This kind of doubling comes naturally if you want to solve the problem with the last one: use pre-signals or PBS to stop trains from entering the splitter when they shouldn’t. The preferred method here is the pre-signal doubled bridges as the PBS method can lead to pathfinder issues in some very special cases. The main reason to not use PBS is that pre-signals are more controllable and the general use of PBS is discouraged. The only reason why you should ever use PBS is when there is too little space to place all the pre-signals.
When using pre-signals you should always make sure that you use one way signals as they work equally good as two way signals (the reason that there is a difference is outside the scope of this post). You should never have a signal between the exit signal and the bridge as this breaks the entire workings of the pre-signals and the bridges may break horribly. This shouldn’t even be done if you want waiting bays: double bridges are meant to keep trains running and if you design something that is meant to have a buffer for stopped trains then there is something essentially flawed in your double bridges. For the most ideal situation see the screenshot to the right.

Double bridges and splits
Although it is not entirely wrong it is not encouraged to make a regular split at the same place as the split for the double bridges. The main reason for this is because it leads to a signaling nightmare: should you put pre-signals only for the bridges? But then you block the branch line when both bridges are occupied as the trains get stopped before the split. Should you use regular signals? That leads to the same problem as described before and isn’t ideal either. The only real solution is to use PBS and rely on that too, but in general the use of PBS is discouraged. Another reason is that double bridges are a special case of normal track and you should view it as normal track in the most situations, except where you mix it with other things like splits and merges. That should never be done! It can lead to loads of different problems and it brings general ugliness to the game.

Double bridges and priorities
Sometimes you need to have a priority while there are also double bridges in the same line, this leads to an essential problem: how do you give priority to what are essentially two seperated lines? A solution has been developed to this and it is quite simple once you understand it. What happens is that you use PBS to split the traffic over the bridges, this has the advantage that to block signals (and thus pre-signals) both the bridges will be considered the same block which is ideal for the prios. What happens next is that you make one of the signals at the end a two way exit or combo signal (A in the picture), this enables the prio over the bridges. Due to the nature of YAPF and our configuration you need to change the other signal to two way too (B in the picture). If you don’t do this then it can lead to trains stopping at the PBS signal as sometimes the PBS signal can’t find a way across the bridges. The situation in the image is the most compact and ideal way to combine prios and bridges. There might be different ways to combine them but this is the most simple one.

Double bridges and synchronization
Keeping the network flowing under a high load is the main aspect of #openttdcoop. Due to a fundamental ‘flaw’ in OpenTTD trains take longer to cross diagonal track than straight track. This has quite the impact on doubled bridges as explained in this blogpost. You will barely notice the impact of this however, the only time you should notice is when are densily packed on the mainlines. That mostly happens when SML is involved or when the trains have very high acceleration. In all other cases it is still important to keep sync but not essential to building. I would advice to keep bridges in sync unless you need to move tracks around too much to keep correct corner lengths. There is nothing more annoying than needing to redesign your hub just because you’re trying to stick to something which isn’t going to influence the traffic.

Introduction

Hubs are one of the most key thing in any OpenTTD game that isn’t just point-to-point but is actually meant to be fun. Everyone built hubs, everyone had trouble building them, but everyone solved these problems a bit differently. In the very beginnings, a common thought process is “hub … well hub has to be 4way!”…

If you look at public server games for example 01 and 186, I believe you will notice that something has changed. In the early times, we built 4way hubs. Although we do not use this anymore, I will point out a few interesting things about these. Look at the very structure of the 4way hub – you basically can’t unify it! Each line often goes quite differently based on how the builder’s style is, sometimes using roundabouts, whirpools, just mess and rarely the whole hub gets reversed. The point behind this is, that 3way hubs look basically all like “an ultimate 3way”.

From there one could say “Well, what changed from that time when you still build the same design?” This is because long time ago, we focused on hub design. Now we focus on details, components, mechanisms, from which the hubs consist – which basically means: We care about proper building. Now if we return back to the beginning of this paragraph, we can see that using both “caring about design” and “caring about proper building” are just too much and the 4way hubs are becoming too large today . A very nice example gives MZG04 and PSG 173 – Pile transport, where we tried to re-play an old game and you can see how large a normal 4way hub becomes there… but of course they work better with proper build style .

This is for me the ultimate 4way hub. Built by nobody else than Mark himself, see how the tracks swap in directions. This makes “the sweet-spot” much easier and compact to build. (More about sweet-spot further down in the article.) The only downside of this styled hub is that it gets huge with wider lines because of more complex balancers you usually want to use . Although in this form, it is a true masterpiece.

Hubs as puzzle

Because hub designs are nicely shown on OpenTTD wiki (from which we use only the “ultimate 3way”), I will focus only on the segments of hubs – mergers, splits, uses of tunnels and bridges, and some minor design issues such as the sweet-spot. As an example-vault I will be using one of my savegames, this time a special game-for-article. Downloadable right here . (r20080)

Sweet-Spot

The hardest part of every hubs is where trains turn left. It is just like when you are driving a car, when you turn left, you cross everyone else. This is particularly evil in 4way hubs, but let’s put these aside. In a 3way hub you still need to solve this spot somehow. I highly recommend beginning the building of a hub with this spot – the centre of the hub, or at least make a planning how will it look. That way you reduce the possibility of “forgetting a connection” … which often results in some connections around all of the hub and so on. In the few following images I will show how you can solve this, with some commentary .

Out of the Hub

With this style one first gets outside the hub and solves the issues somewhere later. This is quite comfortable when you want to let the ML clear. (like when you do not want to tunnel it anyhow) Then you just swap the tracks when in safe position. This technique is very friendly for usage.
Demonstrated by Intexon in psg 173, BBH 02. (note that the hill disables sooner swap, otherwise it could have been smaller )

Solve Inside

Here we can see how Jondisti just makes the line A and then crosses it with B. This saves you space behind the hub, while sacrificing some inside.

Clash Together!

This is a style where you just go one over another, using bridges and tunnels. Great way especially if you can make it all close together and keep compact, because the 3 levels of track atop of each other are like +50% than normal tunnel over track in terms of tracks-per-tile. (if you want to bother with numbers, note that with 3level it is 200% – 100% from the one track and 50% from tunnel and bridge, because they are doubled therefore have half value but that isn’t important, just save space ) A nice example of this can be found in psg 186, MSH 03. Note how the hub is basically mergers-only.

Splits

Usually the part which is easiest. You just split lines from each direction. In this case, you can play with the actual order – if you split outer line first or outer, or both lines inside. Another decision-time comes when you bridge/tunnel the ML, or the split line.

Bridge vs. Tunnel

How old this conflict is? Like ancient and eternal … in splits it is probably most significant. As seen in the image below, you can save a lot of space with bridges made like this. Also, it is highly friendly with presignals which are just best unless you want to prio the bridges .

The basic rule of splits is “just use anything to get those lines away”.

Mergers

Something like a mirror-difference from splits. The hardest, most key thing mostly defining how the hub will actually look. (if you plan to build a good one) This paragraph will focus on systematic styles of mergers, not entirely the technique how they are built … because that would be just endless topic. The point is that basically any merger could work… the question is if you are lucky enough and the traffic goes just like you wanted. This leads to considering absolute balancing as an ideal case, but in many games, some “less” balanced mergers are just fine.

Not balancing “merge”

Balancing … why do we need balancing when this works? Note that if this ever worked, then it is ONLY a matter of luck that trains come from the right lines. If one relies on merging “outer with outer” and “inner with inner” or anyhow similarly like being smart and joining “outer with inner” and “inner with “outer: etc., it still is not balanced, thus relies on luck where trains come from. The greatest fail comes when you get to high amount of lines and you try to swap the lines where trains come just based on where you feel traffic demands it. Now end about such “mergers” and let’s get to something more serious .

Fully Prioritized Merge

As a Full priority I take such prio that gives absolute way – therefore preventing any slowdowns on ML by the joining trains.
This basically means that an amount of lines join others, giving them absolute prority. A style of joins typical for SLHs where we just want the SL trains give way to the ML ones. Although some people use these things also on BBHs and MSHs. Note that I am not saying it is a mistake! All matters on how you do it, the situation you are in, and so on.

Fully Prioritized Merge joining all lines

This is common for SLHs. One line joins all others. Typically looks like this. (for any amount of ML lines, just multiply/expand the design – also, when expanding you should toy with the waiting bays so it performs best) Here goes an example… joining only 2 lines.

Multi-to-multi-line join style

This implies that you want to give all joining lines an access to all of the joined lines. This is practically doable only with 2line join if we are talking about any reasonably simple and compact merger. Again, there are many techniques how to do this, but one note to be highlighted is: care about signals, making sensitive gaps is really needed in order to reach maximum throughput.

Fully Prioritized Merge joining some lines

This is often used when more lines join more lines. Typical examples in PZ05. The only “not ideal” thing is that again, it doesn’t balance completely, but well … you want to balance 4->8?

Half Prioritized Merge

This merging style would mean for me that I am merging two equally important lines. We have some priorities in order to make them choose lines better, but we do not have full priorities because it could make trains be stuck in them for too long.
This is typical for All-to-all balancers.
Here we can see a very smart solution by Mark. Using a prio that would be normally considered broken, because only one of these tunnels is prioritized.

All-to-all Merge

There have been quite a few forms of a merger that allows all entering lines all possible exits. These mergers are easy to build because they have quite a systematic look, they are pretty simple and they fit all forms, from 4->2 to X->Y. You can use this design with some priorities or without them. Under heavier loads the trains that join later can have trouble with joining if there are some priorities. Note the PF traps behind the merger. This makes balancing a bit better because it reduces train preferences of one or other line.(I do not want to say the PF traps are needed, they only are a good thing to be considered.)

Hub Composition

Although we still use similar things to “ultimate 3way”, there still are some techniques and styles, how to save space and keep throughput. Most of these things is smart usage of tunnels and bridges, and well … creatively pulling hub parts together by knowing which parts you are going to use (this also involves for example expecting high priorities, thus saving space for them) and working with terrain.

Bridge & Tunnel abuse

A super-powerful move while building hubs is using 3level tracks correctly (tunnel – rail – bridge). In general, bridges are good because they are more compact, but on the other hand, can not go under anything. On the other hand tunnels are harder to place, more space-demanding, but are able to go under for example a power plant or signal transmitter wall in the middle of your hub.

Multi-levels

In my example game I used only tunnels to make it a bit harder, so the demonstration of what to do is more significant and easier to replicate when you have both bridges and tunnels available, therefore I think more educational . (Note: tunnels still can go under each other if you have them in different levels! It only is much harder than bridge over tunnel. Theoretically, you could make Nlevel thanks to Ntunnel-tunnel-rail-bridge … but that would in most cases result in too large tunnels … anyways, it is also a possibility to be considered.)
Here come some examples of dealing with 3levels… BBH02 is particularly interesting because it does not keep the lines going the same direction together.

Directional Tunnels

This is quite a classic technique how to keep hub systematic and clean. Because you decide you will bridge the straight line still and still, you save some space in the other direction. This is usually done by “making parts” of hub and bringing them close together, resulting in each part having it’s tunnel.

Joining bridges together

The art of this style (also applies for other styles) where casual hub differs from a masterpiece, often is the ability to merge some “parts” together, making them for example both on one tunnel. This can for example save a lot of space. The basic point is you try to use as long tunnels as possible, and stuff there as much things as possible. This can be positively influenced by higher TL, because you can use even longer tunnels. The problem is – curves eat the space back.

Hub Operation

The most important thing is how the actual hub works. This is usually only influenced by the mergers. Since I have already noted some kinds of mergers and what situation they fit, I will not repeat it again and I will just show some interesting usages. (these are just examples to show what I mean, I can’t possibly show everything)

Merger Logics

This is a hub that leads mainly to the goods drop. ML is from A to B, C is the goods exit. What I want to show here is not just usage of mergers by type of hub or how it fits the landscape, but also how they work. See that while trains coming from the goods drop give priority on the A and B joins to the ML, while they merge equally on merge C. Definitely a good point to consider – think how is the hub actually be used.

Shifters and hubs

SML hubs are never very popular because they are just huge, so I will ignore these. I rather want to mention an idea I came up with … that is “simplification” of balancing. In MSH 01, I have built a balancer where trains from A have one track prioritized and one giving way (B). Of course entering the balancer from the way where you got to choose and give way to others is uncomfortable. Therefore we can shift trains (C) from that line to the “already joined” one. This is especially useful with badly accelerating trains because trains join the line without stopping. I used it only for LL_RR hub, but it could be used even in larger scales, having for example LLLL_RRRR coming from each side, you could shift and ignore those tracks in further balancing, making the mergers smaller and simplier. (note that I tried to place the shifters inside hubs, therefore adding no more space, but stuffing them there )

Conclusion

If I try to conclude what I have just said, then it is: Building a hub is considering possibilities, pulling the right strings, sacrificing the space on one side for more space somewhere else. Build hubs not “as always” but know what you want from the hub, know what do you expect from it, consider under what circumstances you are, consider how big will it be, think about it’s components and try to mix them together for maximum compactness. Usually the point you want to reach is “have as frequent rails as possible in the hub” – using all of the footprint the hub takes . All I have written is just a theory but still, most of building is practice, so this guide will not be enough itself . Build and develop your own style! If you put it all together, you can make a compact, complex and often a great hub that works just great. Now what are you waiting for, go bake someone’s brain off!

a long time since I blogged the last time, huh? Well, as I always pointed out, I’ll always stay in touch with ‘coop – and so I accidentally ran into a coopetition challenge at Sunday 4th!

As many of you may know, there is a cool mod out there named “Head to Head” for some reason: it features a map-generation logic which duplicates a landscape in order to offer a fair head2head competition gameplay! The mod is created and maintained by Yexo. Further information is to be found at the TT-Forums, the binary itself may be obtained at openttd.org.

Well, the game itself turned out to be a disaster to our #openttdcoop members! As Ammler went bankrupt at the very beginning of the session, planetmaker decided to keep the gameplay on a very slow pace and I made several wrong decisions in the first game year, thus giving Yexo a good opportunity to outperform all of us! Eventually, we did not even find a plausibly reason to disqualify him so we had to admit his total victory over planet ‘coop – see the screenshot at the bottom for further details

Finally, I want to thank Yexo (although he degraded us ingame) for this great mod and I have to add that I will definitely be around for a new coopetition session in the next days or weeks!

What causes this problem? It is caused by trains having incorrect orders, usually only toy trains go to this station but when a part of the network gets rebuild or when a hub has missing connections then trains might use other stations to detour and get on their way to their destination. If these detouring trains don’t have proper orders then they will stop at every intermediate station.
The solution to this is quite simple: just create non-stop orders. You can do this simply via the order window by clicking the non-stop button. This leaves a problem of its own however: you can easily forget this step. Fortunately the OpenTTD devs have made a solution for this: an advanced setting.

When you have this option enabled all orders will be non-stop by default and thus you cannot forget to do it manually. Every #openttdcoop player should have this option enabled at all times, you might even call it a mandatory option. Unfortunately we can’t force the server to have this option enabled as devs have moved it to the network save option category a long time ago.

While I am writing this post I should also note that all trains should have shared orders at all times if they have the same orders. If you’re cloning trains then you should keep ctrl pressed while cloning, this will automatically share their orders. You can also share orders by pressing ctrl when you use the go to button on another train. Doing this without holding ctrl will simply copy the orders without sharing it.
Why do we want shared orders? Because they are a lot easier to edit. You can change the orders of an entire group of trains by just changing the orders of one of them, otherwise you would have to do the same for every single train.
If you want to change the orders of a single train in a group of shared orders trains you will have to click the last option in the order list though (the one which says “– End of shared orders –” and hit delete, this will unshare the orders for this train. This also has the downside of removing the orders from the train though.

Logging

The rule on our servers is you sign your own work. This way we can see who’s done what. But it’s not a foolproof system, as players with bad intentions will most likely not sign their destruction, or respond to inquiries of other players. Because of this, admins had to guess who was responsible for such actions, which generally resulted in kicking the player who was the least known. Obviously this is not a fail-safe solution.

To combat this problem our server runs with a custom-written patch. This patch outputs certain game information to a logfile, one file for each game. Firstly it logs information from the server itself. Think of error reports, leaving and joining players, game status and password changes. Secondly it logs all the actions by the players, with their respective price tags and parameters like game tiles. And thirdly all in game chat is also logged. With this information we can accurately determine the culprit, ban him and then reload the game from an autosave to undo any bad changes. This way we are pretty much covered against any sort of in game mishap.

Privacy

Now you could consider me a privacy nut, I’m apparently one of the few who thinks it’s important and shouldn’t be given up so easily as it has been in the previous years. With that in mind I’d like to highlight the privacy side of this situation to calm the uneasy feeling you might get of the idea of being watched in game.

While we are logging everything that goes on in-game, only members, players that have shown to be trustworthy, get access to the log files. And they are not staring at it all the time either, because frankly, there are better things to do then stare at up to 20 Megabytes of text. The way the log is used is that we browse it with a tool whenever we notice bad behaviour on the server. This tool looks at the last X lines in the log, highlighting actions that could be the bad behaviour we are looking for. Think of the levelling of land, actions with huge price-tags and demolitions. This saves us the work of actually having to search for these things ourselves. Basically, we don’t look at the building in progress, we only search for abuse when it’s needed. Last but not least, logs will be deleted after a while. Generally we keep around 5-10 games worth of logs and the rest is discarded.

Statistics

The majority of our playerbase comes with a background in exact sciences, like me. With this in mind, I thought it would be a good idea to generate statistics from our logfiles. Because who doesn’t like statistics? So more then half a year ago I decided to write a program in Java that parses those log files and generates statistics out of them, like the number of lines typed and money spent.

The program is now hosted on our own Dev server. After a long time of neglecting it’s maintenance, a rewrite to compensate in a change of style and the fixing of some bad bugs, the program is finally up-to-date and all logs excluding the current one are processed. The results of this can be found here. And no, this is not useful. But it’s always interesting to have a look.

Future work

Right now I am working on a system that plots the tile information of actions into an image. Combined with some image processing, it should be possible to build a mini-mini-map, not based on how it looks, but based on how much has changed. This is an example of how such a map could look like:

I wonder if anyone can guess the game number from that image. But once again, not useful, but probably interesting to see. Besides that there is some work to be done on the usability of the program itself and adapting it for use on other servers as well. If you have any more ideas, comments or suggestions, feel free to post your them in the comments or let me know on IRC.

Kinds of splitting

The first and most elementary way how to split trains is by orders. Go to spot 1, go to spot 2, simple, easy, effective. This we use in “normal” cases.

But what happens when we want to split some trains somehow conditionally? Just some?

Split “if there is space”

Based on the power of 2way signals – this one we use mostly in SRNW where any train goes into the entrance, just if there is free space for it (don’t forget to make there at least full-TL waiting space).

Sometimes trains behave extremely dumb and don’t like the 2ways enough. Then we have to make it forced a bit more. Preferably by closing the other exit. This is the way: NOT-gated waiting bay forces the train to get in if there is no one. This could result in a deadlock at the moment when train is just passing by and suddenly the path closes.

This can be easily solved by making it fail-safe.

This still has a critical spot – if two trains come very close to each other or just jam here, it is possible that the fail-saving mechanism will be overridden. As an insurance there could be added a combination of entry and exit signals, making it absolutely immune to any failure.

Splitters “am I the one?”

When there are multiple types of trains on the network/split line, the splitter has to recognize them and pick the right ones. Probably the most reliable kind of this so far is the Train Length splitter/recognizer, letting in only trains of a certain, higher, or lower TLs than a set number. Mark and me already wrote something about these so I will just link you to these:
Mark’s train length splitters
V453000’s train length splitters

Splitters “you go this way, I want that way!”

This is the most interesting type of splitters because we have an input of all-the-same trains and we want to split them into X equally loaded parts (or any other ratio).

Gap splitter

The probably first, simplest and least effective is a “gap splitter”. It is relying on split, if one of the lines is already occupied, halving the maximum possible number of traffic each one of these can get.

As it is just the maximum, it fails when the maximum is not reached – when two trains come in an inverval, resulting in one of the output to be more stressed than the other one. This is a good split for station entrances, as we only care about the maximum throughput, mostly.

Probability splitter

Probability splitters are based on a period of time in which they are released to a certain output. This means that a timer-style train goes in some cycle through a number of bays. It’s position (related with bays) influences which of the splitter output paths is going to be open.

This type of splitter has no problems if trains come in in long intervals but as it is based “just” on probability, in many cases it could be not precise enough.

Similarly as the “is there space?” this also tends to deadlock when the green just suddenly swaps to red when a train is passing by. This situation isn’t that serious though, as the blocked train is going to be released in the next cycle when his path is green again. Still, this could result in jams and slowdowns and can be fixed by fail-safe exit signal again.

Flip-flop

The best splitter mechanism in terms of precision. The flip-flop can be used to split into two streams, mostly used in ratio 1:1, for which it’s best.

As you can see, there is a memory (1) which gets red if a train passes by and stays red for an unlimited period of time unless it is erased. Therefore this path if closed because the entry combo signal into the path looks at the memory status. But hey! The other path is still open! So the next train goes there and locks the other memory. At the same time, the NOT gate erases the first memory and another train can pass into the first path because it’s memory is now erased.

A very important element for flip-flops is response time of the NOT gates. It has to be able to erase the memory before another train gets there. If we have not fast enough not gates, we have to use longer TL to give it more time or use a different type of splitter.
There are also possible modifications of this mechanism, mainly change of the ratio to 1:2 or more. It simply is just making more memories to one path. See this image from PSG 175.

The flip-flop can also be easily used for 1:1:1 split into three lines. Image is also from PSG 175.

Splitter “1,2,3 am I the one?”

This kind “counts” trains and releases every Xth train out to the split output. The rest is kept on the line from which we split. The mechanism is based on a NOT gate which detects any incoming train into the splitter and a cycle bay-based train who changes it’s position in bays with each train passing through the splitter. When the train reaches a certain bay, it splits the train. A key thing is selection of the bay-cycling train which must pass just to the next bay when one train passes the splitter (with too fast trains it could happen that the cycle train skips bays it should stop in, resulting in inaccuracy).

In this picture you can see the “detector NOT gate” (1) which releases the bay-cycle train (2). There are 4 bays in the cycle, meaning that every 4th train splits to A because the bay-detector NOT gate (3) opens that path and at the same time B is closed (4).

This type of splitter is best used with logic trains for NOT gates as we like to have it as accurate as possible. The hugest advantage of this type is it’s flexibility. You can make it split in any ratio from 1:3 to 7:86 or whatever your maniacal mind comes up with. I can think of only only a few problems … the first is – you have to try which train is best for the bay-cycle train. The second thing is that trains must not jam on this mechanism as it could break it completely. Also important is to put the detector close enough to the split, so no the train that is to be split releases itself (doesn’t necessarily have to but it is “safer”) and at the same time the mechanism must have enough time to react and open the split path.

Conclusion

All in all splitters are one big bunch of fun and could be very handy in some situations, especially when SRNW’ing or just in some other special moments when the dumb trains need an extra guidance. As you might’ve seen, I mostly use the flip-flop. That is because if I need to split for example 1->6, I just use three flip-flops in a row (1->2 and 2x 1->3), such as The Hypnotizer in PSG 179. I’m looking forward to more interesting things that could evolve from these basic ones I have talked here about. Thanks for reading and don’t get mad!

Sign spam in PSG 160 where this station was shown for the first time. ((See that many signs have DO NOT, WHO REMOVED? And so on… I would like to get rid of some of these ))

In not only the last several PSGs we encounter one element – difference. Of course everyone of us is different and thinks in different ways. This can mostly be seen on spots with many signs like: Shouldn’t here be PBS? Shouldn’t here be presignals? Shouldn’t here be <whatever>? The solution often differs, but for example in case of presignals x PBS it often influences at least positioning, often PBS things are a tile shorter than presignals. I am talking about the fact that quite often people ask or just straight modify other’s work without thinking about it and not trying to get the idea that is behind it and why it is built as it is. Sure, we are cooperators and we should talk about things but we don’t have to talk about everything a million times.

The result of this article is NOT that I would like to unify our minds to make sheep of us, neither to start making some conventions. No. The thing why I write this is that I want to ask you what would you say if I started blogging some kind of occasional revue where would be noted some interesting things built around our servers, with some notes from authors and some shown possibilities with clarifications and FAQ. That way people could learn faster, and of course it would prevent some errors and needless questions. What is your opinion?

Here follows a taster version, as episode number 1:

Advanced Building Revue 01: The conditional overflow

This is the first part of this series. There also will be notes in italics, which are related to the article above.

In the latest several PSGs we had the possibility to see V453000’s pickup station with conditional overflow. In this Advanced Building Revue part we will take a look into that.

The purpose of this station is to have an overflow which doesn’t affect trains under normal circumstances. (normal circumstances = there is enough supplies or empty platforms for the incoming train, therefore no train needs to wait). The whole construction is fairly easy:

Here we can see the most basic form of this design. It is TL3, 10 platforms per line. Let’s get to building.

The most important thing is – as almost always – signaling. The train just passes by around the twoway signals if they are red (if a train is already waiting there). This way they try each of these and only in case there is no one green, it will be sent to the overflow.

The penalty and PF trap are in some cases optional as the depot is a penalty itself and trains *should* find the path to the station even that way. Both the penalty and the PF trap are highly recommended to be built though, making 100% sure it will work properly.

Also an essential thing is using a timer at the depot join. This makes the train regulation more powerful, because trains that overflow can not get that easily back to the network, so if there is more than needed trains, they are quickly put into the overflow depot but then the overflow “tries” slowly how many can be sent back to the network.

Why that many platforms? It isn’t absolutely needed but we want to make the station able to work as a completely ordinary station without overflow unless the overflow is needed. Which is basically the point of being conditional.

Also don’t forget about appropriate waiting spaces behind the twoway signals! They can be longer but definitely not shorter than 1x TL.

Known Modifications

Platform number

The first very vital modification is to reduce number of platforms – mainly in case there is not enough space. It truly is possible to reduce the number of stations. (don’t ask how exactly as it depends on situation – trains, wagons) One is sure: if we reduce number of platforms, we stress the overflow more. This can result in a slow/jam in the overflow if stressed too much!

Ro-ro or terminus

Another very important and often used modification is that this station can be made in both ro-ro and terminus variants. The ro-ro just bridges the overflow track, merges and just goes away wherever needed.

Frequently Asked Questions

Q: Why overflow?
A: The delivery of raw materials fluctuates, trains come at least a bit in waves, the production of the secondary changes. In order to regulate the amount of trains that pickup the products is very nice to use the overflow because it prevents any jams that could even cause some ML congestions.

Q: Why not presignals?
A: Because we want the trains to just pass around the normal signals, therefore we do not need the signals to be connected to those in from of them and interact with each other. It would actually waste most of the mechanism.

Q: Why timer?
A: The timer is not needed if the priority of the depot join is long enough but it is a very nice tool how to make trains stay in the overflow longer when they happen to overflow, so they stack in the depot if there is just too much of them. The settings of the actual delay of the timer has to be adjusted with situation.

Q: Why the PF trap?
A: To ensure that the trains would not stay waiting in front of one of the twoway signals, meaning that it can not find a path through the overflow. PF trap is making sure it works. A penalty is essential to be used in that path to make sure trains try to go into the real station first before they consider going to the overflow.

My opinion

This station is a very effective overflow-styled design and I really like it used for pickup stations. In my opinion it is best for basically any TL, if there is enough space but note that lower TLs have less trouble with the slow at depots which can either require doubling of depot with higher TLs or it could mean that it is better used with lower TL. All in all pretty solid thing.

My network ended up with 890 trains that travelled around a ML ring. Since all the primary stations where on the ML the game ended up only having MSH and BBHs. This meant that I have to balance all of the tracks on and off the main loop. The loop was LLL_RRR most of the way around excluding the northern section which was LL_RR and L_R only in some sections.

When I originally built the factory area is was a small 8 platform station with 1 entrance and 1 exit. It evolved into a 16 platform station with 3 entrance and exit lines which are each in turn mixed over the ML in all directions

This image is of the busy LLL_RRR MSH to the factory drop where the main line turns 90 degrees. The factory is serviced by Grain, Livestock and Steel and has a monthly output of around 12,000 crates of goods. With this game I have transported every Cargo type that it is possible to transport. This has resulted in many interesting track combinations and layouts.

I started the game without a network plan (this is never a good idea). I used a B2B style game, where I used a fix TL of 5 tiles, and a fixed loco (RE 4600) from the 2cc set. This train is very good for passengers and goods as it is very fast, and has a high tractate effort, which means it won’t slow while pulling loads up long grades.

My first line linked the forests of Drefingway-on-sea to the sawmill at Fultborough. When first built this link was L_R only. Over time demand from the forests and other trains on the network meant I had to upgrade the line to LLL_RRR most of the way for this link.

I also dedicated 2 large cities on the map which I transported passengers between and I also dropped all of my goods at these 2 cities. Both cities ended up to have more than 200,000 population and where close to very busy junctions within my network.

To handle to traffic I made sure each industry had its own area on the map. This meant that I could dictate cargo direction to the drops in order to balance the network. This can be seen in many locations around the map.
If you want to see my full works please download my saved game file: Blog Game

To run the game you will need openttdcoop GRF pack 7.3, and all other GRFs can be found on bananas. You will also need r18985 or later

How it works

The functionality is as simple as genius. The joining train has influence on the priority line by adding OR logic. The exit-signal of the joining trains track turns green again after a train made a decision. If in the meantime a train on the mainline blocked the entrance it stays green, because the OR logic determines it (the joining train unblocks itself, because the exit-signal turns green). If a train is already on the mainline, both signals are red at the point the joining train has to make the decision and won’t join.
Well, if you didn’t understand anything its either my english or you should read it again. Though pictures say more then 1k words. Here we go:

Situation 0

This is a very basic situation, a train is on outer line and wants to go the the waypoint. No trains are coming on the mainline.

Situation 1

The train entered the block with the exit signal and it turns red.

Situation 2

The length of the track from the exit signal block to the joining block is exactly as long as one train (TL). If you have trains of different sizes on one track you either use the TL sorter first or you have a neat idea.

Situation 3

The train choses, the correct track. This isn’t too interesting because there isn’t a train on the ML. Though you might have notice that the exit signal turned green again right before the train passes the entrance signal.

Situation 4

Now we have the same situation as before, but a train is coming on the ML. The train on the sideline already decided to join the ML.

Situation 5

The train on the ML now activated the priority line and the entrance signal turned red. This is a bad situation, because the train on the SL wants to join now. and the other train is far away, joining isn’t a problem.

Situation 6

Luckily in the same moment the exit signal turns green again and therefor also the entrance signal, the train on the SL can join.

I really love this behaviour and you can replace joiners with “overtaking space” with this system. You can probably reduce the size of SML layouts we see nowadays and the good old 1<2 join or even more might become attractive again.

Quadruple Full-Featured Cyclotron

And what I wanted to show you, I modified Pitt2’s Cyclotron, it comes now with 4 entrance possibilities which increases the chance of a join drastically. And for high-speed trains the additional way shouldn’t be a problem.

So let’s talk about stations… it is basic TTD element… every player made some… some designs were fancy and some ugly… most working (i hope . Some stations are bigger than others, a network wide dedicated drop or pickup would be an example. For obvious reasons such stations, in terms of number of platforms, are wider (or much wider) than lanes within the network the station is hooked to and that posses two tasks competent engineer should handle. These tasks are designing station entry and exit.
I would like to direct your attention to exit from megastations; First, it is usually a more complex task, since not being able to move trains after they been served – clogs the station and network itself rather quickly. And, on the other hand, train stream with totally random spacing is hurting network performance due to the fact that more spacing means less trains per lane and a need to upgrade amount of lanes while at same time it also is damaging factor to ability for merging traffic to find gap to get onto the net. And that’s where new concept comes to play… it is a network contraption which merges trains in a way which creates more efficient train spacing and hence better train stream.
There has been 2 concepts mentioned on PS games. The are “compressor” by Mark and “packer” by yours truly. They appear to do similar things but are to be used differently. And usage depends greatly on type of network/station they are attached to.

Compressor acts based on slowing down randomly spaced trains and grouping them together to be released as a pack with minimal intervals inbetween. This is essential for most networks and should be done in case if traffic merges into lanes, because single larger gap instead of many smaller ones means easier entry, but at same time it relies on having available room on the lane it operates on, as in if there are too many trains, stopping them would mean stopping the ML. In station context compressor can and often should be applied to exit from pickup stations, reason being – trains leaving pickups are often go in waves due to fluctuations of production (and many other factors), thus organizing these waves can be a real saver for busy network with lots of merging traffic. PSG#131 has functional example of Mark’s compressor on few lanes of ML:

Packer while being pretty much same by design acts a bit different. The goal of packer is absolutely streamline train packing process to extreme, it produces train stream with no gaps as long as station provides enough trains. After such process these lines are literally impossible to merge into, hence applicable usage is very different – packers should not be used for affecting lanes where trains are supposed to merge often, it will lead to SL bottlenecks once packer kicks into highest gear. That being said, a perfect place and role for a packer is optimizing train stream going from network drop, on network with empty/full track separation, one of best example would be SRNW – aside from overflow injection, dummy trains don’t ever join to lanes that go from drop. A working example of such application can be seen in PSG#170, where a very ugly, but functional version of packer deals with 3 lanes of incoming traffic (badly spaced due to merging) compressing them into 2 tight packed lanes.
After thinking about how tiresome is the process of combining network elements to slow down trains in order to achieve desired merging pattern, I decided to do it simple way and integrate it into station:

There is also a savegame available with working example of this packer, but due to OpenTTD bugs and tight packed stream hitting the station on the other side of the loop there are some issues with station entry as well as “FS1063-safe curves” had to be used in order to maintain gaps between trains. Station size for a single lane is also quite unusual since it has 10 platforms, but that was necessary do demonstrate the efficiency of such device.
Core basis of this packer is spacing station in a way applicable for how trains need to be spaced on ML, essentially for proper function minimal gaps between trains should be 2 signal intervals (2×2=4 tiles for most coop games) and hence 4 tiles between stations give you desired spacing while timed release is powered by a ticker train which run on schedule. This is hardest part – you actually have to figure out how many ticks trains should wait on station before second batch should be release w/o running into trains from previous set, so some testing is required. The release mechanism is also main design difference from compressor which is “capacity” operated with gate logic holding trains in place while pack assembles.

The point i am trying to stress – in most cases performance of network can be greatly affected by producing more efficient train streams and compressor and packer while being similar by nature should be used with caution since they do produce very different results.