When you select a priority signal, the window will tell you it is a priority signal. I cannot change the map icon though, that would be useful, it's the most annoying problem so far.

Originally posted by lollus:

When you select a priority signal, the window will tell you it is a priority signal. I cannot change the map icon though, that would be useful, it's the most annoying problem so far.

Ok that part isn't working for me then. The windows are the same for both types. Here's an example:
https://imgur.com/a/0bzX6rr

Whups I was still on yesterday's version. Updated and I have the priority label in the signal window now. Thanks!!

Hi, ok I tested more and I see that trains don't stop at signals, they stop instantly wherever they're at. I saw 2 cases where they stopped in the intersection. In 1 case it caused gridlock because the priority train was blocked.

I don't have a screenshot of the gridlock example, but here is an example where the train stopped in the middle of a crossover. It's not blocking the priority train, but there is a visual collision:
https://imgur.com/a/Mr4Kifv

How can I prevent this?

The game has no api to set the signals, so my solution is a bit crude. To avoid gridlocks, place the signal a bit farther from the intersection.

Originally posted by lollus:

The game has no api to set the signals, so my solution is a bit crude. To avoid gridlocks, place the signal a bit farther from the intersection.

In the screenshot the vanilla signal is already about 80 m before the intersection. The freight train was leaving the station on a slow uphill crawl. It was already past the signal and entering the intersection when the priority train triggered it to stop. So this wasn't a case where the train was moving fast and "inertia" caused it to stop in the middle of the intersection. Since the train was already way past the signal, shouldn't the priority train have stopped instead?

Possibly. Did you get a gridlock or just an unpleasant effect?

In this case just the visual collision you see in the screenshots. In the other case (where I don't have screenshots), it actually caused gridlock.

Regardless tho, see where the vanilla signal is?
https://imgur.com/a/VOlT5Ts
It's wayyy before the intersection (6 segments), and this was a slow moving train. So the loco was already well past the vanilla signal (by about 3-4 segments) and beginning to occupy the crossing and when priority stop was triggered. A stop shouldn't be triggered for trains already past their signals, correct?

Maybe the track geometry of the intersection had something to do with it? Maybe it's something the mod algorithm isn't expecting? Note the node types after the vanilla signal: green, blue (switch), blue (switch), green, green, white (the intersection). And the nodes after the priority signal: 6 green, then white (intersection).

Yes, correct.
The train on the left stopped much too far, it should have stopped with the loco near the signal, or gone through. I'll look into this.

Ok thanks! I'll try to reproduce it again too after I grab the latest update.

Uh oh, ok I have a new issue, with the latest update. (Posting it here instead of the bug thread because it's the same test map / intersection as above.)

The priority train is now stopping trains on the parallel track that aren't in conflict 😮 Example screenshots:
https://imgur.com/a/ZYS5V5P

You can see the priority train stopped the red train on parallel non-conflicting tracks. (It's the return traffic on the same line.) It was a sudden "insta-stop".

Meanwhile the conflicting blue train doesn't stop until the priority train is in the intersection (it seemed to do a normal slow stop instead of a hard insta-stop.). I like it, it's just the first time I saw this. The previous mod version always seemed to insta-stop everything.

The closeup shot of the geometry shows the nodes better. Note the white intersection node is not a double-slip switch. The red A line is never in conflict with the priority track and should be immune to stopping.

I guess if the algorithm "searches" track branches but does not know the line routes of each vehicle, then it makes sense this could happen. The algorithm wouldn't know that the red train isn't crossing over, only that the track geometry makes it possible, so it stops it. So for this to work well I guess the algorithm needs a way to know the line path of each vehicle so it can ignore non-conflicting ones. Otherwise this sort of thing could occur on any parallel tracks that have crossovers in the "priority zone". I mean I guess? 🤷‍♂️

Hope that helps

I checked the first issue and found nothing worth of note. Have you got "realistic train deceleration" or other mods that brake less?

Yes I'm using Realistic Train Brake mod (set to 1 for slower stops than vanilla). Good point, I can try testing without it to remove any possible confusion it might cause about the decel rate when stopping.

Maybe that would explain those 1 of those earlier cases where the train blocked the intersection. But I think it wouldn't explain the second one where the loco seemed to be wayyy past its signal when it got the stop order. It wasn't that it "coasted" into the intersection, but rather that it seemed to get the stop order when it shouldn't have because it was already past its signal.

Ok I present to you the nemesis track problem 😁 This specific blue node track switch causes non-conflicting trains on the parallel track to stop:
https://imgur.com/a/ctpBpW0
It doesn't matter whether the switch merges into the priority track or just crosses over it.

This last one is a bug, download the latest patch from https://github.com/lolluslollus/lollo_priority_signals_1 and see if it goes away.