How to compose signals

Signals are often made up of components. There are three different ways to implement this in RW. Things to consider are

• the number of combinations
• the degree of perfection of the signal appearance
• the ease of use for the route builder
• the roles in the creation process.

For the number of combinations consider the following simple UK example: Junction signals can be 2-aspect, 3-aspect, and 4-aspect (3 variants). The fingers on them can come alone or in any pairs. There are also many triple-combinations, not to mention of the chance to maybe see a combination with more. 6 fingers give 6 single-finger versions and 15 different pairs which only needs some 9 combinations with 3 or more fingers and we have the impressive number of 30 finger combinations. The interesting bit is that this figure is multiplied with 3 to give the total number of signals to be shown, 90. In case we had two different post designs, that would double the 90 again.

For the degree of perfection, I mostly think of self-shadowing and support structures for the optional parts. If the signal is all black, you don't worry too much about the shadows, but many countries paint their signals in more or less light grey. For the fingers, there is some chance that two neighbouring ones are mounted together in one panel, which will make a noticeable difference from two separate fingers.

Some people argue that only the front perspective from a moving train would be important. But even if you say you are only driving, you might be driving a shunting engine which might halt near a signal, and certainly it will pass many signals in reverse direction at slow speed. So the shape details of signals are not generally useless.

Regarding the ease of use for the route builder, one has to weigh two different aspects.

• Effort to position the signal combination
• Length of the signal item list

Clearly, the two are antagonists, unless you use a signal composition assistant which is not implemented in RW. So, you either have a short list of components (in our case, 3 heads and 6 fingers), and you ask the user to arrange them manually at each site; or you have a very long list of prefabricated combinations (90 items minimum in our case, instead of 3+6=9 separate items).

Only in bigger teams, the following roles in the creation process need to distinguished.

• 3D artist creating the shape, knowing enough about signalling to get the shape and the colours right
• Scripter, knowing enough of signalling to get the control logic right
• Configurer, not necessarily a programmer, but someone who knows how to set up a load of configuration files in finite time.

As shown below, some methods lend themselves more to shared roles than others.

Ways to implement signal combinations

1) Creation of all combinations in the 3D modelling programme. This has the large advantage that you can achieve perfect appearance by having correct self-shadowing of the combined shape. You can also easily adjust for deviations of certain combinations, like neighbouring fingers being paired.

The disadvantages are that the configuration work is done in the 3D programme, i.e., you need a script running inside this programme to create the combinations (before you apply the fine tuning); and you end up with a long list of items. It is also worth noting that only someone owning the source files of the assets can use this method.

2) Combining the signals in blueprints. You can do this by using the Asset Editor or by writing a little script which creates the combined blueprints. The advantage is that you get the combination work out of the 3D programme. The disadvantage is obviously the combination of no self-shadowing with the bloated signal list.

3) Combination in the world editor. By supplying all signal parts as separate signals in terms of asset categorisation and blueprints, you arrive with 3 + 6 "signals" in the list, of which 6 only make sense as part of another signal. (The fingers make only sense if mounted to heads.)

This vast advantage has to balance a list of disadvantages. There is no self-shadowing. The scripts are bit more complicated since the coordination between the head and the fingers is now performed via messages between them. And most importantly, the user has to perform several placement actions per signal.

This latter problem is eased by the fact that the complex combinations of signals are rare and the simple signals are frequently used. Also, frequent combinations could be implemented as under item 2 above, alongside the freely combinable part library.

Signalling assistants

Clearly, the user needs assistance in all three cases, not only to ease the work, but also to suggest combinations which are prototypical and warn of such which would not be used in the prototype.

In any case, one would define snap points for each signal and specify what could be snapped there. Then, the user only needs to select what to use, and no where to place it (except for deciding between two or three alternative locations, in case there are some).

For (1), such a tool would be implemented in the 3D programme. For (2), a separate tool, maybe with a GUI presenting a preview of the aspect, would create blueprints. For (3), it would modify the tracks.xml file which is difficult. At the same time, this latter case is the only one where the user can be consulted with respect to signal distance, too. In countries with speed signalling and strict rules for signal distance, this is an important aspect. Also, this is the only way to put an end to misplaced links and forgotten paths and switches.

Conclusion

If a signalling scheme knows many combinations, option 3 is the more feasible one, otherwise option 1 provides better look and nearly the same disadvantages as option 2.

Parsing and modifying tracks.xml might seem a bit far out from today, but it is a precondition for more comprehensive route builder support.