YAPP Presignals [yellow signals]

[Eddi]

Disclaimer: this has nothing to do with the "Presignals" that were introduced by TTDPatch

In Germany, presignals are used to show the status of the next main signal
Presignals do not instruct the train to stop here, but instead indicate the train to slow down to stop at the next signal.
Presignals are positioned in braking distance to the main signal (1km). (there may be repeater signals in closer distance)
there exist semaphore and electric versions

reference: stellwerke.de [german]

in context of YAPP the behaviour could be:

presignals are not safe waiting positions regarding track reservations. track reservations always end at a main signal [or other safe waiting location]
a train passing a presignal tries to extend its present path reservation beyond the next main signal.
if that succeeds, the main signal and the presignal are set to green, and the train can continue safely at full speed.
if that does not succeed, the main signal is set to red and the presignal is set to yellow. the train will start to slow down to a target speed of 40km/h [value open to discussion]. it will repeatedly check if the track can get reserved. if the train approaches the last tile before the reservation, it will make a full stop until the path is free.

"combo" signals are both presignal and main signal in one place. for electric signals, a more modern system (Hl, Sk, Ks) could be used for display

this has two effects:

• trains can slow down if the line is conjested, reducing the need to stop at every signal, if the train ahead is slower
• a difficulty setting "realistic braking" could be introduced, denying the train "emergency braking" within 1 tile, so misplaced presignals could lead to trains skipping a red light, and potentially cause crashes
  (very fast trains like ICE that in reality exceed the 1km braking distance could be forced to reserve more than 1 signal ahead, guaranteeing proper braking distance)

(afaik only two signal types are still "free", so there might not be one-way versions of these signals)

[Brianetta]

Disclaimer: this has nothing to do with the "Presignals" that were introduced by TTDPatch

In the UK, what you describe is known as an advance signal.

[Bastiaan]

I think this is an exellent idea and a very good extension to PBS. This would solve so many more problems YAPP didn't solve yet. I even think this could change the whole signalling system, reducing the assortiment to three types of signals (main, advance and combo) in both 'normal' version and one-way version, all based on YAPP. This won't let us need the original signals any more.

[Eddi]

the old signals were kept mainly for backwards compatibility

especially the coop games abused them heavily in ways that cannot be converted to YAPP, especially not automatically.

i do not see them disappearing any time soon.

IMHO, a "one way" flag would be quite fitting in a "programmable signals" approach, but that leads a little far away from this feature.

one way signals should rarely be needed in YAPP layouts, as trains will try to avoid going backwards through a signal. if they do it anyway, you can mostly solve that by tweaking the pathfinder penalties. and if you really need a one-way combo signal, you can put a single one-way signal and a presignal behind it, it would not be a big limit when one-way combo signals are missing (and i see practically no use for a one way presignal.)

[Brianetta]

one way signals should rarely be needed in YAPP layouts, as trains will try to avoid going backwards through a signal.

Not rarely enough!

Just occasionally, I have an absolute requirement that a train never pass a signal in a certain direction. Often it's to guarantee that a way out from a busy area is never blocked by more trains coming in, or to stop leap-frogging at grade junctions. Tweaking the penalties globally isn't an adequate solution to specific problems, so I can't see any benefit to be had by removing one-way advanced signals (as PBS is called in-game, and not to be confused with advance signals).

[Eddi]

i did not say remove the existing one... i just said that i don't think it is worth creating two versions of every signal

[Tekky]

(very fast trains like ICE that in reality exceed the 1km braking distance could be forced to reserve more than 1 signal ahead, guaranteeing proper braking distance)

Just as a side note: In reality, the German ICE uses LZB (continuous speed control by Centralized Traffic Control) and not PZB (speed control at fixed places by signals). In other words, the German ICE high-speed train normally ignores signals, because its speed would be too high to react to a red signal in time anyway. Instead, the train's speed is continuously controlled directly by Centralized Traffic Control and the train reserves several signals in advance. On track which does not support LZB, the train must obey standard signals, but the train's speed is restricted to 160km/h in order to ensure that the train will be able to brake for a red signal in time.

I'm not sure if this concept of continuous speed control without the use of signals fits in well with OpenTTD, because OpenTTD without signals would be a completely different game. However, maybe a mixture of both concepts would be appropriate for YAPP signals in OpenTTD:

I think YAPP signals should be placed as they are now, in order to specify which locations are safe waiting locations. However, instead of having advance signals as Eddi suggests (which would clutter the view), I think a train should always be aware of the distance to the next red signal and always keep its speed low enough to brake in front of the next signal, as if the train were equipped with LZB. Because currently YAPP only reserves the path to the next signal and the next signal is always red until the train reaches the signal tile, this would cause the train's maximum permissible speed to often be very low. Therefore, a train should attempt to reserve a route past the next red signal, as soon as it would have to initiate braking for this red signal.

[T-Unit]

it will repeatedly check if the track can get reserved. if the train approaches the last tile before the reservation, it will make a full stop until the path is free.

I think that could be the biggest stumbling block of this idea. If it isnt well implemented then it could slow the game down a lot.

[Zutty]

I think a third signal state has been a suggestion that has floated around A LOT. It would be cool to have train speeds limited by track and signal types, as in real life, however this would add a fair bit of complexity to an already complex system.

Plus it would be a pretty big thing to implement, and I imagine some GRFs would need to change also.

[Eddi]

it will repeatedly check if the track can get reserved. if the train approaches the last tile before the reservation, it will make a full stop until the path is free.

I think that could be the biggest stumbling block of this idea. If it isnt well implemented then it could slow the game down a lot.

i don't see the problem there. it's exactly like now when the train is already waiting at the signal, just that it starts sooner.

[Tekky]

I also don't consider it a serious problem, as the problem with red signals will have to be fixed sooner or later, anyway. Currently, a train waiting at a red signal tries twice per second to find a new route, which is bad for performance if you have many waiting trains. This will have to be replaced by callbacks: Instead of the train continuously attempting to find a new route, it will ask to be notified when a certain track segment becomes free and only then will it attempt again to find a route. This requires extra memory, but is much better for performance.

[ostlandr]

I like the idea of a third ("yellow") signal state. I imagine that the code to get trains to run at other than top speed would spill over into the "speed limits" suggestion. I play very "engineering heavy" games with the 'heavy trains' patch set to at least 5, and with some sets/eras as high as 8 or 10. Having a realistically heavy train stop at a signal is harsh, especially on a grade (FYI I try not to place signals so trains stop on uphill grades, but sometimes there's no alternative.)

[Brianetta]

Having a realistically heavy train stop at a signal is harsh

Somehow, though, they always manage not to SPAD. (:

Hopefully advanced signals, advance signals and so on will eventually allow the devs to look at removing the "magic brakes" that trains seem to use on the half-tile before a red light.

[hertogjan]

I have once (I guess two years ago) attempted to write a patch that allowed trains to look ahead for a red signal and brake gradually a few tiles before it. Unfortunately, this was only possible on tracks without junctions (if I recall correctly, bends were not an issue). In order to make this feature work in all situations, one needs to know where a train will go. That means that you will have to "ask" the pathfinder where a train goes, and this makes writing such a patch very difficult. But maybe now there are some more experts on YAPF (pathfinder) and/or YAPP (PBS) who will be able to write a patch.

[Tekky]

If I remember correctly, in Locomotion (the official successor to Transport Tycoon Deluxe), trains are always aware of the distance to the next red signal and slow down accordingly, whenever they approach a red signal. The trains reserve a route ahead which is at least as long as their braking distance. This solution worked very well in Locomotion, because the behavior of trains looked and felt more natural, i.e. trains had no "magic brakes" that caused them to make an abrupt stop in front of a red signal. I think this solution is better than placing additional yellow signals as distant/advance signals that would clutter the display.

However, this does not mean that I am against yellow signals. In Locomotion, there are yellow signals too. If I recall correctly, Locomotion main signals (not distant signals!) always show yellow instead of green if a train's maximum speed is limited when passing the signal, i.e. if there is an additional red signal within braking distance. I think I like this solution best, because it gives the user nice graphical feedback with yellow signals without cluttering the display with additional distant signals.

However, these yellow signals provide merely graphical feedback and don't change the actual gameplay. The actual gameplay changes I have described in my first paragraph.