[2.0.15] Train interrupts removing limits of next stop

[Folko]

Hi,

I am not sure if this is a bug or intentional, but I personally find one aspect of train interrupts very unintuitive and it requires workarounds that are sometimes very difficult. IMHO, the system would be a lot easier if this was fixed:

• consider two trains A and B with a schedule like this:
  • Station "Provider": wait until cargo full. 2 stations with a static train limit of 1.
  • Station "Requester": wait until cargo empty. 1 station that dynamically sets train limit to 0 or 1.
  • Interrupt "Fuel": if low on fuel, go to station "Fuel".
• Both trains are idling in "Provider", waiting for "Requester" to set its limit to 1
• Station "Requester" sets its limit to 1
• Train A starts its schedule while B will keep waiting, station "Requester" is now at 1/1
• On its way to "Requester", the interrupt is triggered in train A and the schedule changed to "Fuel". This resets "Requester" to 0/1.
• This will make train B start its schedule, setting "Requester" to 1/1 again.
• B finishes its job before A is done refueling, so B returns to "Provider" and "Requester" is reset to 0/1.
• When A is done refueling, it will keep waiting in the "Fuel" station because "Requester" is next in schedule but at 0/1. This blocks other trains from refueling.

I believe that an interrupt should never reset the train limit of the next scheduled station since the train was already triggered to be on the way. IIRC, train limits were introduced to fix that enabling and disabling a station was triggering multiple trains at the same time. Interrupts are now reincarnating the original problem since an interrupt also temporarily interrupts the limit, making it possible to allow multiple trains to move away from their previous station.

I think that changing the behavior to make interrupt stations (or maybe just all temporary stops) not remove the reserved train limit slot in the next station would make the system a lot more sound. This is also not a fundamental change that would break existing interrupt-based designs since interrupts can't change the schedule, so I don't think anyone could make active and intentional use of the current behavior.

[jagholin]

I haven't used interrupts much so far, but to me the current behavior seems logical. Train A is not going to the station anymore, so it releases the reservation. Otherwise you might get "full" stations with no incoming or arrived trains because they are all get stucked in some interrupt or another.

The problem with your proposal that I see is that it only works in your case, and only because the trains presumably don't wait too long to be refueled. But people are using interrupts in all kind of crazy ways(like making dynamic schedules), so you have to consider how it works in all potential cases.

Also have some questions with interrupt behavior in general:

1. In my observations, interrupts trigger when the train leaves the station, not when it's already on the way. Can they trigger when the train is in the middle of the route to some station?
2. Isn't there an interrupt for "station full" condition? I think your problem can be solved by adding a depot where trains that get into the condition you described can wait in. By setting priority of the depot to the highest, you can also prioritize those trains to leave for the requester station first, so that depot itself doesn't get filled with trains that never go anywhere.

[Folko]

I understand your concern, but I don't think trains are supposed to stay inside of an interrupt for long periods of time. I'm comparing this to systems programming: You're supposed to handle interrupts very quickly because interrupted threads (i.e. trains on the way) will keep all their semaphores (i.e. train limit states).

[jagholin]

I understand your concern, but I don't think trains are supposed to stay inside of an interrupt for long periods of time. I'm comparing this to systems programming: You're supposed to handle interrupts very quickly because interrupted threads (i.e. trains on the way) will keep all their semaphores (i.e. train limit states).

it's not programming. There is nothing in the game that suggests that interrupts should be resolved in a timely manner.

[Kalanndok]

An interrupt that triggers will not reserve a place in the destination in the first place since the train will never have departed to that station.

An interrupt will never trigger while a train is holding a reservation to a destination where it is destined to go.

To be fair, there is the condition that once the interrupt is finished there might be no free station on the schedule. And that is absolutely logical because the interrupted train was never reserved at that station. That's imo the dispatcher's job to resolve and therefore part of the puzzle. That might be a simple depot station or maybe a large waiting area where trains go after refueling.

And bang...there is the use case for a multi station interrupt.

Btw...that the developers even implemented multi station interrupts shows that interrupts are by no means supposed to be short.

Also you are interpreting "interrupt" wrong. It's not an interrupt to the drive. It's an interrupt to the schedule which gets evaluated before reserving a slot on the scheduled destination.

[Folko]

Thanks for hinting me in the right direction. I assumed that interrupts were evaluated everytime the path finder is evaluated, but FFF 389 states that interrupts are only evaluated when a train wants to leave a station and then the interrupt is inserted before assigning the train to the next stop.