

- #OPENTTD PATH SIGNALS HOW TO#
- #OPENTTD PATH SIGNALS PATCH#
- #OPENTTD PATH SIGNALS CODE#
- #OPENTTD PATH SIGNALS FREE#
A block becomes free when trains are behind the signals. Here in your case, you must consider that there is a train *inside* the block. And a block *is not* free as long as there is a train inside it.
#OPENTTD PATH SIGNALS HOW TO#
So in the end the removal of the signals could possibly be made slightly safer by not reserving through the next train but I have no real idea on how to do that right now.Keoz wrote:The problem is that the intermediary block (that one in front of your waiting train, before the station) is still considered as occupied because the train which is in the station (in the third platform from right) has its ending over the tile with a signal.īut it should got to the far right two blocks but it doesn't.ĭon't forget that entry/exit signals, beside having a specific behaviour, also act primarily as block signals. the new signals act after the state of the current reservations. Adding signals is safe since it just adds more signalling blocks, but it keeps the current reservations in place, i.e. Just imagine that people started to remove signals on a live real world track. Having said that, removing signals is a so-called dangerous action that can trigger train crashes. So simply terminating a reservation at newly built signals is not really a nice feature.
#OPENTTD PATH SIGNALS CODE#
To make matters worse, the code is written with the idea that yellow aspects of signals could be introduced so a reservation may specifically run through a path signal until another signal (especially so trains don't go into an infinite G deceleration when stopping at a red signal).
#OPENTTD PATH SIGNALS PATCH#
Sadly enough removing the clearing of the reservation from your patch doesn't solve the issue. With the no try reserve patch you'll get a crash, without it you don't. For example, in the attached savegame: remove the signal that train # 2 has just passed and then unpause the game. This means that a train that has a route through a junction gets its reservation cancelled and another train may pick that reservation up. The no try reserve patch seems to work better, but I'm not fond of removing already existing reservations upon removing signals. You'll notice they'll get stuck on the diagonal bits. The exclude signal on path reservation patch definitely seems to break at least signals on diagonals just perform the tasks to reproduce this issue with the patch applied and then start all trains. Thank you for this attempt at fixing this bug, sadly enough both fixes break other things. This comment was imported from FlySpray:

So, now, when placing a PBS signal at S0, GetTrainForReservation in CmdBuildSignal is returning train T1 (due to the connected paths and since (in this case) SE direction is checked before NW). What makes things worse is that the signal tile is included in the reservation and now the reserved paths of train T0 and T1 are connected.

This sounds already a little bit strange, since now we have a reserved path which does not end at a PBS but a normal signal. When removing signal S0, the call to TryPathReserve in CmdRemoveSingleSignal is reserving a path for train T0 to the next signal at S1. The behavior is the same on trunk r27100.
