So simply terminating a reservation at newly built signals is not really a nice feature. 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). 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 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.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |