Train Death Prompted circuit solution :) (Level Crossing Warning Lights)

[foamy]

@Opetra: I tested it. Your design fails in the case of a player being on the tracks when a train comes. It, in fact, traps them by raising the gates; there is no lock on the trains entering if the gates detect a player. I presume you didn't intend that.

Would be interesting how you tested.
I assume you either changed my design or stepped on the track while the gates where raised. Otherwise it's not possible to have trains and players on the crossing at the same time.

Have you tested the specific blueprint you uploaded? My test was quite simple: I placed some tracks, then dropped your print on top, then hooked the tracks into a loop and put a nuclear-fuelled locomotive through it.

As wired, you do not close the incoming signal when a player is in the crossing. Instead, it is set to close if the outgoing signal is also closed, as a sort of poor man's chain signal. I assume this is needed because of the tight spacing of the block signals (which is poor practice in general, and in any case there should be no need for an outbound signal anyway). The gates do provide an output, on channel G, but nothing in the circuit network does anything with it.

The gates are raised if a train is coming. But that's all they're doing. And because they have to be raised, which doesn't happen right away, you can actually manage to cross even with a train incoming as well. That's why my design -- and most other ones I've seen -- default to the crossing being closed.

[Optera]

As wired, you do not close the incoming signal when a player is in the crossing. Instead, it is set to close if the outgoing signal is also closed, as a sort of poor man's chain signal. I assume this is needed because of the tight spacing of the block signals (which is poor practice in general, and in any case there should be no need for an outbound signal anyway). The gates do provide an output, on channel G, but nothing in the circuit network does anything with it.

The gates are raised if a train is coming. But that's all they're doing. And because they have to be raised, which doesn't happen right away, you can actually manage to cross even with a train incoming as well. That's why my design -- and most other ones I've seen -- default to the crossing being closed.

The exit signals are optional in case the crossing is used in a chain signal block. Removing it changes only how entry signal and gates react to trains behind the crossing.

Just tested again, even with a train going almost 300kmph it was impossible to get run over.

2020-06-21 062831.png (565.4 KiB) Viewed 1868 times

But hey, perhaps I'm testing my design wrong, so here's a save as well:

_Testworld 0.18 - RR Crossing.zip

(1.03 MiB) Downloaded 113 times

[foamy]

Inasmuch as the only thing in your blueprint that provides signal to control entry into the crossing by trains is the exit signal, I don't know how you can say removing it changes nothing.


The test save you have is not using the print you uploaded; the one in the save has the gates outputting to Green, but the print you originally posted has it outputting to "G". When outputting to green the crossing does behave correctly in at least a cursory test.

Still don't like the gates being right next to the track like that, but it does work.

[Optera]

Thanks for telling me what settings you get for my bp, now I see what happened.
When I took the bp I had Dectorio installed, that messed up the signals. I thought the bug from blueprint signals being stored as index rather than signal name had been fixed.