[0.18.34] Greedy train signal indication logic makes invalid assumption or is bugged?

[Impatient]

train signal indicator behavior.png (250.17 KiB) Viewed 2106 times

The picture above shows two examples of a fork. In both examples the track turning to the vertical is locked in its directionality by one train signal at the end of it. In the lower example the horizontal track additionally has two signals at its left end, which make it bidirectional.

The unexpected behavior is, that in the upper example the train signal indication logic seems to greedily apply the directionality of the track turning vertical onto the right part of the horizontal track. But only onto the right part.

I would have expected the logic to either be non-greedy and make no assumptions about the directionality of any part of the horizontal track or, if it is greedy, assume that all parts of the horizontal track are unidirectional.

[Krazykrl]

I do not see anything wrong here. The train signal placement indicators go by a set of rules, and is just following logic in this case.

The vertical spur in both examples is explicitly signaled to have a one-way southbound train. Which means the horizontal line must be at least one-way westbound before the split.

Once you signal the horizontal tracks to be two-way, they behave as expected.

[Impatient]

Why isn't the whole horizontal in the upper example also treated as bidirectional?

[disentius]

I think because of this:

Signal placement.png (147.55 KiB) Viewed 1992 times

The undefined segment (straight) ends at the join with the curve

[Impatient]

Yes, the unidirectional track ends there. -> Why also assume, that the right side of the horizontal track, which leads up to that fork, is unidirectional? Does that mean, that all track, which is before the fork, is assumed to be unidirectional?

[Impatient]

While experimenting a bit further, I found this example of another obscure assumption:

train signal indication behavior.jpg (53.95 KiB) Viewed 1978 times

Here the track turning vertical is shown as possible bidirectional (despite its signal), while the left side of the horizontal track is shown to be possible only unidirectional. How so?

All the examples up until this post can be explained by, that the indication logic moves backwards from the signal and applies the possible directionality to all the track leading up to that signal. It also loops around and makes the track section, the signal is on, itself a possible bidirectional. And it makes the left horizontal track a possible unidirectional only.

To me that clearly is nonsensical. But maybe there is some ruleset, where to indicate signals, by which this is correct.

[kingarthur]

While experimenting a bit further, I found this example of another obscure assumption:


train signal indication behavior.jpg


Here the track turning vertical is shown as possible bidirectional (despite its signal), while the left side of the horizontal track is shown to be possible only unidirectional. How so?

All the examples up until this post can be explained by, that the indication logic moves backwards from the signal and applies the possible directionality to all the track leading up to that signal. It also loops around and makes the track section, the signal is on, itself a possible bidirectional. And it makes the left horizontal track a possible unidirectional only.

To me that clearly is nonsensical. But maybe there is some ruleset, where to indicate signals, by which this is correct.

its looping back on itself and that unidirectional set of track is making what amounts to an overly complicated left turn on the horizontal section.

[disentius]

Good question.
As long as the rail segment{block) is undefined -> no signals placed, the behaviour is like this. Lesson: do not place one signal only when you have a track with splits or joins:)