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.

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.

Of course this counter is a complex electronic circuit and we should not look at it in a too close manner. It uses half-adders, memory and a lot of logic gates. But some parts, especially the logic gates, are really interesting.
My first intention was to optimize them to be useful in #openttdcoop network games.

Logic Gates – An Overview

Boolean Operators a.k.a. Signals
First of all, we’ll have a look at the requirements to understand logic gates, as I create them, in OpenTTD. A default signal can be either red or green. These two states can be defined as true and false or as 1 and 0 or zero and non-zero or easily as yes and no. In fact, it is a system with only two states. A Maybe doesn’t exist. As you can see it, doesn’t matter which state has which name, but it is important for the definition and further constructions.

My definition is:

• 0 / false / no = green
• 1 / true / yes = red

That’s just a matter of the question you ask yourself. My question is: Is a train in the signal block?. The complete logic turns around if you ask yourself: Is the track free?.
Please keep in mind that my definition is _NOT_ equivalent to the definition of ‘red’ and ‘green’ used in electronics. I still decided to do it this way, because the AND-gate is easier to build in this case and I somehow think it is used more often in complicated constructions like the XOR-gate.

Handling special cases
You also should know, e.g. when you build your own logic gate construction, that I always used two trains to create it. One train and a signal block with more than one exit signal (-< =) is always vulnerable for a signal-lock-situation. In this case the train enters the block and while choosing a track, the chosen track and its signal turn red. The train is locked and it takes several seconds to return and choose the correct exit.
I really like Marks Idea for a NOT Gate, but it might cause unintended problems. Using two trains avoids this problem because the first train stops and the train behind must always choose the other option which changes the state of the logic construction.

The best train
I optimized all construction for two Lev3 ‘Pegasus’ (Maglev) and added sometimes a wagon to make the train a half-tile longer. Lev3 is better than Lev4, because Lev4 for is accelerating too fast and both trains slow each other down all the time having a lower average speed than Lev3. All slower trains (482km/h for Lev3) work too, but the reaction time is slower.

The AND-Gate

I told you a lot about the requirements now and unluckily the first logic gate is very simple. The feature of AND logic is hardcoded in OpenTTD (all entrance-exit-blocks work that way) and we don’t have to add further additions to this signal block.

What happens here is easy, as the logic table shows you only if both signals (x, y) have the same (1) state the output (x^y) is (1). In other (easier) words x and y have to be red to turn x^y red as well.

The NOT-Gate

The NOT gate returns always the opposite of the input. Two trains, the loop and a prio-line were needed to create this construction. It looks a bit like a maze, because I shrank the size as much as possible. For this construction you need two Lev3 with one wagon or two double Lev3 to work properly. If you don’t the output might turn 0 for a millisecond.

The OR-Gate

The OR-Gate was the trickiest to construct. I had many problems with incorrect output in the beginning, but I found a clever solution. Again you need a loop and a one-tile prio for the input x. If input x turns red, the first train will stop at the entry-signal of the inner loop right in front of input x. The second train will avoid the inner loop and use the outer loop. If the train is there, the output turns red regardless of the input y. The thing I am really proud of is, if input y turns red, the loop is ignored and the output turns red immediately.

More Logic Gates

With these three logic gates you can create many other logic gates or logical constructions such as XOR, half adders, full adders or even flipflops. Though I doubt it is possible to create a complete ALU (e.g. the slow reaction time), but constructions helping us to regulate the traffic and the movement of our trains in complex openttdcoop network should be possible.

I hope you gain something from my little article about logic gates and enjoyed reading. Now head on, build your own logic gates or implement them in any other weird network construction. Please post your results as comments, at our wiki or send an email to info [at] openttdcoop [dot] org.