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.

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.

I hope we can make out the best games in 2009 soon.

After recent interests in self-regulating construction, there was an attempt to improve the usability of such designs. We have already seen self-regulating networks, where dummy trains transfer cargo onto ML trains, and recently self-regulating orders where vehicles could potentially go to all stations. What has not yet been done is to apply a form of regulation to point-to-point passenger games.

The main idea behind the concept is to have trains arbitrarily choose a station to drop their next load. While one could put each possible pair of stations into an order list, you would have to maintain the 240 possible pairs  for 16 stations, making it a big hassle. However, if you force trains in a certain direction by the network, you can keep everything more manageable. So if you can force a certain selection of trains in one direction, you are set.

The plan for PSG #157

In PSG #157, the idea was put to the test. The plan basically consisted of four flattened rings, where trains would be able to change on the shared parts. At three of the hubs, trains would have a choice of turning right or left. Using logic, trains were forced either left or right in turn. The two smaller hubs used flip-flops to do perfectly cut the train flow in half for each outer part. Due to the size of a flip-flop, the central hub was built using a timer. This timer forced all trains to the left for a few seconds, then right for the next few seconds, which again resulted in the stream being effectively cut in half.

Stations would need a much lower ratio – if they would get a 50/50 share, the chance was very likely that the train would drop the load at the next stop, and the chance of reaching the other end of the network would be minimal. Instead each station was given 1/8th of the traffic, which gave a good distribution without having the trains spending an eternity on the line. Due to traffic being halved, the outer hubs would take 1/4 trains each.

Station hub 2, where you can see the 1/4 selector

To pick one out of four or eight trains accurately, a mechanism was needed. The most used system consisted of a not gate (the MagLev loops at the top) which would allow the train in the counter (erail loops in the bottom) to move ahead one signal for each train. The loop had 4 signals, and thus four segments. By tapping into one of the segments, we could get a signal for every fourth train. The remaining pair of not gates (MagLev loops in the center) were used to always have one red signal and one green signal, so that trains couldn’t have second thoughts and still go the wrong way.

You can have a look at the game in the PublicServer Archive

As a special feature, there were new logic trains available. Going at supersonic speeds, they allowed the user to create extremely fast responding logic systems, and made completing the plan a lot easier. You can find them in OpenTTD’s online content section.

The current PublicServer game #151, is a multi-region map where different regions are connected by ICE trains (or rather Shinkansens in this case) but the local s-bahn is subject to individual design.



Setting:
The growing cities of my region needed a decent and high-capacity s-bahn in order to transfer all the people to the ICE terminal, but on the other hand I like to keep it simple and not create a new set of orders for each single station which needs separately looking after. Also I didn’t want to build a SRNW due to its higher space consumption and the little space available, having chosen one of the smallest islands around.

Self-regulating orders (SRO)
The solution is in using conditional orders to its full extend. In the example, my main s-bahn line connects four stations (each 8 tracks wide) on a LL_RR line to the ICE terminal (UET Uetani Shinkansen):

Convoluted as they may look, the principle of these orders are simple:
Go to the stations on the tracks in their order A,B,C,D. If the vehicle is more than 90% full, return to the ICE station and subsequently go straight back to the same station without stopping elsewhere. If the vehicle isn’t full, go to the next station in the sequence. Visiting the same station where the vehicle surpassed 90% load ratio (after dropping the cargo at the drop station), proved the most efficient orders with respect to obtained station rating and the total waiting PAX at the stations.

Ceavats:
A set of these orders may need some time till the trains reach an equilibrium. This might take longer the longer the list of visited stations is. The regulation will fail, if you add way too few vehicles. In this case, the vehicles will always visit the same station, some stations might not get the coverage they need.
Regulation might also fail, if way too many trains (or vehicles) are assigned to such set of orders. Nothing bad happens though, if no congestion occurs – but efficiency is then very low and cargo will go through all stations; the vehicle number might be limited automatically by giving an additional conditional order that the vehicle goes to a depot, if it is (nearly) empty when leaving the last station in the orders list.

Variations:

• This scheme can be varied, e.g. by issuing the orders such that the next station instead of the same is visited, after a vehicle returned to the drop station. The tests showed though, that the average station rating was considerably better when the same station is visited again.
• Another solution could be to always start with station A and only go to B, C etc, when the vehicle isn’t full. The disadvantage of this approach is that the further stations tend to get less vehicle coverage and thus a worse rating.
• Setting up such string of conditional orders involves many mouse clicks and is really tiresome. In order to ease the pain on the mouse, it’s certainly possible to lower the amount of conditional orders and only do a jump after each 2nd station or so. The experience in this game showed, though, that this was of limited value and results comparatively poor.

Giving the orders
Orders are always added before the highlighted line in the orders window. For a start it’s advisable to give simple goto orders to all stations which the vehicle should potentially visit, in the order they should be visited, if all stations only have very little cargo available.

• Then add an additional order to the drop station.
• Add a conditional jump, available in the drop down menu under “goto”:
  The mouse cursor will change and you now need to click onto the order where you want to make the jump to, if the condition is true.
• Done that you can actually set the condition:
  Select the thing you want the jump depend on:
  
  Select the value to compare the property to
  
  
  And set how to compare the property to the entered value:
  

Summary
These orders are certainly nothing new and they’ve been used here and there. But they could be taken to the extreme (and then they’d probably not only be self-regulating orders, but also PITA orders), and the same order list could be given for all vehicles which transport a single cargo. It’s especially useful, of course, for pax networks where vehicles seldom have full load but the optimum amount of vehicles per station varies.

Acknowledgments
Thanks also to HansNL who kind of made me look into this in more detail and play with the different possibilities of these conditional orders – and write it up. Thanks also to all other players on this PSG #151 which make this particular game into one of my nicer games again.

In the picture below you can see an example of my asynchronous approach which makes for a very simple but high capacity SRNW station:

Original stations:
The biggest cause for the complicated stations are the dummy trains. They have to be synchronized to avoid one stealing load from another. To accomplish this synchronization you would need special constructions and this can get quite complicated and messy, certainly with big stations. Another solution for the synchronization problem is to just make the dummy train a multiple of the normal trains’ length. But this is only useful to some extent, as super long trains/stations aren’t all that efficient.

General idea of the asynchronous station
To overcome these issues I tried an alternative, asynchronous approach. The idea is basically to make multiple stations, but put them adjacent to each other.

This way, all the stations get their own cargo from the industry(s) and no train can steal from another. By combining this with X-BT’s idea of “abusing” PBS signals, I was able to make the station very compact. It is possible to put two asynchronous SRNW platforms on a three tile width. You would also need ((2 * TL) + 3) tiles of length (even for a single station this is very little).

Construction
On the image you can see how easy it is to build a station like this. The dummy train only needs two orders to the same station (be sure they are set to the “Far End” of the station). It is necessary that you make the dummy station (at least) one tile longer than the TL to make it reverse and go to the other end of the station. By doing this it releases the piece of crossed track, the real train can go in and start loading. Depending on the train length, one tile might be too little, because the loading/unloading times increase when the TL increases).

Two solutions are possible:

• Make the dummy station longer so it takes more time for the train to start unloading/loading
• Use timetables to specify a specific delay for the dummy train when it is unloading

Also note that the PBS signal is facing in the opposite direction of the loading dummy train. This way the dummy train will reserve the crossing track and block the real trains from entering the station. Some smart use of PBS is used here, since the only safe spot for the dummy train would be in front of the PBS signal (as it’s facing the wrong way), all the way up to the next signal. This means it is possible to use any length of track after the dummy station, but you have to make sure it can be reserved (90° angles can be disabled and won’t work).

Possible problems
This asynchronous approach is somewhat against normal building rules, as you wouldn’t normally build separate stations to increase the transporting capacity for industries. As stated in the wiki an industry gives cargo to the two highest rated stations per cycle. It would appear that you can only use this approach for two platforms, given this limitation. In practice it scales well to more platforms, which is caused by the dummy trains. As there is always one train loading (dummy or real), the stations rating will remain “Excellent”. But, there will be small changes in the rating because of the gap when the dummy train is full and the real train enters the station to start the loading. These small fluctuations apparently are enough for the other stations to get cargo as well from the connected industries.

But not all is perfect. When you want to expand the pickup and add a new station to it, it will not start loading (if it is the third or higher station). This is because the rating of the new station will be 0%, so the industries see the new station as obsolete and ignore it. A simple solution is to (temporarily) connect the station to another (unused) industry, or one that only has a single station serving it. This way the rating can increase and the station can start participating in the asynchronous SRNW station group.

To conclude, an example of a synchronized multi-platform SRNW station which also looks pretty clean, created by Mark:

More info about SRNW at the WIKI.

When in a game is chosen for low terraforming, then this implies that you have to work with the terrain as much as possible. The image below shows an example.

The way the network looks is more important then the overall speed of trains or network throughput in general. Instead of flattening the sides of the mountain, bridges are constructed to keep tracks as level as possible. This type is often chosen in eye-candy games and is recommended to keep in mind during any game.

Medium terraforming

The most used terraforming style and also the most unclear one in ways of what exactly is medium. With medium terraforming you don’t flatten mountains to suit your building needs, but you terraform those tiles that are needed to obtain fluent networks that will not slow down trains.

In the above image several tiles have been lifted or lowered to have a fluent rail road.

For the exit of the station several tiles have been raised so that trains travel at the same height and can easily merge on the outgoing tracks.

High terraforming

By far the most easy rule that is around. Also known as “free terraforming” and it allows you to terraform to your needs or pleasure. So you are free to flatten that mountain in order to build your station or network.

“Coop style”

Not really to be a terraforming rule, though it distinguishes itself that for mainline tracks steps are created to climb a mountain. We don’t go around or make a steep climb, but we make steps so that trains have to climb only a single tile at once. Every step should be around 4-5 tiles long before the next rise comes. The rest of the landscape is left untouched as much as possible.

Conclusion

So now you have a general picture of the different terraforming styles we use on our servers. Remember it is not a rule cut out in stone, but a rough guideline to terraforming.

More info: Wiki: Terraforming