Safe Rail Crossing

[Marconos]

Love the idea and your model of how you think they should work is spot on. In reality it should be pretty simple to implement (simple is relative to how complex other parts of the game are)

[Tallinu]

For all the critics: http://www.factorio.com/blog/post/fff-87

Look at the picture for the concrete paths. He already built a setup worth a working crossing.

The picture just shows gates surrounding a stone (not concrete) path crossing some tracks. The blog doesn't say anything about the gates functioning differently, and I don't see anything in the picture to suggest that would be the case. In other words, it appears to be purely aesthetic in this case.

It would be nice if there was a way to "occupy" a signal block with something other than a train, for instance, so that you could make a crossing that IS guaranteed not to kill you or destroy your car or tank even if you're careless. Will that be possible when 0.13 comes out? I understood maybe 3/4 of what I've read about the circuits, and really don't know what you're supposed to use them for. Something like a conditional where if the gate on either side of the path is open, the connected signal blocks are marked as occupied would be perfect and a lot simpler than all sorts of logic regarding when to open or stay closed.

[ssilk]

BTW: Rail yard speed limits is the counter-suggestion to this suggestion.

And before that we had this discussion: https://forums.factorio.com/forum/vie ... =67&t=7717

I can interpret the enclosed survey very clearly: This suggestion is not needed.

[mrnicosable]

It is possible to setup a safe rail crossing which will stop your trains when you approach the gate:

http://imgur.com/ETIWXap

SafeCrossing.png (1.27 MiB) Viewed 4479 times

[ssilk]

Hm. Does that mean I can move it to Implemented?

[Engimage]

Maybe it is a good iea to implement rail signals which will trigger red sign if a player approaches/steps on the rail segment as well as trains occupying that segment

[Vykromod]

Maybe it is a good iea to implement rail signals which will trigger red sign if a player approaches/steps on the rail segment as well as trains occupying that segment

That's basically what can be done with circuit networks, and it's literally what the picture mrnicosable posted shows.

I myself would rather build an opposite mechanism - one that doesn't stop trains, but instead closes gates when the train approaches. My only concern is that this mechanism may trap me on the rails between the gates if the train just happens to enter the crossing block while I'm on the crossing.

[atloomis]

I set gates to close at yellow, and the signal to go red when you're using the gate. That way if you get there before the signal is yellow, the train has time to stop and let you through, but if the train is too close, you can't enter.

[phi1010]

I didn't yet find a way to make a 100%-safe crossing, is there one I missed? Most of the other implementations (priorizing the player when there, and keeping the signals green otherwise, as well as not allowing deadlocks, aka stopping both player and train until someone backs off) fail on trains running over signals that were yellow before closing. I'd like to close the signal, and then ask the signal, whether the section before it is safe (would be green if not closed, as it already is, when a train is stopped directly before the signal), but closed signals apparently don't return a color signal.

I've tried my own implementation, assuming it is safe when i close a signal when it has been green before; but the circuit network is too slow, allowing a train to switch the signal to yellow after examining it, but before I am fast enough to close it and stop the train:

factrainsio.gif (1.73 MiB) Viewed 4402 times

(Don't try to connect the states of the different elements, the screenshot-gif software was too slow to actually capture consistent frames, causing green presignals before red signals and vice-versa.)

• ">": If "green" > 0, output "green" := 1 // if signal is green or gates are already open (signal is already red), it is safe to open the gates
• "*": output "O" (Open Gates, Close Signal) := "green" * "G" (Player near) // if it is safe to open the gates, and there is a player, open the gates
• "+": output "green" := "O" // rename signal to allow adding "O" from "*" and "green" from signal; might as well have been an explicit addition

It start's oscillating, apparently not being able to decide whether I or the train was there first.

Using two signals for determining the state didn't work for me in earlier attempts, it either fails at the moment where the first (examined) signal is yellow, but the second (closed) signal still green, causing the train to stop, with me keeping the gates closed although the train has stopped, or at the moment where the first (closed) signal was yellow), but the second (examined) one still green; causing me to open the gates for a short moment (until the examined signal turns yellow), although the train will run over the red signal. Is there any solution to get (or calculate) the closed signal state, or would that require a mod?

EDIT: I tried mrnicosable'atloomis's suggestion. It work's better than i expected; but I still have to test if the gates-closing-animation is short enough to prevent me from running into between both gates with 10 exoskeletons or a car. I think that latency might be to long, if the gates only start closing if it is already too late to stop the train.

EDIT2: 0.13 *almost* fixes this suggestion. With 10 exoskeletons one is still able to run on the tracks when it's to late for the train to stop. Took me about 20-30 attempts, but it is possible. Yay, I died.

One more try: when the signal is closed, it doesn't send green, it send's nothing. But when the signal is yellow or red due to a train passing (tested with pre-signal to allow working with slower trains), it sends red / yellow. That might be useful.

EDIT 3: Might have a foolproof solution; will anyone check for bugs?

2016-08-20 21_36_17-Factorio 0.13.17pdn.png (3.78 MiB) Viewed 4392 times

It might still be necessary to delay the "G" signal by one tick to make sure it doesn't arrive before the "red" signal if player and train are recognized in the same moment and cause the gate to open for 1/60 second; but I haven't been able to run in front of the train like this. (Maybe train movement and the player induced "G" signal are not computed in parallel.)

The gates (I was surprised when I the gate suddenly opened w/o the first comparator) are also interesting, one could make a tetris game...

2016-08-20 21_56_43-Factorio 0.13.17.png (153.14 KiB) Viewed 4392 times

[ssilk]

Hm. Not quite understanding the first gif.
Maybe this helps: A train needs some time to stop. There is a point before the train (when a signal goes yellow), where it reservates the next block and will not (cause he cannot) break anymore before this signal, even, if the signal goes red. You can turn on the display of this breaking-point in the debug-mode.

[phi1010]

Hm. Not quite understanding the first gif.
Maybe this helps: A train needs some time to stop. There is a point before the train (when a signal goes yellow), where it reservates the next block and will not (cause he cannot) break anymore before this signal, even, if the signal goes red.

The gif showed my first try to be faster than the signal; "remembering" whether that point has already passed in a kind of flipflop by remembering if the signal was green before I closed it (after that, it won't send green to the wire anymore), but that circuit is too slow and can start oscillating, if one triggers both conditions at the same moment (train passing critical point, and player being detected).

You can turn on the display of this breaking-point in the debug-mode.

That's cool, then I won't need pre-signals for testing anymore.

As far as I can tell, with a slight modification to atloomis's method also works, and without combinators: The signal turns to red, when there is a player; and the gates should only open when there is neither red/yellow/*green* (instead of just red/yellow); exploiting that bug-looking behavior of no output signal on safely closed signals.

[ssilk]

but that circuit is too slow and can start oscillating, if one triggers both conditions at the same moment (train passing critical point, and player being detected).

Circuits need always one tick for calculating. That is a game-limitation that cannot be changed.

Maybe you should look better into Show your Creations or Gameplay-Help. I'm nearly sure, there are existing solutions for safe rail crossings.