[Rseding91] [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.

[Rseding91]

Do you have some sample save file that shows the issue? Looking at the code I don't see anywhere that looks wrong which makes me wonder if it might be the setting of the schedule through the lua API breaking the logic.

[Tekbox]

I separately ran into this issue (also while trying to do something for cybersyn and was pointed to this post)
I replicated the issue with entirely vanilla features by adding a temp stop using the train gui. And from what I've seen it seems that interrupts can simply not trigger under any circumstance while there is a temp stop anywhere in the schedule, doesn't matter if it is before or after the current stop or buried beneath regular stops. As long as it exists interrupts do not trigger.

[Harag]

Here you go. That's the savegame I manually assembled for the initial post, no API calls involved.
Observe how the train's interrupt does not trigger before or after the temp stop when you start the train by sending it to A and let it do it's thing.

Looking at the code I don't see anywhere that looks wrong

Maybe my expectation is wrong that rail stops should trigger interrupts?
I would find that ... unfortunate, though.

[Rseding91]

Looking at the code, it seems it's explicitly set up so if there is a temporary stop in the schedule the train does not do interrupts. It seems to work this way so when you tell a train to go somewhere using the temporary stop logic, it always goes there and doesn't get re-routed somewhere else due to interrupts.

So this is working correctly.

[danbopes]

Perhaps it would be better to differentiate internally if it's a temporary stop created by script or by the player?

[Rseding91]

Maybe. But the logic was not written for "temporary stops made by scripts". It was made for player interaction and then a lua API was added to interact with that.

[Harag]

It was made for player interaction and then a lua API was added to interact with that.

If that's the reasoning behind it I think temporary named stops (not rail stops) should work with interrupts because those can only be created via API.

Not that it helps my use-case much because I'm still forced to put rail-stops in-between to achieve point-to-point schedules.