[0.18.22] inconsistent chain signal behaviour

[disentius]

What I was doing:

Trying to keep a station clear on a single track railway. by using chain signals.

Expected result:

Chain signal in the red circle should be red

Actual result

The signal is blue, and the trains will go the the station, even if there is a train before.

I can work around it by "bridging"the station with two normal signals, but the behaviour seems inconsistent. It should be either green or red, and in case of green, there should be a block split at the station.

inconsistent chain signal behavior 3.png (1.15 MiB) Viewed 2674 times

[Loewchen]

30881

[disentius]

Thanks for finding that:)
However, I still consider it a bug/inconsistency. And not solved.

[5thHorseman]

The only inconsistency I can see is that I would not expect the regular signal you added in picture #3 to be red, as its block is empty.

In pic 2 the circled chain is blue because a train routing to the station in the picture can get to that station without going through any blocks ahead that are red, but can't go anywhere else. That to me is totally consistent with chain signal behavior.

I'll admit though that I almost never use 2-way rails and never ever try to do anything tricky with them so my expectations may be counter to the general opinion of those that use them regularly. It totally fits in with what I'd expect if all the signals on the south side of the track were missing. Except what I noted about pic 3.

[mmmPI]

The only inconsistency I can see is that I would not expect the regular signal you added in picture #3 to be red, as its block is empty.

file.png (1.21 MiB) Viewed 2600 times

The signal (d) is green, and i expected it to be, is that the one you meant ?

if you meant the chained signal under the regular signal (c) from what i see i expect it to turn blue if you put the station in the other direction , it would then behave like the circled signal in the previous situation but it make sense to have it red as it is otherwise.

I don't think the direction the locomotive are facing has any impact on the color the signals takes, as it would be the same colors if you were to only use a wagon.

I didn't expected such logic for coloring chain signal to be applied this way regarding to station but it's not enough to qualify for inconsistency in my eyes ( i mean if the signal turn blue if you switch the station ). it's just that instead of considering only a block as a valid destination, the coloring logic for chain signal also consider a station as a valid one. Thus coloring blue as if a station was what is usually considered an " open block " , while instead in the game code it is written a "valid destination "maybe contrary to popular belief ? ( including mine before reading the thread ) as it is almost always the case . And even while it is the only available destination it is still enough to be considered as 1 "open path".

i can't think of possible implications for the proposed changed, isn't this some kind of small-impact arbitrary decision on implementation ? one might say nit-picking , glad to learn something new anyway .

[boskid]

There is nothing interesting here. Rail chain signal is blue because there exists a path that ends at train stop and this is intended. As Loewchen said: 30881

This logic goes deep into how trains signal reservation works: if train tries to reserve rail chain signal, it is forced to also reserve next signals until it hits regular signal or end of list of signals on a current path. Second case is when there is goal train stop after a rail chain signal. It is possible to make this logic to fail on rail chain signal reservation when approaching end of list of signals on a current path, but this would mean trains would become stuck without proper adjustments to trains pathfinder: it would be required to now keep extra state if previous signal on a path was rail chain signal and if yes, skip check for a destination reached. This would mean trains would not be able to reach train stop when last signal would be rail chain signal - in some cases of a double entrance with regular signal and chain signal, it could happen that train would pass its goal train stop only to approach it from another path where there would be regular signal. Train stops that would be only after rail chain signal would be never accessible. Too much complication, not going to happen. Not a bug etc...

[mmmPI]

isn't this some kind of small-impact arbitrary decision on implementation ?

it would seem like i grossly under-estimated the impact of the change from the developer point of view, and it doesn't seem as arbitrary as before now.

the impact of the change for the players however does still appear like very small to me.

[disentius]

Thanks for the reactions everyone.
Something new learned, indeed.

[5thHorseman]

The only inconsistency I can see is that I would not expect the regular signal you added in picture #3 to be red, as its block is empty.

The signal (d) is green, and i expected it to be, is that the one you meant ?

It's the one I was referring to there but it's red, not green. I see you're doing something with wires so maybe that's why. I never set signals based on wires so don't know all the rules to that. If it had no wires, though, I'd expect it to be green. D looks like C, B, and F which are red. it does not look like A which is green.

if you meant the chained signal under the regular signal (c) from what i see i expect it to turn blue if you put the station in the other direction , it would then behave like the circled signal in the previous situation but it make sense to have it red as it is otherwise.

I agree. A train heading toward it has no station it can get to.

[disentius]

signal (d) is red. I use the signals to "bridge"the station.
The signal before the station (d) copies the state of the signal after the station (c).
- Circuit condition of (d): read signal.
- Circuit condition of (c): "close when green < 1"

To keep the track 2-way, i matched them with chain signals on the other side.
With no wires, (d) would indeed be green.

[coppercoil]

I still can't understand why chain signals perform a check for train stop. If pathfinding cannot find some route, this is railway design bug made by player, isn't it?
Moreover, a chain signal is placed for a reason, and its logic should not be overriden by any stop or whatever.
Or maybe I have too few two-sided railways

[boskid]

chain signals perform a check for a train stop so its reported state is consistent with how trains would behave. As the reservation code will pass when a last signal before train stop is chain signal, train will enter such chain signal section so signal cannot be set to red.

[mmmPI]

It's the one I was referring to there but it's red, not green. I see you're doing something with wires so maybe that's why. I never set signals based on wires so don't know all the rules to that. If it had no wires, though, I'd expect it to be green. D looks like C, B, and F which are red. it does not look like A which is green.

it is red indeed. yes D looks like the C B F that are red, i expected it to be green and saw it green i guess, not even realising the wires.

i have made this one where signals are either red or blue and i thought they would all be red

chained.png (2.52 MiB) Viewed 2499 times

[5thHorseman]

i have made this one where signals are either red or blue and i thought they would all be red

This was actually very hard to answer, though I know the answer. It's a lot more complicated than I originally thought but makes sense to me intuitively.

The big take away though is that stations are NOT signals (they are treated more like trains, but as a positive instead of a negative), and trains in a block make ANY signal leading to that block RED. A block with a station is always a positive (green) indicator, unless that block also has a train. Trains win over stations.

Chain 0 has 2 chains to check, a1 and a2. They are both blue, implying that they already know there is one good (i.e., to a green signal or free station) and one bad path (i.e., a train or red signal). So it's blue as well.
Chain a1 has 2 chains to check, b1 and b2 (unlabled but they match a1 and a2). b1 is red but b2 is blue, so a1 can be blue due to that.
Chain a2 has 1 chain and 1 station to check. The chain is red but the station is free (there is no train at it OR IN ITS BLOCK) so the a2 can be blue.
Chain f2 has 1 station, but that station is not free due to the train in its block.

g1 is a regular signal and is red due to the tain.
g2 and g3 are red due to ending at g1, a red signal.
g4 and g5 both immediately hit blocks with trains, so are red.
g6 has 2 paths, both go to red signals so is red.

h4 is blue because it could end in a station OR h3, which is red.
h6 is blue because it could end in h4, which is blue or h5, which is red.

k4.5 is blue because could end in a station OR k3, which is red.
k4 is blue because it ends in a blue chain signal.

[mmmPI]

The big take away though is that stations are NOT signals (they are treated more like trains, but as a positive instead of a negative), and trains in a block make ANY signal leading to that block RED. A block with a station is always a positive (green) indicator, unless that block also has a train. Trains win over stations.

That's one convoluted way to say it , from my perspective , i had in mind 2 rules with hierarchy.

1) trains can't enter occupied block
2) trains can't be prevented by a chain signal to reach a station that is their target. in this case it turns green or blue if another path after this chained signal is occupied by train.

This was actually very hard to answer, though I know the answer. It's a lot more complicated than I originally thought but makes sense to me intuitively.

That was my exercise to remember this logic , i made situations and tried to explained to myself why the signals were blue, i feel i can predict now which is satisfiying. Also i share your reasonning for all cases, it convinced me that the word "inconsistent" is not appropriate, but only thanks to knowing this more precise rule.

Next one will be using 2 way tracks and circuit control signal to spice things up

[boskid]

Now lets make it even worse: if train has a temporary train stop in schedule, it will be able to pass chain signals that are red, because chain signals are able to see only real train stops - temporary train stops have no entity, they are simply a pointer in a train saying to which rail it should go (by removing that rail, temporary train stop will get invalid).
Trains when following path are not interested in what colors are on the signals - they are only interested in 3 things: 1/ if block behind a signal is empty, occupied by itself or reserved for itself, 2/ if signal is not reserved for CN, 3/ if signal is regular or chain (in case of chain signal, it will be required to also try to reserve next block behind next signal).
It is possible to see this train signal reservation code in action in 81098 where by reaching waypoint by a braking distance, path is extended and this makes train unable to cross some chain signals since after extending path, it is unable to reserve all blocks up to a train stop or regular signal.
There is one rule that is quite hated by some people, that train is able to cross red signal if it leads to a block that is already reserved by given train - it makes long trains to crash into itself on tight roundabouts. Interesting part is that if train has already reserved block which is ahead of train but which is after chain signal, train will not be able to reserve such signal again if it is unable to reserve blocks with standard reservation rules (up to a regular signal or end of path)