[kovarex] [0.17.66] Rail signal won't output to circuit network if closed by circuit before block becomes occupied

[farcast]

Now, I know that rail signals don't output to the circuit network if it's ONLY closed by a circuit condition, but that's not what I'm talking about here. If the block is occupied or reserved, it should still output to the circuit network.

Rail_signal_no_output.png (234.81 KiB) Viewed 7255 times

Steps to reproduce:

1. Place a straight section of rails.
2. Place a rail signal in the middle of the rail with Close signal and Read signal checked.
3. Close the rail signal with a circuit condition.
4. Place a train in front of the rail signal.
5. Read the output of the rail signal with an electric pole.

What I expect to happen:
The rail signal should output a 1 on Red once a train is placed in front of it.

What happens:
The rail signal won't output to the circuit network if the train was placed after the signal was closed by a circuit condition.

I just updated to 0.17.66 from 0.17.45, but I didn't see anything about this in the change logs, and the rail signal will still output if the train is placed before the circuit condition becomes true, so I think this is a bug.

[quale]

I think this is an intentional change, after all those requests for the ability to force signals closed. I just don’t agree with the way it was done. It isn’t coherent anyway.

Some of 0.17.66’s rules as I’ve inferred them:

1. A signal becomes circuit-closed if it’s green and there’s a close request. This is fine and familiar.
2. If the front of a train passes a signal with a close request, that signal transitions to circuit-closed.
3. Regular red remains regular red and still allows a train to make a new reservation, even if there is a close request.
4. Once a signal is circuit-closed, only relinquishing the close request can pull it out of that state. Occupancy can’t be read anymore as you’ve found. Some people seem to want this as a feature, but I don’t see much sense in it.
5. When a train’s braking point passes the next waypoint station, the train re-evaluates all signals along the way, allowing them to transition to circuit-closed. The train will defy physics and stop on a dime to obey. Wut. Block intrusions have a similar effect, but shouldn’t normally happen unlike close requests.

So signals are now stateful. You also still can’t exactly force a signal closed even way ahead of braking distance.

If you request a red signal to close, it will remain red. If the train occupying the block then wants to reserve the block again before it’s left the block, it will actually get it. That passage only then makes the signal circuit-closed to prevent another lap. If you have multiple signals re-entering the same block, setting each signal to circuit-closed on passing obviously won’t do anything for the others, so the train will just blast through everything.

I think a signal should use all information available to it: block occupancy/reservations and the close request, considered separately from each other. Block occupancy can always do its thing as though the close request doesn’t exist. The close request only exists as another condition preventing trains from making new reservations. Completely combinational and orthogonal, you can still read occupancy while holding a signal closed, and a close request will actually stop all trains ASAP without silly exceptions. If green-with-close-request outputs nothing to the circuit network—although I disagree with that—it’s just like the old behavior but with more commanding close requests.

[gabberworld]

there is another problem with that rail signal, at in some chance it not allow close signal at all,
in my case there was a 2 examples, one is when it just flick red yellow green, and another was when i want force red to yellow

[Optera]

If the rules quale posted are how signals operate that is very unintuitive indeed.

Circuit control should have priority.
- Green and red signals should switch to circuit closed the moment they get the control signal.
- Yellow signals should allow only the train currently reserving the block from entering before switching to circuit closed red.

That would be clear cut, without any weird exceptions and much more intuitive.

[farcast]

When a train’s braking point passes the next waypoint station, the train re-evaluates all signals along the way, allowing them to transition to circuit-closed. The train will defy physics and stop on a dime to obey. Wut.

I've done some testing, and that seems to happen whenever the train re-paths, not just when passing waypoints. I've made a separate bug report about that here.

The combination of these two behaviors, ignoring the train instant stopping issue, means that rail signals can stop outputting seemingly at any time. That makes me believe that one of these behaviors must be a bug, if not both.

[quale]

The combination of these two behaviors, ignoring the train instant stopping issue, means that rail signals can stop outputting seemingly at any time. That makes me believe that one of these behaviors must be a bug, if not both.

At the very least, it’s a misguided feature attempt. I just don’t see the sense in it. A common safe crossing design now fails if you request to close the signal while it’s yellow. As soon as the front of the train passes and the crossing becomes occupied, the crossing will think it’s clear again. Wonderful.

Really the only way to do it properly is to make circuit-closed replace green like it used to. By then you can lock it into that state to blind yourself to trains arriving by other means, but why would you? It’s strictly lost functionality. If your close request is on the wire, and red and yellow aren’t, you know the block is clear and no trains will pass that signal again until you relinquish the close request. You don’t need to blind yourself to confirm that. If a train does enter the block by other means, usually you actually want to know about that. Plus, where do you draw the line? If one train leaves the block and another immediately enters (through an open signal), how is that relevant to a signal just monitoring from elsewhere? Block was occupied and block is occupied. You can detect the change of train by reading its own yellow signal, and even know where it came from.

Like I said, if you want close requests to be more commanding, stopping trains already in the block trying to re-enter it, just make trains check the close request as a precondition for trying to reserve a new signal. If you want to blind yourself, why?

there is another problem with that rail signal, at in some chance it not allow close signal at all,
in my case there was a 2 examples, one is when it just flick red yellow green, and another was when i want force red to yellow

Flicker mode means the signal isn’t attached to a rail or connects two ends of the same block. I don’t think it needs to malfunction, but it also isn’t that important. Its presence usually indicates a mistake anyway.

If you want to force a yellow signal to become circuit-closed, you either want to defy physics, or you want to be blinded to the train whose momentum will carry it past the signal regardless. Do you understand the ramifications?

If the rules quale posted are how signals operate that is very unintuitive indeed.

Circuit control should have priority.
- Green and red signals should switch to circuit closed the moment they get the control signal.
- Yellow signals should allow only the train currently reserving the block from entering before switching to circuit closed red.

That would be clear cut, without any weird exceptions and much more intuitive.

Red shouldn’t switch to circuit-closed because you usually want to know about occupancy, e.g. to determine that a crossing is clear. You used to be able to make very basic and reliable crossings. Now you need to stick another signal that no train is intended to pass somewhere, or add combinator logic that avoids closing the signal unless it’s green. Oh, only close if it’s green. What else did that?

[quale]

While we’re discussing the merits of circuit-closing behavior here, I should add that I’m not sure if stopping trains re-entering the block (to the extent that this even happens in practice) is a good idea. You can at least make that work, but should you want it? There are two slightly different effects you may want to achieve by closing a signal:

1. Just stop that train. This would require trains to check the close condition regardless of occupancy.
2. Clear the block. Stopping the train would often prevent this and cause the contraption to deadlock.

Which of these would be more important? I’m inclined to think the latter because deadlock is such a harsh penalty. Signals and the circuitry controlling them are bound to blocks anyway, not any one volatile train. It’s what you observe through them and what you ought to control through them. Observing block occupancy, you aren’t affected by re-entering trains at all. In many cases you can’t even tell that it happened, so does it matter? Is there a good use case for desperately stopping a re-entering train?

A third way to be done with this matter is to disallow trains re-entering their own block unconditionally. Be consistent and deadlock all trains wishing to re-enter, but with the benefit that even the longest trains can’t hit themselves as long as loops are broken into multiple blocks. I’m sure that won’t go over well.

[reduke]

Glad to see that someone else has noticed this!

It happened with the 0.49 release. I posted about it twice, first time it was thought resolved with a different fix, and the second time it was assigned as not a bug .

viewtopic.php?f=7&t=72111
viewtopic.php?f=182&t=72479

[kovarex]

Hello, this is only related to manually pacing trains into blocks reserved by circuit network (as it would normally not enter).
So I changed the logic, that when you manually place a train into block reserved by circuit network, the signal will switch from state "RESERVED_BY_CIRCUIT_NETWORK" to "CLOSED"

I also added debug tooltip info that shows the signal state (OPEN, CLOSED, RESERVED, RESERVED_BY_CIRCUIT_NETWORK).

[Loewchen]

Hello, this is only related to manually pacing trains into blocks reserved by circuit network (as it would normally not enter).
So I changed the logic, that when you manually place a train into block reserved by circuit network, the signal will switch from state "RESERVED_BY_CIRCUIT_NETWORK" to "CLOSED"

I also added debug tooltip info that shows the signal state (OPEN, CLOSED, RESERVED, RESERVED_BY_CIRCUIT_NETWORK).

Trains can enter circuit closed blocks if the train is not able to stop anymore after the signal closes though.

[quyxkh]

Trains can enter circuit closed blocks if the train is not able to stop anymore after the signal closes though.

You'd think so, but it's not true. If the circuit manages to close the block, the train will stop. Run a pre-0.17-style waypoint that disables itself when its block's reserved, that forces the train to repath, and currently (I regard this as a bug) that means it completely releases all its reservations. If circuitry wants to close the block it had reserved and is about to enter, it'll stop before entering it. Get the distance right it'll happen in one tick.

0eNrtnE1v2lgYRv/KyGuIuK99v1jMfhbddTeKEAluaw2ByDjRRFX++2DA+aBOeY6m0mxm04oEDsaPH2Pfe3K/Fzfrh/q+bTZdMf9eNLfbza6Y//m92DVfN8t1/7Pu6b4u5kXT1XfFpNgs7/pH7bJZF8+Totms6r+LuXu+nhT1pmu6pj6+/vDgabF5uLup2/0TXl55+9A+1qvpATAp7re7/Wu2m/6Neo7tn/hUzKcu7uGrpq1vj78Nz5MfmPbC3HV73Ndv3YfUcKKm91QboZYy1aUTtXpPjSPU6oXaQzfTXbe9/9mGhrMNnRT7ZLp2u17c1N+Wj8227V9y27S3D0232P9u9cL50rS7bvFDfo9N2z0s168RHp8x/drW9aaPso++W/bHwax/cHe/bJdd/z7F74dfn96r3ixv1vVi1ez6/4t51z7Uk2JXb1aLbrs4fLpi/mW53u1/eni06D/rfb3SN+lz8Xzcns3x8+/617j+n7ZevT26mlW/t6/7Z+83/bgDik/tp+Vf9R9dMRKDFw9DV55ycJcPmKAfMGH8gClHqPFd1aanfTfGvPLDtl7591x/4ahZb3f1SyqnyIZftvXyNbE+Yz2Rqk9k5CMlbedPX04C+fI5IKs7f/q692eXM3UzwK0A1wGuAa4B7gxwS507S4BbAS7JzQMuyS0ALsktAi7JLcncTGLT65ZBaqa3LYPQTC9bBpmZ3rUMIjO9aglEZnrTEolML1oikek9SyQyvWaJRKa3LJLI9JZFEFmptyyCyEq9ZRFEVuotiyCyUm9ZAJGVessCiUxvWSCR6S0LJDK9ZYFEprfMk8j0lnkQWaW3zIPIKr1lHkRW6S3zILJKb1kFIqv0llUkMr1lFYlMb1lFItNbVpHI9JaVJDK9ZSWIzOstK0FkXm9ZCSLzestKEJnXW2YgMq+3zEhkesuMRKa3zEhkesuMRKa3zJHIwDAIiCyAURAQWQCDICCyAMZAQGQB3JcBKrhgBFTwTQaooGKAKjeMhCX3i2yp3C6wU6PcLZB/lJsFDtWoz7OApKI+zwKiinKtyAkryrUiZ9eoTxyQtORake+tqPeKpCUXi1wRJLlZ5PIlydUi11pJ7ha5MExyt8hVbJK7RS65k9wtcn+Q5G6Rm5kkd4vceSW5W+Q2MelfWiCtLHeL3IBnuVtktCDL3SJDG1nuFhmHyXK3yKBRlrtFRriy3C0yHJflbpGxwyx3iwx0ZrlbZFT2MMEnYtFUttwuMuJ9mObUsGR83s3kfpHZhMNkr4hFkckNiygyuWIRRSZ3LKHI5JIlFJncsoQMDLllZD7U6WYHmb11uthB5pqd7nWQmXGnax0ZRSa3LKPI5JYhR0J3OpjSoTsdTEHRpQ6mzOhWB1N8dK2DKUm618EUKgNGKVK+9LEOpKjpagdT6ixws1bi6n0zlFtSnWU/qiuWo1AwUj8MeoTLerF7I3f81BedWjX4oulcFw2jYL1tw8DH2fa6UazJMmg8UkuFWoqRlW6AjmIquHFnO7IahXq2becu7ygz4KMpKdgITd1zTXr8EIV9Utxrp1scw+GZhJZWapvKoU1udt4mI/L1UaIfda/PvOx/o/r3rvYl0V/XvF3lPhC93Rtb5cL+m/2a/ffr5PV99h9+Kv2cdfzzAVcKJ1jgygzfi84Uw7rCarzG9ViN17gBq/EaN2I1XuMmrMZr3IzVeIkLlJnhOl/jOqzGa1zDarzGLakar2ErqsZrWE/VeA0bqBqvYSNV4zVsomq8hs1UjZewwJpJIDJgzSQQGbBmEogMWDMRRAa0mUgi81SN17CBqvEaNlI1XsMmqsZr2EzVeAmr+zODGq9hHVXjNaxRNV7DllSN17AVVeM1rKdqvIYNVI3XsJGq8Ro2UTVew2aqxktY3aUZ1HgN66gar2GNqvEatqRqvIZ9bdl6u78N33bNYz1qml9VYZbL6F/Z27bZ405/8T67iqPDOLpaM7j32nYH6t5r2Ejdew2bqHuvYTN17yWs7tcM7r2GddS917BG3XsNW1L3XsNW1L3XsJ669xo2UPdew0bq3mvYRN17DZuhe69QbTaD7r1GddC916gG3XuNWjL3XoNWzL3XoJ659xo0MPdeg0bm3mvQBN17jZqhey9RdbEGnLBM92rA2dV0rQZ8FZhu1YDvLdOlGiNpeejea9QA3XuNGqF7r1ETdO81aobuvUTVXRpwyW26SQPuD0z3aMDdkukWDbi1M92hqUhaHrr3GjVA916jRujea9QE3XuNmqF7L1H1dVHAqJTp3gwYQjN9VRQw3mf6oihgcNL0NVECSctD916jBqjea9QIzXuNmqB4r1Ez9O4lqr4aCphXMX0xFDAJZPpaKGDGynS9A0yvmS53JJKWh8a9Rg1QuNeoEfr2GjVB3V6jZmjbS1Rd6ABmgOk6B9AYTJc5gHNhuspBDBHTVQ4itJiuchD/xnSVg+hC5iO17DVsopK9hs3UsZewuspBVDfTVQ5i5lkwKthr2JL69RpWl6zzkRoVqhfNU2fDwsmuPFdP3X+jnloIH6in9sYk+dn64VM33P6fOfjh//XDP97rnqwgbsC+eUnjh2Xnr/dvd/utXj2sT8vlv84A949dqt4847ge/8jWXfecw7r88zfL+E+K9fKm3u+n4nO/+35r+liGA+axbndHRb+cuRRDrmbp+fkfVTZsyw==

Copy blueprint

[quale]

Here’s a little crossing design to prove that things are quite broken. Each end of the crossing is entirely connected through a single circuit network. The northern and southern ends have a slightly different design.

I’ll explain the southern end first. The player gates output a green circuit signal when they detect the player. The rail signal in front of the crossing has green ≠ 0 as its close condition, so it will try to stop trains when there’s a player. That rail signal outputs a red circuit signal when its aspect is either red or yellow. That red circuit signal opens the train gates and closes the player gates. There’s another rail signal well before the crossing that outputs yellow when its aspect is red or yellow. That only affects the lamps, not the crossing mechanism. Lamp interpretation:

White = crossing is idle
Yellow = crossing is idle, but a train is coming
Red = train has reserved the crossing
Green = player has reserved the crossing

This design worked properly and was safe in 0.16. It doesn’t require the rail signal to force a train to stop when it’s really too late, because the train always owns the crossing. The way a player can cross is that they request the train to stop, and the train will stop if it hasn’t yet reserved the crossing. There is no race condition because the player is detected before they can actually run into/through a gate. You can space the auxiliary gates out to deal with higher exoskeleton/car speeds, and grow the window where a car is detected while stopped.

0.17 is now troublesome. If you walk up to the gates while the signal before the crossing is yellow (i.e. the lamps show red but the train isn’t on the crossing yet), but before the braking point has passed the waypoint station past the crossing, the train will relinquish its reservation and brake harder than it should be capable of to stop for you once its braking point hits the waypoint station. Weird, but it doesn’t break things. If instead the braking point doesn’t pass a waypoint station (in this setup, because the braking point has already passed the waypoint, or because you stopped the train and you leave and then re-enter the crossing immediately), the train will not stop for the close request, but the signal will switch to circuit-closed as soon as the train enters the crossing. That then opens the player gates, allowing them to run into the train. If the train was moving slowly, it will bump into the closing train gate at the other end.

The northern end has a slightly different design. It has a chain signal not connected to the circuit network in front of the crossing. The rail signal after the crossing is now the one that tries to close when a player is detected. A new signal placed in the other direction is used to detect trains. This should be a better design overall because trains shouldn’t stop on the crossing in case of congestion. It also works around 0.17’s circuit-closed blinding behavior by reading the block’s state through a different signal.

There’s still an issue, though. You can actually make the train stop in the middle of the crossing despite the chain signal. You can trigger it in this setup by bringing the train to a stop at the southern end. Then walk out to the south to allow the train to move again. When the train has actually entered the crossing (avoiding the yellow issue described earlier), run into the closed player gate. Note that the lamps at the northern end turn green as you do so. Stop attempting to walk through the gate so they turn white again. (What matters is that the gates don’t detect you, but they will as soon as you start moving toward them. This is just an easy way to achieve that.) Now wait for the northern lamps to turn red and the crossing to close, then walk north. As the train owns the crossing at that point, the gates won’t open for you. Then the train brakes insanely hard to stop for the circuit-controlled signal, in the middle of the crossing. The reason is that at this speed, its braking point passes the waypoint station while it’s on the crossing. That makes it relinquish the reservation even though it has entered the block through a chain signal of all things.

P.S. The crossing itself has a minor issue. If you block a train, but move out of the way before it’s stopped entirely, the train can hit the entrance gate before it’s had time to open. I don’t think that’s a bug in Factorio. You can fix it by moving the entrance signal farther away from the entrance gate.

Edit: Aside from this crossing, it’s also not just manually placed trains. Trains can enter blocks through different signals. If one signal is successfully circuit-closed, that doesn’t stop trains entering through other signals. This screenshot has lamps turning on when anything > 0, and the rail signal next to the combinator closing when C > 0 as provided by the combinator. I noticed another issue with the screenshot itself, but that definitely belongs in another report.

Screenshot

Not manually placed.png (1.66 MiB) Viewed 6753 times

[farcast]

My post was meant to be the simplest way to reproduce a more general problem, I'm sorry if I wasn't clear enough.

In .16, a rail signal will output a one on Red
IF:
-A train reserves a block through a different rail/chain signal.
OR
-A train is occupying the block.

In .17, a rail signal will output a one on Red
IF:
-A train reserves a block through a different rail/chain signal AND is not in the Circuit Closed state.
OR
-A train is occupying the block AND is not in the Circuit Closed state.

In .16, you can reliably observe the state of a block through a circuit-controlled rail signal.

In .17, you cannot reliably observe the state of a block through a circuit-controlled rail signal. If you want to reliably observe the state of a block, you MUST use a non-circuit-controlled rail signal.

This change in behavior was not documented (as far as I know), and the new behavior seems inconsistent, as once a rail signal's close condition becomes true, you can't be sure whether that rail signal will output a one on Red or not.

[quale]

Looks like this is indeed fixed in 0.17.67, even though I wasn’t sure if we got through all the way. The circuit-closed state is back to only overriding green as far as I’ve been able to determine. The close condition now applies separately from signal aspect per my original suggestion. Although I later questioned the very idea, at least it’s the right way to implement it. Repathing issues encountered while exploring the boundaries remain, but even the one most closely related to circuit-closed signals probably deserves its own report.

Thanks.

[reduke]

I can confirm this fixes the bug I posted.

Thanks - I think (this means by main game is no longer broken and I can go back to playing... just when I thought I'd nearly broken the addiction...)

[farcast]

Can also confirm, bug is fixed. Thanks!