You should be using this tutorial instead.

---

Back to Hammer Tutorials

Back to Adding Signals To Your Map

Once you have your track laid out and a Signal System defined, you can start placing the Hammer entities necessary to make the signals work. This is probably the most complicated subprocess for making a map work, so we'll break it up further into smaller subsections.

• Signal Blocks and Interlockings
  • Signal Blocks - Rules of Thumb
  • Interlockings - Rules of Thumb
  • Examples
    • Single Track with One Block
    • Single Track with Multiple Blocks
    • Passing Siding
    • Double Track (One-Way)
    • Double Track (Two-Way)
    • Crossover with Junction
    • Complex Interlocking with Logic Gates
    • Bascule Bridge
• The Signals Themselves
  • Signal Placement
  • Assembling the Signal
• Path Loaders

The backbone of all signaling systems is the signal block. The purpose of a signal block is to detect the presence of a train in a given length of track and inform the rest of the signal system so they can convey the proper information to the engineer. Signal blocks are either occupied or clear, making them a simple boolean indicator of a train on the track. A signal system is only worth scrap if it can't stop two trains from hitting each other, so it follows naturally that these should be the first things you set up in your map.

In the real world, block occupancy is checked using a track circuit, which uses the solid metal axles of the train to short a relay coil between the two rails. In Trakpak3, however, the entity responsible for checking the blocks is the tp3_signal_block.

To place signal blocks in Hammer:

1. Spawn a point entity and open its properties, then change the class to tp3_signal_block.

2. Give it a descriptive and unique name.

3. Change the other keyvalues as required. Most of these can be left alone, though you might need to adjust the Trace Height, Width, and Offset if you're using a track gauge that's significantly different from RSG.

The Starting Mode keyvalue should probably be left as Automatic, though if for some reason you want a block that always shows up as "Occupied" or "Clear" (until told otherwise with Hammer inputs), change that to Force Occupied or Force Clear.

The Scan Speed keyvalue can be left alone now and adjusted later (if needed).

Note: The location of the entity in Hammer matters! Later on, when you're setting up the block bounds in-game, you'll have to "select" the normally-invisible tp3_signal_block entities based on their physical location in the world. Just make sure they are in logical places so you can tell which stretch of track they will apply to!

While you don't set the exact bounds of the signal blocks in Hammer, you should have a general idea of where you want them to start and end. You are going to need a separate tp3_signal_block entity for every separate stretch of track you want to be protected by them. I'll cover some general rules about signal blocks first, then move on to some common examples later.

In general, signal blocks:

• Are long enough to fit an entire train without it overlapping onto other blocks.
• Cover only static track (no switches, movable bridges, etc.). If non-static track is within the block limit, special rules usually apply.
• Are protected by signals for both entry and exit - Trains can't enter or leave a block without having a signal indication that authorizes it.
• Are limited to only one train at a time. Under normal circumstances, trains are forbidden from entering an occupied block at anything more than the slowest speed in the rulebook, typically Restricted speed (in other words, the signals are "Permissive" and not "Absolute").

Generally speaking, signal blocks exist between interlockings. What is an interlocking, you ask? For the purposes of Gmod railroading, an interlocking can be defined as a group of switches on through-track (typically mainlines) that are protected by signals. In modern times, interlockings are sometimes called Control Points (or CPs).

Compared to signal blocks, interlockings:

• May be as small or as large as needed.
• Cover non-static track (at bare minimum, a single switch can be considered an interlocking), and static track as required.
• Are protected by signals for entry. Some interlockings (such as passing sidings) have signal blocks, and therefore also have exit signals.
• Can contain multiple trains, but only if the switches are set such that the two trains cannot collide. Unlike some signal blocks, Trains are not allowed to enter an interlocking if the signals disallow it (in other words, the entry and exit signals are "Absolute" and not "Permissive").

Trains are only allowed to move through interlockings if the signals allow it, and aren't allowed to change switches or reverse direction until they move to somewhere they can be governed by signals again. Typically, that means trains have to pass all the way through the interlocking. Sometimes, as is the case with passing sidings, the main and passing tracks and the switches are considered one interlocking, but the signals on the main and passing tracks are okay for trains to stop or reverse in.

Now, on to some examples. These will include some common track configurations you could see on any route, as well as some more specialized ones to show just what the block system can really do.

The simplest example of a signal block is a length of single track in between two interlockings. The signal block ensures there's only one train on the single track, thus preventing head-on collisions.

In these diagrams, the red signals are Absolute signals (can't be passed if showing a Stop indication), and the green signals are Permissive signals (Stop is actually Stop And Proceed). In this example, all the signals are Absolute because they protect interlockings (the black tracks).

The previous example is a good illustrator of how signal blocks work, but suppose your stretch of single track was longer? Long enough to fit multiple trains, even? You wouldn't want to have one signal block for the whole length of track, because there's no reason why you couldn't have multiple trains follow each other in the same direction.

By splitting the long single track into multiple blocks, you can have just as many trains on the single track, going in the same direction! Note how the signals in between the blocks are Permissive? Trains following one another in the same direction can enter the block (at a safe, slow speed) even if the signal is showing a Stop [And Proceed] indication, because it's reasonable to expect the train ahead to get moving again.

Occasionally in between lengths of single track, you should have passing sidings or double track to allow trains moving in opposite directions to pass each other. A passing siding is effectively two independent single tracks next to each other, with one designated the "main" and the other for "passing".

While passing sidings require coordination (by timetable or dispatcher) to let multiple trains through, double track can let many trains through while requiring coordination only at the ends. In this example, the tracks are set up for Right-Hand Running (RHR), meaning trains are not (normally) allowed to proceed on the lefthand track.

Two-Way (or ambidextrous) double track is usually set up for one-way running, but has the flexibility to allow for irregular circumstances that one-way double track can't handle. Two-Way double track is functionally the same as two multi-block single track segments side by side.

This example shows a typical pair of crossovers with a junction that goes off somewhere else. The interlocking is flanked by two-way double track on both ends.

While most of the previous examples have been simple, requiring no additional entities besides the tp3_signal_blocks, interlockings that must be covered by signal blocks present a problem. Normally, the signals monitor only one tp3_signal_block at a time. In some interlockings, such as a diamond - which are effectively two main lines that must coordinate between each other to prevent collisions - the signals must monitor multiple blocks at once. The solution to this is the tp3_logic_gate entity, which behaves like a tp3_signal_block in every way except instead of scanning tracks, it monitors the states of other signal blocks or logic gates and outputs an occupancy state based on the logical combination of them. In general, you will need one tp3_logic_gate for every signal that's part of a complex interlocking.

How do you know when to use logic gates? There are two main reasons why you'd want to use them:

1. There are multiple signal blocks that cover the same piece of track that must be considered together, or

2. There is a signal block that is very short, so the trains shouldn't stop in it, occupancy protection must still be enforced.

What's an example of both of these in action? A Diamond, of course!

In this example, the logic gates perform the two functions outlined above. They monitor all the applicable blocks in the area of the diamond to prevent trains from colliding (though still allowing trains on the double track to pass each other). And, because the diamond blocks are so short, they include the block beyond so that trains can't proceed through the diamond without having enough room on the other side as well.

One final example of how to set up signal blocks would be a movable bridge, such as a bascule bridge. This example is special because of the fact that the bridge can open, which ought to drop the signals to Stop for obvious reasons. Tp3_signal_block entities can be forced to show as occupied using Hammer Inputs/Outputs (I/O).

The bascule bridge produces outputs that indicate when it's safe for trains to pass. These outputs can be used to force the signal block for the bridge to show as occupied when the bridge is up, and return it to automatic scanning when the bridge is down.

Now that you have all your tp3_signal_blocks placed, it's time to place the actual signals. There are three entities that are used to make signals:

1. tp3_signal_master - At bare minimum, this is all you need to make a signal. This entity will set its own bodygroups/animations/skins and communicate with trains and the rest of the signal system, dispatch boards, etc.

2. tp3_signal_slave - Does not control or communicate anything, but receives bodygroup/animation/skin commands from a tp3_signal_master that controls it. These are used to make multi-part signals, such as a signal with 3 heads. One tp3_signal_master can control 2 tp3_signal_slaves.

3. prop_static - Poles, brackets, signal bridges, or any other static hardware used to support the signal.

For the purposes of this tutorial, I'm using using the term "signal" to refer to the whole installation: tp3_signal_master plus any tp3_signal_slaves and props to mount them on. "Master Signal" and "Slave Signal" will refer to tp3_signal_master and tp3_signal_slave of course.

The images above give a general idea of where signals ought to be placed. As I've described before, signals should be placed to protect entry into, and exit from, signal blocks. When you have a chain of blocks, of course, that translates to one signal roughly where the two blocks are supposed to meet. Because the signals need to reference signals in front of them, I recommend you start at the end of the line and work your way backwards, if it's practical to do so.

The positioning of a signal in the world depends on a lot of factors, such as locale, time period, type of signal, etc. For most signals, they are placed on masts (poles) 12 to 24 feet high (Trakpak3's signal masts are categorized by height) and on the side of the tracks the engineer would be able to see best. So in the US, typically they would be on the righthand side of the tracks unless there was a good reason not to. In fact, it was a requirement for high signals (i.e. not dwarf signals) to be above and to the right of the tracks before the 1980s in the US due to standards dating back to the steam era.

In the modern day, where locomotives are typically low-nose and short-hood forward, the one requirement is that the engineer should be able to see the signal. That may mean you have to make it really tall to be seen over another train.

1. Place the entities.

As I mentioned above, signals are made of mounting props, one master signal, and 0 to 2 slave signals. Conventionally, the master signal goes on top (if using a multi-head signal), or is the "main" head (if using something like B&O CPL, where there's a main head surrounded by "orbital" lights).

2. Name the signal entities.

Give the tp3_signal_master and tp3_signal_slave some nice, descriptive names. The master signal will need to reference the two slave signals "below" it, so use the Slave Signal 1 and Slave Signal 2 keyvalues in the master signal's properties for those.

3. Configure the Master Signal Properties.

Besides the bodygroups/skin/model stuff, the important ones you will want to set are:

• Signal System Name - the filename (no extension) of the Signal System that the signal will be using. This is a file you should have made earlier using SigEdit. The signal system file is kept in <your addon>/lua/trakpak3/signalsystems/<your map>/.

• Signal Type - the signal type in the Signal System that this signal will use. Signal types are defined in the signal system.

• Tags - a list of all the signal tags this signal will use, separated by spaces. Signal tags are defined in the signal system.

• Starting CTC State - all signals have a "CTC State" that has the values "Allow" and "Hold". Signals with the "Allow" CTC state will behave like you'd normally expect, displaying an aspect based on the track and block conditions ahead of it, and the next signal in the system. Signals with the "Hold" CTC state (should) always display the most restrictive indication (usually "Stop"), even if the way ahead is clear. There are more options that can be set using Hammer I/O or Dispatch boards, but Hold and Allow are the only two permanent ones.

• Signal Block - a tp3_signal_block or tp3_logic_gate that this signal will monitor, and factor its occupancy state into deciding what aspect to display. This should generally correspond to the tp3_signal_block just beyond the signal. If you don't specify this value, the signal will assume the way ahead is always clear (this can be used to make "distant" signals).

• Next Signal - a tp3_signal_block that this signal will monitor the Next Signal and factor its speed/route information into deciding what aspect to display. This should generally correspond to the tp3_signal_master just beyond the signal. If you don't specify this value, the signal will operate based on block occupancy alone (this can be used to make "home" signals).

If you leave both Signal Block and Next Signal blank, the signal will assume the most favorable conditions possible. This can be used to make "off-map" signals, where trains can disappear into a tunnel or something and be deleted. Additionally, at interlockings, the Signal Block and Next Signal can be changed as the switches are set (more on that discussed later).

Generally, for signals that are intended to have Dispatch Board or Hammer I/O control and protect the entry/exit for interlockings, the default value should be "Hold". For all other signals, the default value should be "Allow".

• Cab Signal Pos - a position in the world that cab signal boxes will use to detect when they're "passing" the signal. If you have the master signal selected, you may notice a small white circle (in the 2D views) or a purple sphere (in the 3D view) roughly at the center of the model. You can drag that around in the 2D views to set this keyvalue easily. Generally it should be in the middle of the rails, about one locomotive length (500ish - 750ish units) before the signal.

The rest of the keyvalues can usually be left alone. If you're using a model with animations (such as the semaphore or banjo signals), you may wish to play with the Animation Behavior values, which affect the "physics" of the animation, making it bouncy or smooth or whatever.

4. (Situational) Configure the Slave Signal properties.

The slave signals are designed to be controlled by the master signals, so will only need to change the appearance keyvalues such as skin, bodygroups, and animation behaviors.

Repeat as necessary until you have all your signals placed.

Path Loaders (tp3_path_loader) are used to give signals special behavior that is dependent on switches. Each path loader represents a valid route through an interlocking, in both the forward and reverse directions. When the switches of an interlocking are set to produce a path loader's route, it will change certain signal parameters to reflect the new route. They can change a signal's block and nextsignal, as well as set other parameters like route (switch) speed and divergence (main/diverging).

Because each path loader represents a valid route through an interlocking, you are going to need one for every valid route through the interlocking. In other words, for every entrance to an interlocking, you'll need one path loader for every exit that can be reached from that entrance. That can add up to a lot of path loaders! To reduce the burden on the mapper, each path loader works in both directions, so you won't need two path loaders for the same route.

Let's take a look at an example. Take this simple interlocking for instance:

We're going to go through all the valid ways a train can pass through this interlocking. The first, most obvious ways, are when all the switches are set to their Normal position (i.e. straight). We'll call these the "Main" paths.

Now, suppose either crossovers S1 or S2 (but not both) is thrown to its Reverse position. That produces two more paths, which we'll call the "Xover" paths.

Lastly, suppose we want to use the turnout. If the turnout switch S3 is thrown Reverse, you have one path if S1 is Normal and another path if S2 is Reverse. We'll call these the "Turnout" paths.

But wait, isn't there one more way you can get through the interlocking?

Yes, there is, but it's stupid. Nobody will have a good enough reason to want to use this route. If someone really does need to use it, throw the switches and give them a Force Restricting aspect to get them through. But I wouldn't waste an entity for this path. Any paths through an interlocking which are similarly useless should not get a path loader.

As you can see, even a simple interlocking can have a large number of routes. This simple one with three switches (the crossovers count as one each) has six! And the number only gets higher the more complex the interlocking gets.