How to implement new signals (a look in to the map array)

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
The Physicist
Engineer
Engineer
Posts: 6
Joined: 08 Nov 2009 23:51

How to implement new signals (a look in to the map array)

Post by The Physicist »

Do you remember the old days with only block signals? A lot of deadlock, but then pre signals arrived, and solved a lot of problem. But not all of them. Later we saw the PBS-signal, what a wonderful signal.

I have now looked on all my complex rail network, and for the newer I discovered, I only use the block signal and the two PBS-signals. The block signal is mostly for eye candy, since it normal state is green 8)

I never use the pre signal, but after a analyzing work, I found, that in my network, some of the PBS-signals could be replaced with a pre-PBS-signal (described below). As far as I can see, all pre-signals can be replaces with PBS- or pre-PBS-signals (see Part 3 and 4).

Furthermore I found, that a number of relatively simple signals-configurations are impossible, i.e. block signal on single tracks without the risk of deadlock.

On the bottom line, I have a list of six signals I want in the future, on of them is with three possible states. Furthermore I have though of more signals, but not sure weather they a that useful.

Part 1

But before I can ever think on new signals, there is an issue with the map array! It is not with unlimited space, so step one is to find room for these signals.

For this I have three approaches:

Approach 1: Skip pre signals (signal 2-4) in m2 7..0. This would be a problem for backward compatibility.

Approach 2: Set m5 bit 7 to 1 and m7 bit 6 to 0, and there by double the amount of space for signals, but could be a problem for future programmable signals or other big rail projects, where I at least would expect, that they require a lot of bits for indexing.

Approach 3: Use the yet unused m7 bit 7..0 or m6 bit 5..2, but they are common for all rail (rail, signals and depots), so that could hinder a future major property for rails. Or maybe m2 F..C, which are also unused for regular track, but again, this could cause problems in the future.

I don't know what would be the best approach.

Part 2

And the second problem: Signals with up to four states. Here I have three approaches too:

Approach 1: Maximum of two 3/4-state signals per tile (one for each track), giving room for two extra signal states in m4 bit 7..4 Today there is a maximum of one PBS-signal for each track in each tile, so this maximum would not change anything.

Approach 2: Using yet unused bits, see approach 2 i Part 1 for problems with this.

Approach 3: Let 3/4-state signals be two different signals. This is a ugly hot fix, and it occupies more room for future signal.

So here I think Approach 1 would be best.

Part 3

For my little future, I have found four usable signal states:

Red: Stop, and signal is a safe waiting point

Yellow: Stop, and signal is not a safe waiting point. When trains reserve a path, it should try to reserve though this signal to the next red signal. But the path will only be reserved to this signal, unless the preceding signal is a double path signal, which requires a path two signals ahead.

Green: Proceed to next signal. Path reserved one signal ahead.

Double green: Proceed to next signal again. Path reserved two signals ahead.

Part 4

My suggested signals:

Block signal with two states. No more words about this signal.

PBS: Two states: Red and green.
Path signal is the already known signal, and no more words should be required.
This signals comes in both one way and two ways versions. The one way capability can eventually be coded in m4 bit 7..4, giving the signal two variable states and two fixed states, at all four states when combined. This would give problems with backward compatibility.

Pre-PBS: Two states: Red and double green. Signal requires a reserved path beyond the next signal, before it will change to double green.
Double path signal acts much like as the today known entry and combo signals. Exit signals can be block or regular PBS-signal.

Delayed PBS: Two states: Yellow and green.
1: Can cut a block in two parts, and thereby let a double green path signal switch to double green. Much like a exit pre signal today.
2: Can delay triggering of road crossings without acting as an extra block signal.

Advanced PBS: Three states: Red, yellow and green.
Useful for tracks with multiple blocks, where the direction can change. The signals normal state is yellow. When a train pass the signal, it turns red. When the train pass the next signal, it turns yellow.

What is your comments? :)
Eddi
Tycoon
Tycoon
Posts: 8258
Joined: 17 Jan 2007 00:14

Re: How to implement new signals (a look in to the map array

Post by Eddi »

currently there is space for two more signal types without any changes to the map array. there are even already graphics for these types included in the basesets.

adding these types is fairly easy, there exist patches that do that. filling these types with meaningful behaviour is the tricky part.
The Physicist
Engineer
Engineer
Posts: 6
Joined: 08 Nov 2009 23:51

Re: How to implement new signals (a look in to the map array

Post by The Physicist »

Eddi wrote:adding these types is fairly easy, there exist patches that do that. filling these types with meaningful behaviour is the tricky part.
For me it is not at problem to find meaningful behavior for extra signals, since I want at least two additional signals, and often even more. But the problem is how the space in the array should be used. There is 8 bit for each signal pair, which gives 256 different states. For signals in X and Y directions, there is 65,536 possible states, of which only a tiny amount is used. In both cases, only approximately 40 states is in use.

But since I am not an expert in the OpenTTD-coding, I am wondering have nasty it would be to use states where bit from non-present signal is used? E.g. creating a variant of the PBS signal, if the bit for the non-present PBS-signal in the other direction is set to 1.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 13 guests