[0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network conditio
Posted: Sat Jan 04, 2020 5:52 am
by SeaRyanC
What did you do?
Set up some entry/exit conditions with the intent that trains should go to a station that they are able to enter.
What happened?
Trains deadlocked when they didn't have to.
Here's the setup:
Setup-1.jpg (17.26 KiB) Viewed 5595 times
The green train sits at Station B. It wants to go to Station A; there are two of them (eastern and western).
Setup-2.jpg (307.51 KiB) Viewed 5595 times
The white train sits at Station A. It wants to go to Station B, which is occupied by the green train.
Setup-3.jpg (279.47 KiB) Viewed 5595 times
At the eastern station A, the Rail Signal has been set to Closed using a circuit network condition.
Currently, this is a deadlock. The green train and white train wait forever for each to leave their station.
This should not be a deadlock, because the green train has a legal place to go, and waiting for the white train to clear the area *will not allow it to go there anyway*
In fact, if we remove the white train, the green train *does proceed* to the western copy of Station A:
Setup-4.jpg (421.27 KiB) Viewed 5595 times
It seems like the pathfinding logic applies the "train waiting here" penalty *instead of* the much higher "closed by circuit condition" penalty. This doesn't really make sense, since the circuit condition is very likely not going to change based on a train leaving the guarded block.
What did you expect to happen instead? It might be obvious to you, but do it anyway!
The train should have pathed to the western station, since it's able to do this when there isn't a train behind the signal. In either case the signal is closed.
Re: [0.17.19] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Posted: Sat Jan 04, 2020 9:06 am
by boskid
Technicaly signal that you refer as closed by CN, is in state CLOSED because of white train and not reserved_by_the_circuit_network, so penalty for signal closed by CN does not apply. I could easily fix this so signals that are closed and at same time, scheduled to close by CN (but not yet reserved_by_the_circuit_network) to also apply this penalty but i am not sure how much it will break.
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Technicaly signal that you refer as closed by CN, is in state CLOSED because of white train and not reserved_by_the_circuit_network, so penalty for signal closed by CN does not apply. I could easily fix this so signals that are closed and at same time, scheduled to close by CN (but not yet reserved_by_the_circuit_network) to also apply this penalty but i am not sure how much it will break.
(a) I'd like that, it's always seemed unreasonable to me that a train in a rail block disables the circuit-controlled penalty, particularly because that's often the point, discouraging further pathing to/through a block.
When the path includes a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited.
(b) Shouldn't the train _eventually_ discover the other path? It looks 6m farther per second, 30m per 5s repath interval, right? So a few minutes tops here?
(c) I can't load the supplied map, and when I try to recreate it I don't get a deadlock, the train repaths properly. I have seen trains refuse to repath at chain signals, it happens, it's just hard to reproduce.
... hunh. I built it, the trains repathed. I took the blueprint, pasted it in here, built the blueprint, now both the blueprinted and the original are deadlocked.
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Posted: Sun Jan 05, 2020 1:20 am
by boskid
I made test case and fixed penalty so it will be applied when rail signal is scheduled to be reserved for circuit network. It felt counter intuitive that adding train (and so changing signal state to CLOSED) was decreasing total penalty.
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
I made test case and fixed penalty so it will be applied when rail signal is scheduled to be reserved for circuit network. It felt counter intuitive that adding train (and so changing signal state to CLOSED) was decreasing total penalty.
Do note that that bp I posted deadlocked without circuit closure.
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Issue was that train waiting at signal will repath periodicaly and during repath, amount of ticks train was waiting was cleared even if it was instantly back in waiting for signal.
Fixed for next release.
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Issue was that train waiting at signal will repath periodicaly and during repath, amount of ticks train was waiting was cleared even if it was instantly back in waiting for signal.
Fixed for next release.
Sigh. I'm actually getting weary of saying "you guys rock". Is there some less-boring way to phrase that?
Re: [0.17.79] Train incorrectly deadlocks in presence of occupied block guarded by signal closed by circuit network cond
Issue was that train waiting at signal will repath periodicaly and during repath, amount of ticks train was waiting was cleared even if it was instantly back in waiting for signal.
Fixed for next release.