adf88 wrote:

Sorry, I uploaded wrong patch file. This is the right one.

Attachments

• fix_force_proceed_gets_reset_when_going_near_signals_r25742.patch (0.88 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723#comment12564

planetmaker wrote:

Pathfinder code is convoluted at best. We wondered... could it be simplified maybe?
maybe "if (HasSignalOnTrackdir(gp.new_tile, dir))" only? without the weird old condition?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723#comment12621

adf88 wrote:

HasSignalOnTrack would be ok, this way all types and combinations of signals would be equal, passing back of a PBS would decrease the counter as well as other signals do. Is this what you are suggesting?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723#comment12625

frosch wrote:

We wondered whether
+ if (HasSignalOnTrackdir(gp.new_tile, dir) ||
+ (HasSignalOnTrackdir(gp.new_tile, ReverseTrackdir(dir)) &&
+ GetSignalType(gp.new_tile, TrackdirToTrack(dir)) != SIGTYPE_PBS)) {
is equivalent to
+ if (HasSignalOnTrackdir(gp.new_tile, dir)) {

I.e. does the ( && ) imply the first condition and is superfluous?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723#comment12626

adf88 wrote:

With just "if (HasSignalOnTrackdir(gp.new_tile, dir))" trains would pass signals from back without resetting their "force proceed" status. You are not checking the back side at all, it makes no difference whether there is a signal or not. So no, it's not equivalent.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723#comment12628

Rubidium closed the ticket.

Reason for closing: Fixed

In r25955.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5723