Circuit wait condition on an interrupt does not cause the train to leave, the condition flickers constantly

[shardmutex]

What did you do?

I am setting up a generic train pickup / drop off system using train interrupts. The train is sent to the drop off station by a generic item interrupt. At the drop off station, I want the train to leave when a circuit condition is set. (This condition is set when the drop off station has received enough of the resource by measuring a chest.)

I have reduced this down to a minimal example and have provided the same setup with a regular schedule to compare the two behaviours.

What happened?

The train with interrupt does not leave the drop off station in response to the circuit condition being set. If I open the train UI while it is waiting, the circuit condition I set toggles constantly between on (green) and off (gray), indicating that the train receives the circuit condition but then immediately loses it, then regains it, and so on. This appears to be happening every alternate frame.

Additionally, on the same UI, the train status in the upper left window toggles constantly between 'working' and 'waiting at station'.

What did you expect to happen instead?

The train should leave the station when the circuit condition is set, and the temporary stop created as a result of the interrupt condition should be removed.

In the save file provided, the left train loop shows the problem with the interrupt, while the right train loop shows the same setup using a regular schedule. The right loop shows the expected behaviour of the train leaving the station when the circuit condition is set.

To start each train moving and show the behaviour, please place 50 iron ore in the cargo wagon.

Does it happen always, once, or sometimes?

Always - when using interrupts that complete on the basis of circuit conditions. The train will never leave on the basis of the circuit condition.

Note: Potentially related to viewtopic.php?t=119399, but that described an issue with initiating an interrupt using a circuit condition. This issue relates to completing an already active interrupt using a circuit condition.

Thank you.

[shardmutex]

I think I figured it out. The interrupt is "retriggering" on the same interrupt on the same station repeatedly.

When the train tries to leave based on the circuit condition, it still has cargo in its hold (since the drop off station doesn't always empty it). So the 'go to drop station with cargo x' repeatedly refires for the same station - it still has cargo x - so the train leaves and reenters the station constantly.

I resolved it by adding another condition to the trigger to check for the absence of the leave signal. This prevents the interrupt triggering itself.

signal-fix.PNG (34.54 KiB) Viewed 451 times

So maybe not a bug in the end, but I did not expect the interrupt to target the same station it is trying to leave.

[Loewchen]

I don't see any flickering in the first place, both trains are waiting in their stations because the wait conditions are not satisfied.

[shardmutex]

Did you put 50 iron ore in the cargo wagon? This will cause the trains to leave their initial station - the problem occurs when the train reaches the other train stop (the drop off station).

Sorry I wasn't sure the best way to show it, so I had them start from the pickup station.

[Tertius]

I think I figured it out. The interrupt is "retriggering" on the same interrupt on the same station repeatedly.

When the train tries to leave based on the circuit condition, it still has cargo in its hold (since the drop off station doesn't always empty it). So the 'go to drop station with cargo x' repeatedly refires for the same station - it still has cargo x - so the train leaves and reenters the station constantly.

This is a quite common situation, and the proper way to handle this is to disable the station or set its train limit to 0 as soon as the circuit decides the station has enough cargo. This way no train will target this station again until it is opened again. It's fine the interrupt triggers again if the train still has cargo, because this will now target some other dropoff station with the same name. The train will leave and go to that other dropoff station with the same name.

In case there are no other dropoff stations with the same name or all of them are closed (disabled or train limit 0), the train will stay. This is usually no issue, because the station is full and doesn't expect any other train. However if you want to make the train leave even if all the dropoff stations are closed, you need a replacement destination, called a depot. A depot is a bunch of stations with the same name and no loading/unloading facility. Just a waiting area.

Now add another interrupt that triggers on the condition "'destination full or no path' AND not at depot". As destination station use the depot station name. Allow it to interrupt other interrupts. This way the train will go to the depot if its current destination is full. As waiting condition in the depot use "inactivity 0" or 1 or something like that. If it's elapsed, the regular schedule or interrupt triggers again and the train will have some next destination and wait at the depot until it's able to proceed to that destination.

Having said that, this isn't a clean approach in the first place. A clean solution would be to let trains only leave if they're empty. Never release a train that still has cargo. This makes the whole interrupt configuration cleaner and easier.

[Shadowhawk]

I think I figured it out. The interrupt is "retriggering" on the same interrupt on the same station repeatedly.

When the train tries to leave based on the circuit condition, it still has cargo in its hold (since the drop off station doesn't always empty it). So the 'go to drop station with cargo x' repeatedly refires for the same station - it still has cargo x - so the train leaves and reenters the station constantly.

This is a quite common situation, and the proper way to handle this is to disable the station or set its train limit to 0 as soon as the circuit decides the station has enough cargo. This way no train will target this station again until it is opened again. It's fine the interrupt triggers again if the train still has cargo, because this will now target some other dropoff station with the same name. The train will leave and go to that other dropoff station with the same name.

In case there are no other dropoff stations with the same name or all of them are closed (disabled or train limit 0), the train will stay. This is usually no issue, because the station is full and doesn't expect any other train. However if you want to make the train leave even if all the dropoff stations are closed, you need a replacement destination, called a depot. A depot is a bunch of stations with the same name and no loading/unloading facility. Just a waiting area.

Now add another interrupt that triggers on the condition "'destination full or no path' AND not at depot". As destination station use the depot station name. Allow it to interrupt other interrupts. This way the train will go to the depot if its current destination is full. As waiting condition in the depot use "inactivity 0" or 1 or something like that. If it's elapsed, the regular schedule or interrupt triggers again and the train will have some next destination and wait at the depot until it's able to proceed to that destination.

Having said that, this isn't a clean approach in the first place. A clean solution would be to let trains only leave if they're empty. Never release a train that still has cargo. This makes the whole interrupt configuration cleaner and easier.

The proper way is to not send to go to dropoff station X signal to begin with really.
Also disabeling or changing the train limit does not change trains already en route to the station only new trains ( at least the limit works that way)

Best way is to figure out why the trigger keeps fireing.

[Tertius]

Best way is to figure out why the trigger keeps fireing.

I guess there's a misunderstanding on how interrupts should be used best. Many players use the interrupt conditions as an asynchronous if, for example "if (have cargo and I'm not at dest and dest is free) then (go dest)". They assume they have to make the interrupt only trigger if the intended destination is actually free and not trigger that interrupt until the destination is free. But this isn't the best solution.

Notice how often dest is used in the condition and also in the destination. This term has an edge case (a race condition) you try to avoid with the convoluted trigger destination in the first place. If there are two or more trains checking this trigger condition at the same time and dest is free, the interrupt will trigger for both trains. Now both have dest as destination, but if dest has a train limit of 1, only one train will start and the others will stay and block the current station. And this blocking due to a full destination is what you wanted to avoid in the first place!

It's better if you write more simple generic interrupts and don't check in every interrupt where the train currently is and if a destination candidate is currently free. Don't think two steps ahead - only deal with the current step.
Determine your cargo and unconditionally send the train to the corresponding destination, no matter if it's free or not. A very simple interrupt: condition cargo full; target <cargo wildcard> unload; waiting condition cargo <cargo wildcard> = 0.

Now you complain the train will stay at the loading station if every target is full. So you add an interrupt to send the train to a depot that buffers full trains:
condition destination full or no path AND not at depot; target depot; waiting condition 1 second inactivity. Activate "allow interrupting other interrupts". This depot interrupt replaces the temporary schedule entry with the destination that's currently unavailable with the depot as destination.

This way the train will be redirected to the depot if the current destination is full. At the depot the interrupts trigger again. This is the only interrupt where it's useful to check the current location, so the depot interrupt isn't triggered when the train is already at the depot. In the depot the train stays at the depot with the final destination already set. It will stay there until that final destination opens up. Actually one of the trains at the depot with that destination will start, if there are multiple trains with the same destination.

If used this way, the interrupt order is important. First interrupt is the refuel interrupt. Second interrupt is the delivery interrupt that sends the train to the delivery destination. The last interrupt is the depot interrupt that triggers if one of the previous interrupts set an invalid/full destination.

This way you don't have to deal with AND/OR constructs to check if you're currently at some station or if some station is currently full or not full. This can get convoluted, since you don't have parenthesis to group ORed condition terms - just ANDed condition terms stick together. If you're able to leave out any station condition and just deal with cargo conditions, the whole interrupt trigger can get way more simple.

[shardmutex]

This is a quite common situation, and the proper way to handle this is to disable the station or set its train limit to 0 as soon as the circuit decides the station has enough cargo. This way no train will target this station again until it is opened again. It's fine the interrupt triggers again if the train still has cargo, because this will now target some other dropoff station with the same name. The train will leave and go to that other dropoff station with the same name.

In case there are no other dropoff stations with the same name or all of them are closed (disabled or train limit 0), the train will stay. This is usually no issue, because the station is full and doesn't expect any other train. However if you want to make the train leave even if all the dropoff stations are closed, you need a replacement destination, called a depot. A depot is a bunch of stations with the same name and no loading/unloading facility. Just a waiting area.

I see what you're saying about the depot, that looks like the missing piece.

This originally came about from a larger example I was working with where I do set the train limit to 0 once the drop off station has reached its limit - the station calculates how many trains to send based on current resource level.

Both things happen when cargo > limit:

• green checkmark is set (train should leave)
• train limit is set to 0 (it calculates 0 trains currently needed)

In this case, instead of the train 'flickering' like it does in the example - it no-paths to the same station. It's the only drop-off iron ore station, so:

• the interrupt fires because it still has iron ore
• the only iron ore drop-off station has train limit = 0
• the temporary stop no-paths and requires manual reset

The confusing aspect for me was that I didn't expect the train to try and path to the exact same station it is trying to leave from the same interrupt condition it just fulfilled. The new temporary stop being the same stop it's currently sitting at made me think it didn't get the signal to leave. So I tested with just the leave signal and encountered the flickering behaviour, which didn't look right.

Having said that, this isn't a clean approach in the first place. A clean solution would be to let trains only leave if they're empty. Never release a train that still has cargo. This makes the whole interrupt configuration cleaner and easier.

True for sure. I was trying to set maximum limits each station should have and see if I could get that working. It's definitely easier to let the train empty and accept a bit beyond this amount, I will probably just do this instead. Thanks for your comments!

[shardmutex]

Best way is to figure out why the trigger keeps fireing.

This way the train will be redirected to the depot if the current destination is full. At the depot the interrupts trigger again. This is the only interrupt where it's useful to check the current location, so the depot interrupt isn't triggered when the train is already at the depot. In the depot the train stays at the depot with the final destination already set. It will stay there until that final destination opens up. Actually one of the trains at the depot with that destination will start, if there are multiple trains with the same destination.

Wanted to share another solution I found which works the way I was intending.

I changed the "checkmark != 1" condition in the screenshot from my previous post to a "station not full" condition (e.g. (item wildcard) drop is not full) for the drop-off station. In combination with setting the train limit to 0 for "full" stations, this prevents the interrupt triggering for the same station that was just filled.

(I have a small stacker at each pickup station that handles empty train arrivals using the train limit - trains can always return to a pickup area.)

What this allows - a full train can visit multiple drop-off stations before returning to item pickup. If each of those stations requires only a small amount of the resource, one full train can supply them all in one round trip, rather than pickup -> drop off 1 -> pickup -> drop off 2 etc. When no more drop offs are available (all are at train limit = 0) the train returns to the pickup station, even if it isn't empty.

Not useful for bulk resources like ore but could be useful for other things used in smaller quantities, such as sulfuric acid for uranium mining.

Appreciate your comments as they've helped me understand this in a better way.