All the European routes modelled in Train Simulator (excluding some historic routes, for obvious reasons) have some form of train warning system that sounds an alarm in the train cab and/or applies the emergency brakes if you drive past a signal without acknowledging it, exceed the track speed limit or pass a red signal. And all of the routes' signals also include a check for "SPADs" or Signals Passed at Danger.

The following sections describe how the system works.

SPAD messages are very easy to generate and don't require any additional objects to be added to your track. All you need to do is add a few lines to the OnConsistPass function of your signal. Here's the relevant bit of the standard European BaseOnConsistPass function:

All that's happening is a check if the signal is blocked when a train starts to pass link 0. If it is, a SPAD is generated by calling a code function called SendConsistMessage which (as the name suggests) sends a message (in this case the SPAD_MESSAGE) to the offending train.

The AWS or Automatic Warning System is used on Train Simulator's modern British routes. Approximately 180 metres before most signals there's an "AWS ramp", which is placed just like a signal except that the ramp goes in the middle of the track instead of next to it. Like a signal, it has a link, which in this case goes right above the ramp. When a train drives over the ramp it passes that link, triggering the OnConsistPass function in its script.

All that function needs to do is check the state of the next home signal up the line when a train starts passing its link. It does this by calling a code function GetNextSignalState, which looks up the line until it reaches another signal link facing in the same direction and then triggers that signal's GetSignalState script function. Then it calls SendConsistMessage to send the appropriate AWS_MESSAGE to the train.

Here's what that looks like:

If the signal ahead is clear, the AWS_MESSAGE is sent with the parameter "clear", and a bell rings in the train's cab to let the driver know he's clear to proceed. If the signal ahead is blocked or showing some kind of warning, the AWS_MESSAGE is sent with the parameter "blocked" and a warning sounds in the cab until the driver hits a button to acknowledge it. If the driver doesn't press the button soon enough, the train applies its brakes automatically, but that's handled by the code and it is not necessary to worry about it here.

Like any other signal, the AWS ramp also needs to have Initialise and OnSignalMessage script functions. Nothing needs to be Initialised though, so that function can be left empty, and all the OnSignalMessage function needs to do is forward on any message that it receives. Apart from that, all the script requires is for the necessary global constants (CLEAR, WARNING, BLOCKED, which are 0, 1 and 2, and AWS_MESSAGE, which is 11) to be declared. Like the shunt signal, the script is simple enough that it doesn't need to have any common files included.

The TPWS or Train Protection & Warning System is an additional system which is used on Train Simulator's modern British routes. Like AWS, it requires a separate object to be added to the track, in this case, a "TPWS Grid" which is placed just before the home signal it protects. Like the AWS ramp, this grid has a link which should be placed directly above it (making sure that a train going in that direction will pass the grid's link before it passes the home signal's link 0), and the grid's script contains an OnConsistPass function which checks the state of the home signal just in front of it when a train drives past that link.

Unlike the AWS ramp, as well as checking whether the signal ahead is blocked the TPWS grid also checks if the train is going faster than the speed limit for this bit of track. If it is, it sends a TPWS_MESSAGE (12) to the train, which causes it to automatically apply its emergency brakes.

Here's how that works:

Using the existing code, it's possible to create your own warning systems. For example, the German Indusi / PZB system can be replicated using a mixture of AWS and TPWS messages. This can either be done by adding separate PZB inductor magnets next to the track in the appropriate places, or by simply adding the necessary checks to the OnConsistPass function used by standard German home and repeater signals.

When you pass the 0 link of a repeater signal, if the next home signal up the line is red, the Indusi system triggers a warning just like the AWS ramp, so an AWS_MESSAGE with the "blocked" parameter should be sent to the train. When you pass the 0 link of the home signal, if it's red the train will automatically be stopped, just like the TPWS grid, so you can send a TPWS_MESSAGE with the "blocked" parameter to the train.

The Indusi system also checks to make sure that if you're passing a home signal that's set to warning you have slowed to 40km/h. Again, this can be done by sending the "overspeed" TPWS_MESSAGE if the consist's speed is more than 40km/h (which is 40 / 3.6 in metres per second).

It should be possible to simulate the behaviour of many other warning systems from around the world using a similar combination of AWS and TPWS messages.

Although most of a route will normally be covered by home signals, some areas (particularly in yards) are "dark". Once a train goes into a yard it probably won't encounter another home signal until it leaves the yard, and the signals outside the yard generally won't know or care about trains inside the yard.

To handle this, there are special signals which have one or more of their links flagged in their Initialise script function as being a "yard entry". These links ignore the occupancy of the track beyond them, which involves making a few simple changes to their OnConsistPass function -

Just place the signal using that modified script on the mainline somewhere before the yard entry you want to cover, put the appropriate link a little way inside the yard, and your signal will turn green again as soon as a train finishes passing that link and disappears into the yard.

If you need one signal to cover multiple yard entries, you can flag more of the links as yard entries. Again, by making your changes as generic as possible you can re-use the same basic script functions for multiple signals with different numbers of links and yard entries. In the case of the UK Colour Light signals, for example, there are lots of yard entry signal scripts, but they only contain Initialise and (if they have any feathers) ActivateLink functions - the rest of the scripting functions for them are kept in a small set of common files that the signal-specific scripts include.

On the Bath - Templecombe route, several of the junctions are designed for trains to cross between tracks or enter a siding by driving past the junction and then reversing up it.

If the signals before the junction are only covering that one junction, that's fine. But if you want one signal to cover multiple junctions of this type, there is a problem. Normally you would place link 0 next to the signal and link 1 beyond the last junction you're covering. But on this route, trains will often drive past the signal and then reverse back up another track, without the rear of the train ever passing link 1. This means that gOccupationTable0 never gets decremented back to 0, so even after the train has reversed onto another line and the junction has switched again behind them, the signal they passed remains blocked.

The way around this is to do something which would normally be incorrect - placing multiple links for the same signal on the same line, putting one after each junction. Each link keeps track of which link (if any) it's connected to, and so wherever you drive your train and however you switch the junctions, the signal will always know whether the route in front of it is blocked.

Consider a simple case - a signal that has to cover two junctions that merge onto the track ahead of it. This signal will have three links - link 0 next to the signal as normal, link 1 just beyond the first junction, and link 2 just beyond the second junction.

First, in the Initialise function declare a new table gSpecialConnectedLink to keep track of which links are connected to each other:

Next, in the ReactToSignalMessage function, you need to make sure the signal reacts to messages arriving on the correct links. Most messages should be ignored unless they arrive on the last link, except the INITIALISE_SIGNAL_TO_BLOCKED and RESET_SIGNAL_STATE messages (which can be received by any link) and the JUNCTION_STATE_CHANGE message (which should trigger the OnJunctionStateChange function when it arrives on any link except the last one). You also need to make a slight change to how the OCCUPATION_DECREMENT message is handled, to make sure that it checks the occupation table entries for all of the links (0, 1 and 2) are zero before setting the signal as NotOccupied.

The OnJunctionStateChange function needs changing next so that it keeps track of which link each of the other links are connected to.

Finally, you need to make a couple of changes to the OnConsistPass function to handle the fact that the links are now all on the same line covering converging junctions, instead of on different diverging routes.

When a train starts to pass a link other than link 0 in reverse, you should increment the occupancy of the link behind it if that link is connected to you:

Similarly, when a train finishes passing one of those links going forwards, you should only decrement the occupancy of the link behind it if that link is connected to you:

Finally, when a train finishes passing link 0 in reverse, you need to check gConnectedLink is 2 and that the occupation table is empty for all links (0, 1 and 2) before telling the signal it's NotOccupied.

Now if a train drives past this signal, stops just past the first junction (link 1), switches the junction and reverses back up it onto another line, all of the occupation tables will update correctly and the signal will know it no longer has a train blocking the track ahead of it. If you're feeling really ambitious, you can even script signals that handle a mix of diverging and converging junctions in this way. An example of this is the UK Semaphore signal script "Sem_DvgeRte_hh Special 1.lua", which is used by a signal near Evercreech Junction.

The European signals created for Train Simulator are mostly fairly straightforward - they show if the line ahead is blocked or clear and (in some cases) have one or two warning aspects they can show as well.

But some signal systems (for example, North American ones) are incredibly complex and (using a combination of multiple heads, flashing lights and sometimes even moving parts) can show several different warning aspects depending on everything from the state of junctions further up the line to the type of train approaching the signal.

In these cases, using simple functions like Occupied and NotOccupied to control the state of the signal is obviously not sufficient. Instead, it sometimes makes more sense to combine all that functionality into a single function which can be called whenever something happens that might change the state of the signal (such as a signal message being received or a junction being switched), and takes all of the necessary factors into account to decide what state the signal should be in now, and which of its lights should be switched on or off.

For example, this would control a two-headed US signal as used by BNSF in California:

This function has to deal with a bewildering set of factors - what the state of the next signal up the line is, whether you are diverging or going straight ahead at both this signal and the next signal, the speed at which you should cross the next junction, whether you are going into an area with a restricted speed limit (such as a yard), what type of train is approaching the signal... Handling all of this through separate functions would be completely impractical. Instead, there is one function which can be called from the OnConsistPass, OnJunctionStateChange and ReactToSignalMessage functions whenever the signal's state might need to change.

Notice some functionality that's normally found in the SetState function has also been included. Instead of telling SetState what state is being switched to and letting it decide which lights to turn on and off based on that, it is all handled inside this function and tells SetState which lights need to be active on each of the signal's two heads.