Train Signals Not Outputting?

[JakenVeina]

I feel like this is a bug, but I haven't worked with train signal circuit networks until yesterday, so...

Using RS to mean "Rail Signal" to avoid confusion with circuit signals.

I'm observing the following from RS's when both "Close Signal" and "Read Signal" modes are active, AND the "Close Signal" condition is met:

• The RS itself (visually) is always Red, as it should be
• When the RS would be Red without the "Close Signal" condition, it outputs 1x Red (or whatever signal is assigned)
• When the RS would be Green without the "Close Signal" condition, it outputs nothing.

In other words, I have RS's that are visually red, but (sometimes) not outputting a Red circuit signal, which just seems wrong to me.

I setup a small test world and attached it. Just plop down some trains on the tracks and you should see the circuit outputs change.

[Kelderek]

The RS outputs the default red = 1 signal if there is a train in that block. If there is no train in the block but the RS is visually red then that is due entirely to your circuit conditions. The RS will not output a red signal at all if there is no train in that block, it does not generate a red = 1 output just because a circuit told the RS to close.

I assume this is by design to ensure that you don't confuse the RS telling you if a train is present versus a circuit trying to force the RS to open or close.

[JakenVeina]

If that's the case, that seems like a bad design decision. The Circuit Network system is confusing enough already, without having embedded quirks that try to prevent user error. When the UI says "Read signal" as "Mode of operation" I expect it to read the state of the signal. If this behavior is going to be broken in certain edge cases, it should be edge-cases where the normal behavior can't be implemented (not the case here), the edge-case has no other work-around to achieve some other desired behavior (not the case here), or the edge-case behavior needs to be described somewhere.

Fundamentally, there's nothing wrong with having the rail signal just always output its visual state, regardless of whether it's being forced closed or not. It doesn't break the way the rail signal works, it just means that if you actually want to know whether the signal is being forced closed, you need to add another entity to read that circuit condition (which, by definition, already exists).

This feels more like an edge-case that they didn't consider or don't test for.

[Kelderek]

I expect it to read the state of the signal.

This is exactly what it does. The state of the RS is whether or not a train is in the block (red), about to enter the block (yellow), or empty (green). You have to remember the RS's job is to pay attention to trains, so when you read the RS this is what it tells you.

Fundamentally, there's nothing wrong with having the rail signal just always output its visual state, regardless of whether it's being forced closed or not. It doesn't break the way the rail signal works, it just means that if you actually want to know whether the signal is being forced closed, you need to add another entity to read that circuit condition (which, by definition, already exists)..

Using the circuit to force it to close is completely separate. When you read from the RS you are not seeing a circuit value passed through the RS. If it behaved the way you are asking for, then how would you know if a train was there or not? The circuit value (which matches the visual) would be overriding the RS value and that would indeed break the way that the RS works since you wouldn't know whether trains are present, you would only know virtual circuit condition. Consider that you might need to know both pieces of information, the circuit condition and the RS value and how they may differ could be relevant.

I'm guessing it was designed this way because you are in control of the circuit network conditions that would potentially close the RS, but you may need to rely on the RS telling you about the presence or absence of trains. Also, if you are creating that condition upon which the circuit closes the RS, then you shouldn't need to read that from the RS -- that's just an input output loop.

I feel your pain, these circuits are pretty rough to figure out, but I do think that the RS is working correctly and as intended and I wouldn't call it an edge case at all.

[aaargha]

I feel like Kelderek has done a good job of motivating the current behaviour, so I won't get in on that.

Though, I'm curious JakenVeina, did you have a a specific use case that the current behaviour broke or is this more a case of it not behaving like you expected?

[Avezo]

I thoughty it was a bug too and reported it, but apparently it's working as intended. See below:
viewtopic.php?f=23&t=43601

[BenSeidel]

I don't think it's an issue with the behaviour, but an issue with the wording as it implies that you are reading the signal state (that you are trying to set) but in fact you a reading whether or not there is a train in the block.

[JakenVeina]

This is exactly what it does. The state of the RS is whether or not a train is in the block (red), about to enter the block (yellow), or empty (green). You have to remember the RS's job is to pay attention to trains, so when you read the RS this is what it tells you.

If the "state" of the RS is whether or not there's a train present, then the UI needs to say that, not colors. And, more importantly, it the "state" of the RS is not affected by being forced closed, then the output signals need to reflect that, and shouldn't have the possibility of outputting nothing. I think both behaviors have merit, but it needs to be one or the other, not some weird combination of both.Or, hell, just add an extra output mode to the RS, "Read Train Presence".

I thoughty it was a bug too and reported it, but apparently it's working as intended. See below:
viewtopic.php?f=23&t=43601

Gotcha, thanks for the note.