Multi-Aspect Signals (MAS)

[crakinshot]

I'm making some progress and I should have a release in a few days, so I'll start a post to track dev.

[Goal 1]
Multi-Aspect Signals are PBS-extended signals which show various degree's of warnings. These warnings affect the speed / behaviour of the train. The initial goal is to have 4 levels of warnings Green, Double Yellow, Yellow and Red. Double yellow would apply a speed limit of 80mph, while a single yellow would limit trains to 40mph.

This work is based upon Long Reserve PBS ( http://www.tt-forums.net/viewtopic.php?f=33&t=42675 ) but with some differences. Rather than try to reserve as many segments as possible down the track, the MAS signals only reserve up to a 3 segments ahead. For example, if a train can only reserve 1 segment ahead, then the entry signal is set to a yellow, if it can reserve 2 segments then the first signal is double yellow, while the second is yellow. If it can reserve 3 segments ahead, then the next 3 signals are Green, Double yellow, Yellow.

When a train moves past a signal the reservation attempts to extend by 1 segment. If it can't then nothing happens and the train will slow down as it passes the yellows. If the reservation extension is successful then the signals ramp-up 1 notch, so that the train passes a green.

[Goal 2]
The next step after this is to alter the signal "steps" by the current speed of the train. If the train can only travel at 40mph, then the signals are always green (no yellows), and the reservation will only be 1 segment. If the train can reach 80mph then it extends 2 segments ahead and yellows are used... etc, etc...

[Goal 3]
Junction Aspects are when the train is destined to come off the current line and onto another. Generally if the junction doesn't have many turns then it won't need to slow the train down. However, if the train will need to turn many times along its path then the train is deliberately slowed down before the junction entry signal. This is usually done with 'flashing yellows' preceding the junction signal.

[Goal 4]
Combination of MAS signals with SignalEx, to define complex junctions. Visually the signals show feathers (direction indicators). Internally the signals can be programmed to help the pathfinder direct certain trains down specific routes.

That's the plan, I just need to figure out how to alter the graphics and I'll post the first attempt at the Goal 1. A slight problem I need to fix with the reservation extension and I need to add on the ramp-up of signal states, then I need to add in code so that when a signal is passed, the speed limit is applied the train (I've added train limits, so just need to update them).

[tsjook]

Wow, really impressive! I'm looking forward to any release.

Are these signals designed with realistic deceleration in mind?

[Benny]

Always hate it when a slow freight train crosses a junction one second before an express train comes in from another line. This will help me a lot!

Looking forward to a release. (And a binary. *Hint, hint* )

[FHS]

Seems like a great idea. This patch is obviously based on your SignalEx idea.
Good Luck with your Patch.

PS: Could you please post a diff file and a compiled version for windows.

[crakinshot]

Well no praises yet please, its mostly the work of Jafinto (http://www.tt-forums.net/viewtopic.php?f=33&t=42675) at the moment; with some changes to limit the extension. However, there are a load of changes I'm making now to 'ramp up' the speed limits on the signals.

Actually, most of these MAS signals won't be extended with a pool item. I can simply store the aspect code in a few bits in m7, rather than have a SignalEx object. The SignalEx objects will come into play when you want to control a signal that leads into a junction. i.e. you don't want trains to have extended reservations past that signal unless a condition is meet.

Are these signals designed with realistic deceleration in mind?

Eventually yes, the trains will only reserve up-to the safe stopping distance, thus slow trains will try to reserve shorter lengths, while faster trains will reserve longer paths. So basically if you have a very fast train and the signals on a line are spaced ever 1 tile, then the train might need to reserve 8 tiles (8 signals) ahead.

Once I work out how to do the new sprites I'll release it, otherwise it'll be a little boring.

[2007Alain2007]

by the sound of it this patch when its made will be able to give more room between trains

how dose it deal with the end off the line?

[adf88]

Great! Maybe soon it'll be possible to make game more realistic and disallow braking faster then trains ability.

To achieve this aim there shouldn't be a hard speed limit, but a limit calculated according to trains speed, breaking ability and distances to next obstacle, so the train could ride with maximal safe speed and break fluently. Also hard number of three semaphores is not the best choice. Train should reserve as much as it need to make a full brake. If you are interested I can help.

[Tekky]

Great! Maybe soon it'll be possible to make game more realistic and disallow braking faster then trains ability.

To achieve this aim there shouldn't be a hard speed limit, but a limit calculated according to trains speed, breaking ability and distances to next obstacle, so the train could ride with maximal safe speed and break fluently. Also hard number of three semaphores is not the best choice. Train should reserve as much as it need to make a full brake. If you are interested I can help.

Yes, that is exactly how train braking works in Locomotion (the official successor to Transport Tycoon).

If I recall correctly, trains automatically slow down in Locomotion before a red signal, even if there is no yellow signal in front of the red signal. Even if there is a yellow signal, this aspect of the signal merely provides visual feedback to the player, indicating to the player that the train will not be able to pass this signal at full speed, due to the upcoming red signal. The train itself ignores the yellow signal and treats it as green. Therefore, the position of the yellow signal is irrelevant, as the train will only start braking when it reaches braking distance to the red signal.

I think that this implementation used in Locomotion would also be also the best implementation to be used in OpenTTD.

[crakinshot]

Well that's not exactly the point of what I'm doing. later on when I play with the deceleration stuff, I'll probably have the train "look ahead" 3 tiles, if it can "see" a red signal then it begins to slow down to stop. If the train is going too fast then it won't be able to.

What you're suggesting is that a train looks ahead all the way to the red signal and slows down many tiles away. This isn't what happens in reality. In reality the yellow signals indicate to the driver that a red signal is ahead and they should begin to slow down. i.e. the driver cannot see the red signal. Once they can its too late if they are running past 60mph.

In the context of a game, such as OpenTTD, the distinction is that if you position your signals too close together then the train won't have enough warning and won't be able to slow down fast enough. This will essentially force you to have a minimum of 3 tiles between signals (for example), otherwise trains will fly through reds and collide with whatever.

Really, its adding a difficulty to the game. If you don't set up the signals correctly and run fast trains, you could have SPAD events and trains colliding. But this is a bit off-topic here, see http://www.tt-forums.net/viewtopic.php?f=32&t=45263

[Tekky]

I really like the work you are doing in this direction. However, I have the following comments:

later on when I play with the deceleration stuff, I'll probably have the train "look ahead" 3 tiles, if it can "see" a red signal then it begins to slow down to stop. If the train is going too fast then it won't be able to.
(...)
Really, its adding a difficulty to the game. If you don't set up the signals correctly and run fast trains, you could have SPAD events and trains colliding.

Instead of making trains overshoot red signals, I believe it to be more meaningful to make the previous signal show yellow, even if this yellow signal is very far away from the red signal. That way, the player would be penalized by his trains going very slowly instead of penalizing the player with train crashes.

What you're suggesting is that a train looks ahead all the way to the red signal and slows down many tiles away. This isn't what happens in reality. In reality the yellow signals indicate to the driver that a red signal is ahead and they should begin to slow down. i.e. the driver cannot see the red signal. Once they can its too late if they are running past 60mph.

Yes, what you describe is what happens in reality, in the UK. However, what I describe is how high-speed trains work in Germany, at speeds above 160km/h (=100mph).

In Germany, there is a strict distinction between pre-signals and main signals. Pre-signals ("Vorsignale") warn a train of the aspect of the next main signal ("Hauptsignal") at braking distance. These pre-signals have no other purpose, since they can never show red, although it is not uncommon in Germany for main signals and a pre-signal for the next main signal to be placed on the same signal mast, which would be equivalent to a UK signal capable of displaying the yellow aspect. However, there is no such thing as double yellow signals in Germany. For speeds above 160km/h (=100mph), pre-signals are not used at all in Germany, since the braking distance required between a pre-signal and a main signal would be too large. Instead, continuous train control is used, which warns a train up to 10km (~6 miles) ahead of a red signal to start braking.

What Locomotion does is identical to the German system of continuous train control for high-speed trains, as trains automatically start braking as soon as they are within braking distance of a red signal. Your system, which is based on the UK signalling system, requires however, that the player places the yellow signals at braking distance manually. This has the following disadvantages:

1. It may not always be clear to the player how far apart the yellow signal must be from the red signal.
2. It may be hard for the player to find room to place the additional signal at braking distance, especially if a junction is in the way.
3. Currently, all signal locations are considered safe waiting locations by OpenTTD. This would mean that placing a signal in a junction that is intended to show yellow will also sometimes display red and cause trains to wait in front of that signal, even if this means the junction will be blocked. Therefore, you may have to introduce an additional signal type that can only show a green and a yellow aspect, but never red.

However, for fans of the UK signalling system, I am sure your patch would be very interesting. But for normal players, I still think it would be best to have implicit yellow signals automatically set at braking distance, as is the case in Locomotion. Maybe you could introduce a patch setting that specifies whether yellow signals should be implicit or explicit?

In the context of a game, such as OpenTTD, the distinction is that if you position your signals too close together then the train won't have enough warning and won't be able to slow down fast enough. This will essentially force you to have a minimum of 3 tiles between signals (for example), otherwise trains will fly through reds and collide with whatever.

In the case of having one signal per tile, I believe it may be appropriate to introduce an additional signal aspect: Turn the signal off. That way, the last signal at safe braking distance would display yellow and all further signals up to the red signal would be turned off. This would seem more meaningful to me than to penalize players with train crashes for placing additional signals.

[crakinshot]

What you're asking for has nothing to do with signals essentially, you'd simply hard code the train to look ahead for a red. Plus, most signalling systems so far have required the driver to observe the signals, rather then the information to be displayed in the cab. Starting a game at, say, 1920 you'd only have red and yellow semaphores. Unless I'm mistaken Japanese signals are also 4 aspect (if not 5 in fact)...

What you'd need is Positive Train Control (http://en.wikipedia.org/wiki/Positive_Train_Control) or ETCS (http://en.wikipedia.org/wiki/European_T ... rol_System) , whereby the train knows (is informed) of the track condition ahead, rather than observing it from the signals. But this is a different idea completely, and in fact makes signalling nearly obsolete. Also see: http://www.railwaystrategies.co.uk/arti ... ssueid=262

Plus this is probably the wrong thread. These signals aren't for 'realistic breaking' they just impose dynamic speed limits.

[Tekky]

What you're asking for has nothing to do with signals essentially, you'd simply hard code the train to look ahead for a red.

Which is, as far as I can tell, equivalent to having an implicit yellow signal at braking distance, instead of the explicit signal you suggested. Ok, what I just said is not quite correct, as when the red signal jumps to green, the behavior will be different: In Chris Sawyer's Locomotion, a train would immediately start accelerating, whereas using traditional UK signalling, the train would have to first slowly approach the signal until the driver sees it has switched to green. But apart from that, I am unable to see any difference.

What you'd need is Positive Train Control (http://en.wikipedia.org/wiki/Positive_Train_Control) or ETCS (http://en.wikipedia.org/wiki/European_T ... rol_System) , whereby the train knows (is informed) of the track condition ahead, rather than observing it from the signals. But this is a different idea completely, and in fact makes signalling nearly obsolete. Also see: http://www.railwaystrategies.co.uk/arti ... ssueid=262

Yes, that is similar to what I was referring to as "continuous train control". However, it was not my intention to suggest implementing all the features of continuous train control into OpenTTD. For example, I had no intention to suggest replacing fixed blocks with moving blocks, as this would make many signals in OpenTTD obsolete. Instead, it was merely my intention to point out the technical possibility of trains receiving sufficient early warning of red signals, which is equivalent to having an implicit yellow signal at braking distance.

Well that's not exactly the point of what I'm doing. later on when I play with the deceleration stuff, I'll probably have the train "look ahead" 3 tiles, if it can "see" a red signal then it begins to slow down to stop. If the train is going too fast then it won't be able to.

Plus this is probably the wrong thread. These signals aren't for 'realistic breaking' they just impose dynamic speed limits.

The above two quotes of what you said seem contradictory to me. Do you or do you not plan to combine yellow signals with realistic train braking behavior?

[crakinshot]

Well in the context of this thread these signals have nothing to do with realistic deceleration, mealy make it a little more viable to achieve. I may have a go at realistic deceleration, but its not so clear cut as to how you do it. For one, non-PBS signals are out completely. You'd probably have to use the moving block method and have all the signals just there for show / traffic direction control.

Its not something I want to think to deep about, at the moment. At least not until I've finished these signals, which might take a while once I get onto the programmable side. I'll upload what I have for the sprites so far and you'll understand.

[Tekky]

Yes, how to handle non-PBS signals will be a big problem. The only viable solution I currently see would be to treat them as PBS signals.

I agree that you should not try to implement too much at once. However, it is important to have a clear design goal that is well thought through. For example, I recently made the mistake of starting programming work on something in OpenTTD, only to later discover that my design was severely flawed and that my approach was wrong.

[crakinshot]

True, but what your asking for (German system) in reality would require a big change to how its done in the UK. In effect they are two very different ways of governing the train. These multi-aspect signals should be okay for the UK system, and any system where the train speed is governed by what the driver can see. Ironically, the biggest problem at the moment (in reality) is trying to upgrade the UK system to the moving block method.

Anyhow, just to show you the complexity, here are the signals for the front-on view (I think a few cases are missing). I plan to do a proof of concept (in game) before I draw the others. I'm not sure its feasible yet. Will probably try to add the feathers after the main signals though.

[Tekky]

Your signals look nice.

However, since it would be hard to define which route is a main route and which route is a diverging route, I am not sure if it is meaningful to use these feathers in OpenTTD. Maybe these diverging routes could be defined by the player manually by using your SignalEx structure? But, as you said, this problem is not the immediate problem.

[crakinshot]

That's the plan. I was thinking of some kind of automatic setup and then allow the user to customise it later. I've not decided on how to define the divergent paths yet.

For example;

divergence.png (34.5 KiB) Viewed 15160 times

The yellow is straight track, with no divergence (i.e., its the piece of track which can be followed without a choice of left or right tracks). The red are first level divergences and the blues are second level divergences.

The problem would be when you have a Y junction and it not easy to work out which is the mainline.

[Tekky]

I am pleased to see that your concepts are well thought through. One advantage of the indications of diverging routes would be that it would no longer be necessary for track reservations to be highlighted, as the feathers on the signals would provide sufficient information.

About the Y-branches: I guess, in such situations, it would be best to not indicate a main line at all, i.e. to always indicate a diverging route.

[Tekky]

About manually defining routes by the player:

I would like to add that besides defining which routes are diverging for a signal, there is another use for the player to be able to manually define routes for a signal: Route restriction. Therefore, providing an interface for defining routes would also make the implementation of route restrictions a lot easier.

[crakinshot]

Aye, that is also the plan. While feathers are interesting to look at, in practice its only really useful if you also add on programmed restrictions to direct trains/types of cargo/max train speed.

Corrected feathers for front view. Indexing to sprites should, in theory be (SIGNAL_MAX_NUM_LEFT*7 + SIGNAL_MAX_NUM_RIGHT * 28 + SIGNAL_LEFT_RIGHT_STATE). With LEFT3 = 0, CENTER = 3, RIGHT3 = 6, etc... with the top row being essentially blank. The NW and NE signals will be a royal pain to look correct. :/