momsleft.blogg.se - Openttd path signals

#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:

exclude-signal-on-path-reserve.patch (1.82 KiB).

This seems to be the usual case for PBS signals as well, not sure why non-PBS signals should behave differently.īoth do solve the particular issue, however, I am not familiar enough with the code to judge on potential side-effects. The reservation in this case is handled by the TrainController.Īnother attempt is to actually exclude the signal tile from the path reservation, avoiding merging of reservations. This is also in line with what happens in CmdRemoveSingleRail. One attempt which did solve this particular issue was to FreeTrainTrackReservation and not to TryPathReserve for CmdRemoveSingleSignal. Since the path actually only ends at T1's end of reserved path (since they are connected), the call would free also the reserved path of T1, which is not nice either. Thus, the subsequent call to FreeTrainTrackReservation(T1) will free the reservation of the wrong train.īut even if it was returning the expected T0, the subsequent call to FreeTrainTrackReservation(T0) would follow the reserved path until it ends.

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.