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!

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.

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.

• Every line that goes in goes out n-1 times (n times if you allow turning around)
• Merge after split – merge as late as possible

In addition there are a few OpenTTD-specific building rules:

• Curve length must be considered for all curves
• Bridges and tunnels must be doubled for flow
• When doubling bridges and tunnels make sure the lengths are the same (“syncing”)

There is nothing magical about these rules. But once you start building, you’ll find out that most of them are hard to obey, especially because usually there are lots and lots of crossings in a hub. Furthermore all those hubs tend to become unmaintainable, leading to jammed connections that nobody knows how to solve. So is there a way to get rid of the crossings and get a more clean design?


Let’s take a look at the image above: it shows a 4-way single-line hub following the general rules (without the building-specific ones): every line that goes in goes out n-1 times. Merging occurs right after the hub, allowing for easy balancing or whatever you desire.

The magic of this design is that it is really easy to understand and it is extensible. You can use this to build a 6-way or even an 8-way hub – it just makes the hub bigger, but not more complex!


This image shows the same technique applied on a 6-way hub. You can see that there is no difference to the 4-way hub but a bigger number of lines going around.
The building principle is as simple as it can get: inject an incoming line to the innermost ring and lead out all lines in parallel when building an exit. The outermost line leaves the ring completely when it has reached the n-1^st exit.

Casting this into real rails

To test my theory I’ve designed 4×1 hubs and 4×2 hubs without signals but with doubled bridges and a curve length of 8.


The image above shows a single line 4-way hub using the given schema. Of course there’s room for improvement, e.g. saving space by bypassing the first exit and thus saving a row of bridges:


I left out the merging in my design, to show that any kind of merging (just connecting the lines or building load-balancers) can be applied separately for each exit.

The usual #openttdcoop hub is at least for mainlines of 2 tracks. So of course I had to build 4×2 hubs too:


As you can see inserting 2 tracks at once is absolutely the same as inserting 1 track. Taking the tracks out just requires more rows of bridges. Of course there’s also an optimized version of this hub:

Summary

The given hub design is quite similar to the roundabout hubs frequently used by inexperienced players (or if the network load is not too high), but without the merge-before-split disadvantage. I decided to name the hub design spiral hub (because the lines move 1 step outward at each exit).

Advantages:

• Easy to understand, easy to build and maintain
• Extensible
• Can be used for any sensible amount of tracks and entries/exits
• No jamming inside the hub if merger/load balancer is far enough outside
• Never ever merge before split
• Allows for easy exit-specific load balancing
• Quite compact regarding the used area (you can build them around mountains, towns, lakes, …)
• Can be used with mixed mainlines (e.g. rails + maglev)
• Can be built to allow turning around (just take out the lines one exit later)
• Fits anywhere where you can put some parallel lines with long curves

Disadvantages:

• Quite a big overall footprint
• Longer travel distances than e.g. for straight east-west lines

After building a few of these hubs I think the general way of designing them should be as follows:

• Build the hub according to the general schema
• Optimize it to use shortcuts where you really need them to improve performance

As long as the general schema is not broken, the hub will always work as expected.

I’m looking forward to testing this design in one of the oncoming Public Server games. Comments are welcome!
Have fun!

davil

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

Unlike what seems te be the case there are only two variables which make up the maximum speed of a train to pass through a curve: Curve Length and Railtype. The train’s maximum speed and TL are irrelevant. A single 45 degree turn doesn’t slow a train down unless followed by a second one before the entire train has passed the first. The formula for calculating a normal rail curve’s maximum speed is as follows:

Max. Speed in km/h = 232 – (13-CL)^2

Interesting fact is that the source code considers what we call a half diagonal tile as an entire tile. We would call the leftmost picture a CL5 (or 4.5) curve and the upper a CL9 curve, while they’re both considered 9 tile curves by the formula, meaning they allow for the same maximim speed. So when using the formula you should count the half tiles as full tiles. As shown in the picture below.

Different rail types use the same formula but get the following bonus compared to normal rail:

Electrified rail: no bonus
Monorail: +50% bonus
Maglev: +100% bonus

On top of that, some trainsets have tilting trains, which get another 20% bonus.

I hope, this’ll change now, because these new constructions require only one train without any wagons and are extremely small in comparison with the old gates and the once I see nowadays in our games.

The Logic Train

Especially for faster gates Ammler created a NewGrf for me which replaces MagLev “Lev3 Pegasus” with a “Logic Train”. This trains has a max. speed of 65,918km/h and 65,535hp. In fact insanely fast and accelerating from zero to max speed instantly. The optimized gates also function with normal trains but are not as fast as with the Logic Train and sometimes the evil chooser problem occurs. This somehow doesn’t happen with the Logic Trains, but don’t ask me why. Of course you can download the grf file I used. You’ll need it. As far as I know it is also planned to add a NewGrf file to the #openttdcoop NewGrf Package with certain restrictions. In fact, you are not allowed to add wagons to the train. Lets see if that’s possible.

The Not Gate

My new NOT-Gate creation has a size of 3×4 tiles. That’s only three tiles bigger than the smallest circle in which a train can drive. The reaction time is close to zero. The gate requires a logic train and a waypoint. The train needs the waypoint in the order list, otherwise it’ll not work as intended. As you can see the train has to make a choice. The problem we have in normal games, that the signal turns red in the moment the train wants to enter doesn’t occur. I don’t know why, but it just never happened to me, even in long-time tests.

In this video you can see a comparison to other gate types. The important gates has the Waypoint “C”. At the output comparison you can see its the fastest and always showing the opposite of the entering signal.
Optimization of Logic – Logic Gates [Part II]

The Or Gate

The OR-Gate requires the same things as the NOT-Gate. One logic train, a waypoint and an entrance in the order list. The reaction time is close to zero seconds too, you can see how it works in another video I created.

Optimization of Logic – Logic Gates [Part II]

Conclusion

I hope to see some awesome constructions of all the fans of ALUs and logic construction. Since these gates are much smaller and react very fast the possibilities are almost inexhaustible. If you have an awesome construction, post it here, upload it to our wiki or send an email to info [at] openttdcoop.org. I am awaiting your creations.

great news, another big step forward in OpenTTD development: the new framework for computer players has been merged from the NoAI branch into trunk. So, from now on, there’s no need anymore to complain about those stupid AI which OpenTTD had up until now – everyone may programme his or her own AI with as much intelligence as desired. Like many people did as documented in the NoAI subforums. Check out the threads there for different AIs.

Company chart from our first coop game against a few AIs
I got curious when the number and frequency of commits started to increase significantly that afternoon, starting with r15000:

[11:48] <cia -1> OpenTTD: truebrain * r15000 /branches/noai/src/ (ai/ai.hpp saveload/ai_sl.cpp): [NoAI] -Fix (r14984): forgot to rename @file too

[14:51] <cia -1> OpenTTD: truebrain * r15001 /branches/noai/src/ai/ai_core.cpp: [NoAI] -Fix: make NoAI network safe again

hmm… making it network safe again? Let’s see…
a number of other commits followed, also and especially in th NoAI branch. Then then finally what seemed to become more and more inevitable:

[18:12] <cia -1> OpenTTD: truebrain * r15027 /trunk/ (311 files in 30 dirs): (log message trimmed)
[18:12] <cia -1> OpenTTD: -Merge: tomatos and bananas left to be, here is NoAI for all to see.
[18:12] <cia -1> OpenTTD: NoAI is an API (a framework) to build your own AIs in. See:
[18:12] <cia -1> OpenTTD: http://wiki.openttd.org/wiki/index.php/AI:Main_Page
[18:12] <cia -1> OpenTTD: With many thanks to:
[18:12] <cia -1> OpenTTD: – glx and Rubidium for their syncing, feedback and hard work
[18:12] <cia -1> OpenTTD: – Yexo for his feedback, patches, and AIs which tested the system very deep
[18:12] <cia -1> OpenTTD: – Morloth for his feedback and patches
[18:12] <cia -1> OpenTTD: – TJIP for hosting a challenge which kept NoAI on track
[18:12] <cia -1> OpenTTD: – All AI authors for testing our AI API, and all other people who helped in one way or another
[18:12] <cia -1> OpenTTD: -Remove: all old AIs and their cheats/hacks

I can only support this: many thanks to all who made this big step in the history of OpenTTD possible. Great job, guys!

So now let’s look forward to maybe an occasional coopetition game of us coopers against the best of AIs – it will definitely require a slightly different approach than in our usual games w/o any competition as we tried out some time ago in a match against AdmiralAI.

PS: Maybe there’re some further nice fruit in the basket in the not so distant future:

[13:09] <TrueBrain> and ‘extra’ package, which contains AIs, grfs, …
[13:10] <TrueBrain> of course the ‘game’ package should contain the tram grf, and at least a few AIs (which should be in SVN too)

Back in February, Tim blogged about the differences between even and odd train lengths. This post posed it was better to use odd train length because they use less space when queuing.

To see what happens in a dynamic, i.e. moving, situation, I have built a test track which does a full speed join. It tries to get three trains as close to each other as possible, to see what the minimum distance between trains is. On another test track, I tested what the distance between trains from standstill is.

With the full speed join, the expected behaviour would be to have two tiles distance between the trains, no matter what length we use. For the standstill experiment, the expected behaviour is a positive relationship between the length of the train and the distance (a longer train is heavier and thus will have a larger following distance).

However, we are not interested in the large scale effects, but in the quantum effects: compare it to the queuing trains in Tims post: there is a linear relationship between train length and the amount of signal blocks used, but, because signal blocks go in sets of two tiles, even-length trains use relatively much space.

From standstill

First of all, I have tested the train following distance when starting from standstill for the Kirby Paul Tank, SH ’30′ and Lev4. By queuing trains with different lengths – 3, 4, 5, 6 and 6 tl – next to each other and starting them at the same time, comparison suddenly becomes easy. As distance, I have used the number of tiles, in halves, between trains, measured just before the following train reserves the next tile.

Kirby Paul Tank

The Kirby Paul Tank, with it’s 223kW and 64km/h max. speed, is the slowest locomotive in the game. Although we never use this train, it’s good to have multiple speeds as comparison.

The leftmost lane has 7tl trains, the rightmost lane has 3tl trains. The distances between the trains is

tl 3: 4.5 tiles (1.5 tiles/tl)
tl 4: 5.0 tiles (1.3 tiles/tl)
tl 5: 5.5 tiles (1.1 tiles/tl)
tl 6: 6.0 tiles (1.0 tiles/tl)
tl 7: 6.5 tiles (0.9 tiles/tl)

This shows a very linear relationship: d=0.5*tl+3. The used rail efficiency is calculated with e=d/tl = 0.5+3/tl. This means an infinite train length will still have half its length in distance between the trains.

SH ’30′

The SH ’30′ is the first, and slowest, electric locomotive to become available. Compared to the Kirby Paul Tank it’s of course very powerful: 2682kW and a 160km/h max speed.

However, the SH ’30′ shows exactly the same results as the Kirby Paul Tank!

savegame for both SH30 and Kirby Paul Tank

Lev4

The Lev4 is the fastest locomotive in the game. With almost 15MW of power from the dual engines, it reaches a staggering 643 km/h. Does this yield any different results?

The lev4 yields some interesting results:

tl 3: 7.7 tiles (2.6 tiles/tl)
tl 4: 7 tiles (1.8 tiles/tl)
tl 5: 8.8 tiles (1.8 tiles/tl)
tl 6: 8.6 tiles (1.4 tiles/tl)
tl 7: 10 tiles (1.4 tiles/tl)

Take a moment to let this be processed. The distance gets shorter from tl3 to tl4 and from tl5 to tl6! And this is not just on a single occasion; these numbers are the average over three measurements. What is even more interesting are the track efficiency numbers: they show that, from a running start, even length trains use the track much more efficient than the just-shorter odd train, and as efficient as the just-longer odd train.
Lev4 savegame

High-speed join

Of course, this does not tell the entire story. We try to have our network running, so the distances from standstill are not the most important: we want to have a running network, not a network just recovering from a jam. To test this, I have built a high-speed joiner, which tries to join three trains as closely as possible. This joiner is followed by a straight track and a full-speed 180 degree curve. The track was signalled using 2-tile auto signalling, which means we notice the effects of the bad signalling in corners.

For this measurement, I have used a slightly different system. I have measured the distance between the starting positions, subtracted the train length and averaged this over the two follow-up trains, as one of them joins from a secondary track (i.e. it has a slightly longer path).

The full join is considered a success if both the straight track and the 180 degree turn are completed without any slowdowns.

SH ’30′

Tests with the SH ’30′ yielded these results:

tl 1: 4 tiles (4 t/tl)
tl 2: 4.5 tiles (2.3 t/tl)
tl 3: 5 tiles (1.7 t/tl)
tl 4: 5.5 tiles (1.4 t/tl)
tl 5: 6 tiles (1.2 t/tl)
tl 6: 6 tiles (1 t/tl)
tl 7: 6 tiles (0.9 t/tl)

This is the minimum distance between trains. The results show quantum effects for trains shorter than 5 tiles: longer trains all have the same distance in between, which is what you would expect.

lev4

The maglev tests yielded the following results:

tl 1: 4.5 tiles (4.5 t/tl)
tl 2: 4 tiles (2 t/tl)
tl 3: 5 tiles (1.6 t/tl)
tl 4: 5.5 tiles (1.4 t/tl)
tl 5: 6.5 tiles (1.3 t/tl)
tl 6: 6.5 tiles (1.1 t/tl)
tl 7: 6.5 tiles (0.9 t/tl)

Which is pretty much the same result.
SH30 & Lev4 savegame

Conclusion

Both the standstill and the fast join results show there is no reason to prefer odd train length in a running situation. Although even length trains take more space while standing still, this should not be a reason to choose even length trains over odd length trains: although the queue is slightly longer, the situation after trains start running again is even better than with even train lengths. Besides, queued trains are exceptional: we try to keep trains running.

For tightly spaced trains the oddness of train length is not important either. There are some quantization effects with small trains, but even length trains show no disadvantages compared to odd length trains.

For both situations, it is obvious using longer trains is more efficient. My calculation does not take locomotives into consideration: a tl3 lev4 carries 4 times as much cargo as a tl2 train (4 wagons instead of 2). To take this into account, the efficiency should be calculated with e=t/(tl-0.5*#loc) instead of e=t/tl. This will show an additional penalty for shorter trains.

Stations & Trains

First of all you should know that we currently only transport two cargo types in this game (grain [G] and livestock [LV]). Every cargo type needs a dedicated platform at a each station. And of course every train transports only one cargo type. Mixing would be totally useless because we can’t set a Full Load Order for our trains because we don’t know at which station they are going to load or if they even will load anything. Every station platform needs a complex system with so called ‘Dummy Trains’ behind the station. To keep it simple: these trains do the Full Load and give a track free if they did a full load, unload again the real trains join and can do a full load. Clever huh

Subnets are Sidelines

To organise the system we created sub-networks to which a train belongs. Every subnet has its own injection-system and stations as required. The PSG#121 uses a 512×512 map and we divided this map into 12 parts respectively subnets like a clock has. We don’t use the word subnet in practice, instead we call these Subnets Sidelines to keep the terminology easy and conform to our other games. Each Sideline is connected to a mainline via a SLH. The main network uses the SML technique to handle an insane amount of trains. We didn’t built a ring or something, instead we have four mainlines and four big factory drops (again we divided the map into four sections).

Orders & Injection

Every train belongs to a specific sideline and can transport one cargo type ([G] and [LV] in psg#121). There is no real load order, instead the train will just stop at the first station and load or, if all stations are in use, go to the depot and wait until there is a need for an injection.

The injection is a quite interesting topic and I think a lot of experimenting is still needed. We currently use many different systems which belong to two classes: Steady-Injection Systems which inject a train after constant time period (e.g. 10 days) and On-Demand Injection Systems which inject a train if there is a free track at a platform. If I recall correctly I also saw a mixture which constantly injects trains and on demand. Analysing injection systems would fill another article and I will not do that now.

The 100,000 target

The goal of psg#121 is to transport enough grain and livestock to produce 100,000 crates of goods per month. To achieve this we need stations which don’t have only one platform per cargo type. Why? Imagine a farm producing more than 2000 grain or livestock per month, you can’t transport this using a single platform. Mark, ODM and me tested this and found some solutions. The main problem was that if there are multiple dummy trains per cargo type one dummy train could load the cargo which is unloaded by a second one. Avoiding this is only possible if all trains load and unload at the same time. The conclusion is that trains only unload when all trains are loaded, a bit of signalling or logic gates did the trick.

The Mess

Mark and I built ‘The Mess’ yesterday, which is a station with 3 platforms per cargo-type and of course a connection to the on-demand injection system. Because of the size a Sideline of another subnet is just tunneled underneath the station. It took us more than one hour to build this area (including fixing bugs and testing) and it is just a crazy piece of art.

The Future

The possibilities using this technique seem to be endless, this is just the beginning. It should be possible to have several SRNWs within a large one for example. Let’s keep developing this concept and let dynamic networks guide trains to wherever they’re needed.