[2.0.43] Interrupts don't trigger before temporary rail stops

[Harag]

(the temporary rail stop is at the orange circle)

Starting the schedule at A, the train will visit A -> temp -> B -> (A -> C -> B)*

Further testing shows interrupts are completely ignored if

• a rail stop is next in line
• the current stop is a rail stop

Giving the rail stop a wait condition or enabling "allow interrupting other interrupts" makes no difference.

I would have expected the interrupt to trigger at A -> temp (rail stop next in line).

Context

I'm reporting this in the context of using temporary rail stops to implement point-to-point schedules in Cybersyn.

Assume a more realistic schedule constructed via the new LuaSchedule API

1. (temp rail stop at Provider)
2. (temp) Provider
3. (temp rail stop at Requester)
4. (temp) Requester
5. (temp rail stop at Depot)
6. Depot

With this string of (rail, stop) pairs and the current interrupt behavior there is no opportunity in the whole schedule for an interrupt to trigger until the train returns to the depot. This seems counter to what interrupts are meant to achieve.

I know using rail stops in this way has many shortcomings but right now it's the only way to implement point-to-point schedules.

[robot256]

How does the "Interrupt other interrupts" setting affect this behavior? Is this a symptom of the logic assuming every temporary stop is an interrupt stop, instead of reading the "created_by_interrupt" flag?

[Harag]

How does the "Interrupt other interrupts" setting affect this behavior?

It does not. That was just a test to see if the train manager treats temporary rail stops as some kind of interrupt.

Is this a symptom of the logic assuming every temporary stop is an interrupt stop, instead of reading the "created_by_interrupt" flag?

Is this a known problem? I wasn't able to find information about that.

[robot256]

Ah, I missed that part of your post, sorry.

It seems like in your case at least, the current behavior is actually helpful, right? If an interrupt fired after it departed the temp rail stop and before it went to the temp provider stop, then after the interrupt finished it could go to a different provider than you intended.

I'm guessing the only interrupt you actually want to use on Cybersyn-controlled trains is for refueling? And I can see why it would be annoying that trains are only refueled when they have a job assigned and depart the depot.

[Harag]

Not triggering from a temporary stop is useful, yes - and also not surprising, considering rail stops are no named stations and cannot connect to a circuit network.

But not triggering from a normal stop when heading to a temporary rail stop is surprising.

[robot256]

I understand now, thanks. So the workaround might be to put the Depot in the permanent schedule twice so that the fuel interrupt runs in between them.

[Harag]

That's no good because the train will still travel all the way to the depot.
And interrupts will trigger once the depot is the only record in the schedule and its initial wait condition is satisfied.

Another problem is that Cybersyn can reuse trains right after a delivery so when a train keeps busy it might never get a chance to refuel.

[Harag]

It seems like in your case at least, the current behavior is actually helpful, right? If an interrupt fired after it departed the temp rail stop and before it went to the temp provider stop, then after the interrupt finished it could go to a different provider than you intended.

Thought about that some more. It's not actually relevant to Cybersyn because it creates temporary stops that don't have a condition and interrupts don't trigger on pass-through stops, even regular ones (B in my example).

The temporary stop in my example has a condition because I wanted to see if it has any effect.