[2.0.14] Circuit condition trigger for interrupts will never fire

[DeutscheGabanna]

What did you do?
I tried to use "circuit condition" trigger for interrupts.

What happened?
The trigger never fires, even if you dumb it down to absolute simplest circuit condition ever.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expect these circuit conditions to fire the interrupt:

11-02-2024, 22-46-13.png (43.76 KiB) Viewed 614 times

As you can see on the screenshot, A with signal strength of 1 is equal to A with signal strength of 1. I set this condition up with constant combinators to make it absolutely repeatable.

But the dynamic circuits also fail. For example there: 800 is less than 1000.

Does it happen always, once, or sometimes?
Always.

Things I checked that might be preventing the interrupt from firing
There is a valid path to the pick-up stop. I do not see any alerts telling me otherwise and I can send it to that stop directly if I wanted.
The train is set to Automatic, not Manual mode of driving.
The train stop is configured to "Send to train", and as you can see on the screenshot, the train correctly sees the -800 signal.

[robot256]

What does the rest of the schedule look like? Did it already satisfy the conditions for leaving the current stop?

[Loewchen]

Post the save please, see 3638.

[jurgy]

Sometimes the train does get the signal and sometimes it doesn't.

I think I have a repro for the case where it stops retrieving the signal.

Blueprint:

Code: Select all

0eNrtW11zqzYQ/S88QwaJD0Fm2l/QafvQPt3JMBjLiSYYuUIkTTP5710hYkiuHK+c3La3cR4SEMthV9qzkg7kMVi1A98p0eng8jEQjez64PLLY9CL665uTVtXb3lwGahatMFTGIhuzf8MLsnTVRjwTgstuL1jPHmoumG74goMwuc7NdzaRb2WuyAMdrKHW2RnkAEmIjELg4fgkgH0Wije2IuEhkGva3sS/MZ7Hf1yx1Ur6zWAbOtuqNtqBO6rVmyFNh6FXzlB9070xvj6RkdjHIf9KF/6kTpAEw/QDAuaeoAmWNDMA5RgQXM0aFliMRkeEz1MBR4TPUolHhM9SCTGg6IHicz0a2Ujt1KLO+5ALIoLRtIiTdjcB7yrVy2vWnktei2avrq/EXC+lXeiuw4uN3Xb8zCQSsAzJ4bGF+b+RrZSGWRlWsq0ND9FEbMyZiRO05KSwtgBCMS8Gn/XI3EDofnWlhGxXhSdXrZiHW0GbkuPNQKbrhLdHTxeqgd703xGxsLR3I5HjRxMYaNQrZ5ML70AV7K55fpU9HiPnhjwK9cg4MtPgaYKmctPM6g7vh4ho9qVLrELlFAXKr7+FGgGEnz9KdAUJPj6U+A5OBegplbXMrqvr8HWAUmAL3H5brrQLFym1WOwqo0bTy7f8IWswNcHfCVj6NSk+ErG0ElEkZWMpR9Uyeh/upLRf6WSUXwlY2gmU/xCiqGZTPGFjKHZQvGFLMezBV/Icjxb5kLGeSS6jejgctTcmBV03RjuRDsF+b8Ga8eMUVzY4SPkIhsX+xag6rnWwJkxqxQHAvFqgGut5oqvqynhtBq4q4LRuYKthvYW3Oq50kcciMEBF1bpnP5Wh5d1hCDmvyQ+3G+u1Mnf009T3bHNtlZMzxZKdtGurbWpcBMpSQy+beXaXK911PJ6dGneh7m6KZmr5gbs3+ryOZZ4jGXRVTBuEIFSkC3VWCyqXvzF3VuthOI2fFMuvx6V1MTbaSXbasVv6jth6+8IVRmoHfTfvCnVDzvzpDuhNOwEg5lJo0X0WwCdsthA/mT3je8o6+gtZ7KoasPq2QXXjquwHUGd45eeQBn61fi5kDOcf9Pi8YB7OQ6E0bdAFosu2QFIpyOY4Feiq2GKctbWl5G6Eqa3sfcvj8epz/LlJe/m1iMZ9cDbVt5D8x9wFaKAK51U29ESnN7VanT6MvhhwVzgJrDTFfpiTQcYbdTW292bEScHI26EagahK7vYWdsyHO6b4Zb1HnMjVK/xNJqCtg8eB2haLSzi/dFcHnpejeTqnx+vrlf+z3F2VeknJJHsqJL0s4x+rfXNISEpdskzsbeSRBhC9SHozRzUJzws9eszSr6J+pYm3p1GE0R0qbcAh4LNvCU4FGzuLcKhYJmvDIdCLXyFOBRq6SvFYVCz2FeMQ6ESXzUOheqtBKFQvaWg16jOtXCWIrVDdpGkLM9yuhi0s3jot+Wmh7bcWearyKFSJveV5FCozFeTQ6EWWFEuvkgy8gF56KHKZaWvKocJOY99ZTkUKvHV5VCo3poQCjVByn3JRxWfT6z3HSw+eeorzaHGNvPV5lCoua84h0JlvuocCrX4GHmOZh8oz+Wlv9ZAU7c8x2JfeY5miCUJI6fJcyf10z8gzzHqL8+NXX6yPMcSL3nu9aj8b+Q5lvrJczR3jl92AmVyjDzHci957oB7zEueOwBSnCrPTZF+v/IcKz3lOco+qzxXxJ5SU3lUavq9e0tocqlzBcHPOqXTDecHRP5fjyUEAZt4a34o2NQ5RdZNM2yH1mQDrCzEtlYPkRz0bnDNm/n0OMCHurbZcDXNKEXy/HNh/5R5SUhO7acQ5lPAHubi9dBO3wLOS3dzTsjCwK5TgeFq2OkXs+s4+O3zVDDRwlrYlObVlKh1Z2ymE77dAd+NDxp2iXzC/Gpyua+XbDsO20ng7ARtwCEFzTy7d31aJ5iRWPo/a8snPutQGK/QfcM5IZSF5HtaLOHbllMJXMJ/uyJ4zJk1RGxmNnCi2gxtW0lVdbLamd4+MiiLfvrYURkX7Hb9+JJQ9EyoM6HOhPo4QmXp5yHUfnnl8SizM67ssvl9yWWAIpNHW262S0eT7O1E2YdyJu8nJm+enMl7Ju+ZvN8DeQ1TtWxuDXK31H/GVvt/Kyv7DoSZOJ+bYXu9UdK+jt1bkIUFdd9o3mXb5qxYNhd7PPPCabJIFxaL5sJ4fQ+7b+Ppl4SGNExYSK/CL0kSZmGShdnzMUvtcWba8/mYTce5OWb2mBmcYsRhCRyz6Tid7dnC3lwOWQk2V/aNj9Ee9/+7FwYwcv04kllOjXSapSyhcZI9Pf0N8uiuEw==

It uses Editor Extensions mod for infinite energy and chests.

When you place the blueprint the two trains go to the right station (Load) get some items and try to go to the bottom left station.
The top one can't go to the bottom station since it has no path and the bottom train can't go to the station since it the station has train limit of 0.
Since both stations on the right have a constant combinator with the yellow signal == 1 connected to it, an interrupt triggers that sends the trains to the top left station (Test-Overload).
So far so good.

1. Now remove the disconnected station from the top train (Test-No-Path).
2. The train stops retrieving the yellow signal and stays in the load station.
3. Now re-place/undo the deletion of the Test-No-Path station.
4. The train still doesn't receive the yellow signal.
5. Open the top train's menu and manually trigger the Test-load interrupt.
6. The train continues going back and forth between Test-Overload and Test-load again.

What is the expected behavior?
Both in step 2 and 4 I expect the yellow signal to be sent to the train and thus move back and forth between Test-load and Test-Overload.

[jurgy]

Do you still need a save file or is the blueprint enough?

[robot256]

Do you still need a save file or is the blueprint enough?

Please send the save file like Loewchen asked. It's the only way to ensure we are looking at the same thing you are. Blueprinting and pasting can introduce new bugs or hide glitches that appear only in your save file. They also communicate the fact that your setup uses the Editor Extensions mod, which I discovered when the blueprint didn't work. Also that blueprint appears to be missing one section of curved rail, and I don't know if it's an error in your blueprint or some other bug that caused it.

But actually we probably don't need it to guess what is happening. The schedules in your blueprint appears to be just interrupts and no stops in the regular schedule. This is not a supported configuration. As you discovered, when there is no stop in the main schedule that the train is guaranteed to depart, the times when it will evaluate the interrupt conditions are few and far between. You need at least one stop in the main schedule to be guaranteed regular evaluation of the interrupts. That is a limitation of the system as it is currently designed. You can try to make your interrupts so at least one temporary stop is in the schedule all the time, but that is at your own risk.

[jurgy]

The schedules in your blueprint appears to be just interrupts and no stops in the regular schedule. This is not a supported configuration.

It also happens when the station Test-No-Path is in the main schedule: I think the bug is that a train stops evaluating its interrupts when it's in a no-path state.

I've attached a save file that has the blueprint with this additional scenario.

Also that blueprint appears to be missing one section of curved rail, and I don't know if it's an error in your blueprint

That's intentional. The bug is caused by no a path state.

----

Repro is exactly the same as before:

The three trains go to the right station (Load) get some items and try to go to the bottom left station.
In all three scenario's the trains bottom stations have their limit set to 0. Additionally the top and middle scenario can't reach it since the station is
Since all stations on the right have a constant combinator with the yellow signal == 1 connected to it, an interrupt triggers that sends the trains to the top left station (Test-Overload).
So far so good.

1. Now remove the disconnected station from the top or middle train (Middle test: Test-No-Path. Top test: Test-No-Path-2). This can be done at any moment during the train's schedule.
2. The train stops retrieving the yellow signal and stays in the load station (bug).
3. Now re-place/undo the deletion of the Test-No-Path/Test-No-Path-2 station(s).
4. The train still doesn't receive the yellow signal (bug).
5. Open the top/middle train's menu and manually trigger the Test-load interrupt.
6. The train continues going back and forth between Test-Overload and Test-load again (correct).

Hope this helps.

Edit: I've played around with it some more and I think that the root cause is that whenever the train is in No Path mode it stops receiving signals from the train station it's at. The bottom scenario also breaks when you remove the most bottom left station (Test-Unload) and the top scenario also breaks when you set the train limit of the station Test-No-Path-2 to non-zero as well.

The reason I think this bug needs to be fixed is because train stations with the same name but in different train networks can break each other's trains:

11-30-2024, 13-44-49.png (776.31 KiB) Viewed 115 times

The train doesn't move since it's in No Path mode which prevents the yellow signal to be sent to the train. If I remove the top station and manually tell the train to go to the other station once, the train resumes as it should.

[robot256]

Thank you for the save file! That makes a lot more sense now.

I followed your instructions to remove the stop and got the same result. The train stays in the No path state and does not execute the Overload interrupt. If I remove the circuit condition, it executes the interrupt and correctly responds to the no-path state.

11-30-2024, 09-39-04.png (66.17 KiB) Viewed 105 times

I think I understand the root of the problem. In certain situations, the train "leaves" the stop even though its next destination does not exist or is unreachable. After it has "left", it has no access to the circuit network at the train stop even though it hasn't actually moved yet. It still evaluates the interrupt conditions every second when it is searching a path to become available. That is why the interrupt works with no circuit condition but not when the circuit condition is required. That also explains why it does not respond when the stop is rebuilt--it still has no access to the circuit network.

This is a side effect of the behavior reported in [2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path). The root cause is the same: that the train "leaves" the stop early even though it has nowhere to go.