[2.0.55] Train stop dispatch priority not respected for simultaneous interrupts

[blazenclaw]

Not entirely sure if this belongs in bug or feature request, but as per fff-395, emphasis mine:

The way it works, is that the priority of a train stop has two effects:

1. When searching for a destination, trains will prefer a higher priority train stop.
   
2. When trains are trying to leave a stop, trains at stops with higher priority are dispatched first.

Priority of current station is only respected for trains that actively have the target in their schedule; if multiple interrupts are triggering simultaneously, they trigger in order of train ID, not priority.

Picture and save of example, 2.0.55 with no mods (sandbox mode):

06-15-2025, 13-35-43.png (4.31 MiB) Viewed 208 times

Bug_TStop_Interrupt_Priority.zip

(2.22 MiB) Downloaded 19 times

Station "Bob" currently has a limit of 0 while all "Alice" stations have limit 1. The issue is observed when Bob's limit is bumped up to 1.

What did you do?

Tried to control which train gets a delivery from a bottlenecked station by adjusting priority of the stations from which the trains leave.

What happened?

This modulation stopped working once the trains were controlled by interrupts, instead of default scheduling. In the picture/save, when station "Bob" opens up, the first train to be dispatched is the red train (lowest ID), followed by green, then blue, then white, and repeats.

What did you expect to happen instead? It might be obvious to you, but do it anyway!

Ideally interrupts would follow the same prioritization scheme as trains with default scheduling. In the example, I would expect the white train (highest priority) to leave first, then red (2nd highest priority) while white returns, then loop those two.

To be clear, if these four trains instead have a default scheduling of "Alice, then Bob" without using interrupts, the priority works as expected; we get only the red and white trains visiting Bob.

Does it happen always, once, or sometimes?

Always. I have not thoroughly tested the interaction between trains that have interrupts and those with default scheduling, or interrupts of different groups, etc, but ideally the end-all would be determined by priority, not train ID.

[boskid]

I am going to classify this as a duplicate of 126786

[blazenclaw]

Thanks for the link, missed those posts.

On these:
"Lowest ID train is usually first to update" and "This behavior is literally that the trains are evaluated in order, first train checks its departure condition, it is true, it claims the train stop because there are no other trains going there, then second train checks its departure condition and regardless of it having a higher priority, it lets existing train to complete its travel as it was dispatched before."

As another poster mentioned, this would seem to imply that evaluating trains in order of priority would cause a more expected behavior across the linked reports. However, I quite suspect that's not a trivial change, given that train priority is a much less static list (among everything else I don't know).

In any case, thank you again for the quick response and all the wonderful work you've done!