Train-waiting-at-signal penalty resets on recalculation

[tocrafty]

As described in Railway of wiki,

When the path includes a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited.
-------------
The train has waited at a chain signal for a multiple of 5 seconds.
If the trains has waited for a multiple of 30 seconds or if multiple train stops with the name of the destination exist, the train is forced to recalculate its path.

a train waiting for a rail signal will increase the penalty of segment every 0.1 for a tick.

However, it seems that penalty of waiting time is cleared to zero every recalculating.

Here are three stations, A, B and C, three trains, red, blue, and green. All trains are in auto mod. Red train want to go to station B, green train want to go to station A, and blue train want to go to station A too.

railway.png (2.38 MiB) Viewed 2588 times

The penalty of middle segment is 2000, since there is a station in it. The penalty of below segment start with 100, and add 0.1 every tick. At first glance, the penalty of below will exceed the penalty of middle, thus, green train will choose middle segment instead of below. However, this could nerver happen. The penalty of below is restart from 100 whenever blue train is repathed(30 seconds), and could never exceed 2000 of middle.

I have tested with mod Pathological. If set Train Waiting At Signal Tick Multiplier Penalty from 0.1 to 2, green train will go to station C after 4 repath. Note 4 repath need 20 seconds, it's not long enough(30 seconds) for blue train to repath. The penalty increased 120 every second, thus, after 4 repath, the penalty of below segment is at least 120 * 20 = 2400 which is greater than middle.

In summary, when repath happens and train is still not moved, the accumulated penalty of waiting time should not be cleared!

[disentius]

Hm.. Maybe this rule comes into play here?

A rail block changes and invalidates a signal (chain or regular) along the train's path. The train is forced to recalculate its path.

[quyxkh]

Yah, except train-waiting time shouldn't be a since-repath attribute, it should be a since-entered-block attribute. Just record the block-entry tick and be done with it. The evidence on this seems clear, the train's been there forever, no {con,de}struction occurred, but its path penalty hasn't accumulated.

[Stevetrov]

This is one of the situations I was thinking about when I made this suggestion.

[boskid]

Tested this after 79640 (part 2) fix. After 11 repaths upper trains swapped places so i assume this is fixed. Unfortunately this topic will land in Duplicates.