[0.15.9 & 10] Train stops at wrong signal (circuits)

[aaargha]

It seems that if a train encounters a red signal it will stop at a signal it has already allocated if that signal has been closed by circuitry.

In the below image (from the attached reproduction save) A is closed once C turns yellow. As A is already reserved the train should continue and stop at D, however once the train sees D it stops at A. If you remove D the train can reach the far right signal as expected. Rotate B to reset A for more tests. To see it in the save just set the train to auto.

regular.png (2.13 MiB) Viewed 7340 times

[chrisgbk]

Is it actually incorrect behaviour to stop at a signal that has been forcefully changed before the train enters the block, even if it's been reserved?

In my view, the train should be initially stopped at A in both cases, because a change in the condition of a signal should affect the train if it has not yet -entered- the reserved block. For example, if the player manually drives a train into a block that's been reserved but currently holds no train, the train will ignore the player, enter the block, and ram them, whereas if the train was stopped at the signal forcefully, it may be safer, such as in an intersection. This actually happens currently - the signal will turn to red, but the train will ignore it, because it takes it's reservation over the actual signal state. To me, the actual bug is that the trains reservation is prioritized over the actual state of the signal.

So, if signal A changes before it arrives, the train should drive to that signal, stop, and then give up it's reservation until the signal turns green again. So in this case, the train, in my opinion, should stop once at A, give up its reservation, allowing signal A to turn green again, and then it should continue on to D, because by the time signal A turns red by the train reserving the block controlled by C, the train has already passed A so can no longer be stopped by it. So it should end up stopping at D if it exists, or at the regular signal at the end of the line if D does not, after initially stopping at A.

[IV]

I agree with chrisgbk. However, I have one additional remark:
If a reserved signal is closed by circuit the train should stop there, if and only if it still has enough time to break before the signal.

This is why the behavior is probably correct in both cases:
- If D is present, then the train is already breaking to stop in front of D when it approaches A (and has reserved B) and thus has a low speed. Noticing that A is red, the train is slow enough to stop in front of A.
- If D is not present, then the train is going at full speed when it approaches A (and has reserved B). When the train notices that A is red, the train is to fast to stop in front of A.

So this may not be a bug.

[aaargha]

Is it actually incorrect behaviour to stop at a signal that has been forcefully changed before the train enters the block, even if it's been reserved?

AFAIK the block reservation distance is supposed to represent the train braking distance, hence the debug option name. It's a bit unclear, given the number of exceptions where the trains have a 0m braking distance, but I think that's the intention anyway. It also explains why the players train gets hit.

I agree with chrisgbk. However, I have one additional remark:
If a reserved signal is closed by circuit the train should stop there, if and only if it still has enough time to break before the signal.

This is why the behavior is probably correct in both cases:
- If D is present, then the train is already breaking to stop in front of D when it approaches A (and has reserved B) and thus has a low speed. Noticing that A is red, the train is slow enough to stop in front of A.
- If D is not present, then the train is going at full speed when it approaches A (and has reserved B). When the train notices that A is red, the train is to fast to stop in front of A.

So this may not be a bug.

This gets a bit problematic as braking distance is pretty arbitrary, as mentioned above. If we go by what the debug option called show-train-braking-distance gives, and how trains usually respond to circuit closed signals, then it is the same distance as where a train reserves a block, at least "normally".

[IV]

This gets a bit problematic as braking distance is pretty arbitrary, as mentioned above. If we go by what the debug option called show-train-braking-distance gives, and how trains usually respond to circuit closed signals, then it is the same distance as where a train reserves a block, at least "normally".

I agree that it is quite arbitrary. There are two (or maybe three) options:
- The 'reserved' condition overrides the closed condition set by the circuit.
- The closed condition overrides the 'reserved' condition and the train will start breaking when the signal closes. Whether it will be able to stop in time is not sure. If the train goes to fast it will pass the signal and accelerate again. (The train can also compute whether it can stop in time or not and not bother to break if it can not do so in time.)
(- The closed condition overrides the 'reserved' condition and the train will start breaking when the signal closes. The train stops suddenly at the light if it didn't have enough time to break. )

The last one seems unrealistic.

[chrisgbk]

This gets a bit problematic as braking distance is pretty arbitrary, as mentioned above. If we go by what the debug option called show-train-braking-distance gives, and how trains usually respond to circuit closed signals, then it is the same distance as where a train reserves a block, at least "normally".

I agree that it is quite arbitrary. There are two (or maybe three) options:
- The 'reserved' condition overrides the closed condition set by the circuit.
- The closed condition overrides the 'reserved' condition and the train will start breaking when the signal closes. Whether it will be able to stop in time is not sure. If the train goes to fast it will pass the signal and accelerate again. (The train can also compute whether it can stop in time or not and not bother to break if it can not do so in time.)
(- The closed condition overrides the 'reserved' condition and the train will start breaking when the signal closes. The train stops suddenly at the light if it didn't have enough time to break. )

The last one seems unrealistic.

I would argue that the train should make a "best effort" to brake fully, even if it will be unable to do so, because this condition is an abnormal condition - much like if a child runs out in front of the car, you don't go "oh well, can't stop in time, better just not brake at all". Even if a collision occurs, the speed may be low enough to prevent exploding everything. If the train does happen to enter the block because it was unable to brake fully, my suggestion would be to have it continue to brake until it stops, and then once stopped, attempt to find a path to it's destination again.

[Klonan]

I have this Gif of the current behavior:



However i don't see the problem with how this is acting.
The signal turns red before the train enters the block, so the train should stop at the signal.

[aaargha]

I have this Gif of the current behavior:

Gif

However i don't see the problem with how this is acting.
The signal turns red before the train enters the block, so the train should stop at the signal.

If that is the desired behaviour then I urge you to, please, test it again without the chain signal to see how trains usually handle circuit controlled signals.

Either behaviour would work (though IMO instant stopping seems a bit OP and inconsistent to how automatic trains handle player trains), but having both, and the trigger being another signal, just seems overly convoluted.

Anyway, thank you for your work and have a great day!

[Klonan]

I have this Gif of the current behavior:

Gif

However i don't see the problem with how this is acting.
The signal turns red before the train enters the block, so the train should stop at the signal.

If that is the desired behaviour then I urge you to, please, test it again without the chain signal to see how trains usually handle circuit controlled signals.

Either behaviour would work (though IMO instant stopping seems a bit OP and inconsistent to how automatic trains handle player trains), but having both, and the trigger being another signal, just seems overly convoluted.

Anyway, thank you for your work and have a great day!

This is what happens without the chain signal:



But i don't see how this behavior is incorrect either

[Loewchen]

Just to clarify, the confusing thing is, that the train-braking-distance point which seems to determine when the next block is considered reserved/occupied, is NOT the point the train would come to stop when applying full braking power at any point in time.

[aaargha]

To me it seems a bit weird that whether a train ignores a closed signal or not depends on if it sees another red signal further ahead or not. It also (I think?) makes it pretty much impossible to build a high performance merge, zip lock kind that avoids trains stopping.

Now that I think about it is probably actually another side effect of this old bug. The train goes along, ignores that the signals its already reserved gets closed when suddenly it encounters a red signal and is forced to recalculate its path. As changing the trains path seems to give it infinite braking force (who needs that research anyway?) and make it lose its block reservations it now suddenly both cares, and is able to stop at the first signal.

Sorry for not realizing that this was a duplicate sooner, but thank you for hearing me out.

Keep up the good work, and have a great day!

[Rseding91]

To me it seems a bit weird that whether a train ignores a closed signal or not depends on if it sees another red signal further ahead or not. It also (I think?) makes it pretty much impossible to build a high performance merge, zip lock kind that avoids trains stopping.

Trains never ignore closed signals unless they're already *past* them. Past being the front of the train has passed the signal. At that point the train doesn't care what the signal does because it doesn't change how it operates.

[aaargha]

Just to clarify, the confusing thing is, that the train-braking-distance point which seems to determine when the next block is considered reserved/occupied, is NOT the point the train would come to stop when applying full braking power at any point in time.

Sorry for missing this earlier, the confusing thing for me is that trains usually don't care if the circuit network closes a signal they've already reserved (braking distance), except, apparently, if there is a red signal further down the line.

Trains never ignore closed signals unless they're already *past* them. Past being the front of the train has passed the signal. At that point the train doesn't care what the signal does because it doesn't change how it operates.

I don't really know what else to call what happens in the second GIF Klonan posted, that seems to be exactly what usually happens once the block has been reserved. Once the combinator starts blinking the first signal is closed in both GIFs,

Attached a slightly modified save that shows the usual, signal ignoring, behaviour much better. It also shows the infinite braking force when adding the chain signal. The rail signals on top use the same circuit conditions as those on the bottom, the train can be found a bit further to the left.

Thank you guys for checking in on this, it's been very informative so far. Even if I don't really agree with the instant stopping behaviour I guess it can be exploited to make 100% safe rail crossings

Have a great day!