[2.0.10] Train stuck at disabled station

[nakatoio]

I've setup a number of train stops, "[flamethrower][oil][repair pack]". These train stations are configured with "Set Train Limit" circuit network condition.

If the stop needs items, the circuit network sets "L" to "1" to enable the station. When it gets all items it needs, it stops sending "L", disabling the station.


The train is configured with two station schedules, as follows.

1. "[flamethrower][oil][repair pack]"
* 5 seconds of inactivity
2. "[flamethrower][oil][repair pack]"
* 5 seconds of inactivity

It has 4 interrupts.
1. It has an interrupt to refuel the train if fuel is low.
2. It has an interrupt to go get more walls and repair packs if it is low
3. It has an interrupt to go get oil if it is low on oil.

1, 2, and 3 are currently not triggering as their conditions have not been met, as expected.

4. "Gunboat Idle"
Conditions:
* Destination full or no path
Targets:
* "Gunboat Idle" Station
* No wait condition


My train goes to a "[flamethrower][oil][repair pack]", and unloads. The station then gets set to 0.

This causes two issues.
1. There is no path to the next station, so it should return to the "Gunboat Idle" station, it does not.
2. When a "[flamethrower][oil][repair pack]" station becomes available, it stays at the currently disabled station.

The "Play"/"Stop" button does not change between the two stations.
The "5s of inactivity" conditions on both stations strobe green between the two stations.

10-24-2024, 10-37-22.png (669.81 KiB) Viewed 656 times

bug_report_train_stuck_at_station.zip

(12.74 MiB) Downloaded 16 times

Edits:
* Tested against 2.0.10, updated title

[evopwr]

I think this is similar to my problem,
viewtopic.php?f=18&t=117059&p=624076&hi ... pt#p624076

[panicky_hammer]

I'm seeing the same bug. The idea, based on my understanding of fff-395, is to create an event-driven schedule where one train will visit drop-off points, as stations in a group, until empty and refill at a station when empty.

To emulate the memory of which stations were visited, each station will disable when it no longer need the resource. This should force the interrupt, when it evaluates again, to target the next drop-off point in the group instead of just looping back to the same station or ping-ponging between two stops. When the station needs the resource again, it will re-enable and be included in the group of stations to target for the next evaluation of the interrupt.

The train will visit the first stop correctly. When the station disables and the wait condition becomes true, the train will re-evaluate the interrupt. But instead of targeting the next stop in the group, it will target the current disabled stop and start the wait process again, assuming it still has cargo to trigger the interrupt. I found this also happens if the stations are not setup to disable.

This seems like a very straight forward usage of interrupts and I'm surprised less people seem to see this issue.

[panicky_hammer]

I found a workaround in the mean time. The trick is to remove the current station from the target-pool. You can do this by utilizing the targets of the interrupt to include a "trigger" station that is immediately after the target station. This moves the train just a little bit out of the station before the interrupt is re-evaluated against the target pool that now no longer has the previous station in it. It works great.

[Loewchen]

118475