[Gary54]

CSI Open Rails ... very good.

I've attached the activity files. As you'll see, it begins in Creeson, PA, with the player train sitting before a red over red at MO interlocking. The player train will be passed on track 2 by an AI train that will move from Track 2 to 1 up ahead in the interlocking plant.

The activity has a good number of loose consists, mostly in Altoona; I removed them as it should reduce clutter and make things easier. I kept the AI trains, which are mostly WB trains coming up the hill from Altoona.

I do use some SLI models; but, as you point out, all of this stuff can be switched out and/or modified to make things easier.

Many thanks for your help on this.

One other point - I have not encountered this sort of problem on other routes; however, I've only recently started to really delve into OR.

Gary

Attached File(s)

•  NS 50R test.zip (20.73K)
  Number of downloads: 205

[Gary54]

I had some time to try a few more experiments with the HSC route and its signaling. In general, the signaling works fine if you (or an AI train) are not diverging. This time, I decided to check the position light (Pennsy) signals at MG Tower on the route. I was in control of a single-engine train on Track 2 that was to move to Track 3 (moving to the right looking in the direction of travel; west) at MG interlocking. I received the correct indication in MSTS (red horizontal over yellow vertical; medium clear). However, in OR, the indication was that of a clear block (vertical yellow lights). In spite of this indication, the player train did make the move from Track 2 to Track 3 as prescribed by the path set in activity editor.

It appears, then, that OR (for some reason I am unable to fathom) is not linking the existence of the diverging path with the correct indication (though it works fine in MSTS). The same results occur when the player train is holding for an AI train that is set to change tracks within the MG interlocking limits onto the track the player is holding. In this case (as in the examples I described last week), the indication for the AI train basically describes a clear block straight ahead (i.e., no diverging move). However, once the AI train has made its move, the signals for the waiting player (facing a red) become progressively less restricted as the AI train moves farther away. So that works fine.

I hope that some solution to this problem can be arrived at. Running the Horseshoe Curve route on OR is the only way one can appreciate the route.

Gary

[rdamurphy]

The odd part about this is that the signals control the switches - not the other way around...

Robert

[edwardk]

Robert,

When running this route, did you happen to notice the Draw_State++ error? This is normal under MSTS since the script acts as an actual programming language and Draw_State is incremented by 1. Unfortunately this is not the case under OR so this means that Draw_State would have to be incremented by 1(manually) when it comes up to this.

Edward K.

[Gary54]

Would it be best top submit a bug report or is this a problem that goes beyond that classification?

[rdamurphy]

I just shot off an email to Rob with my diagnosis, basically, the issue comes from conflicting AI/Player train paths, and it doesn't appear to be a problem with the signal scripts. We should have a fix for it pretty quickly.

Robert

[Gary54]

Thanks very much, Robert.

Gary

[roeter]

Problem has been found - it is a flaw in the processing of the dist_multi_sig_mr function.
Patch is under construction.

Regards,

Rob Roeterdink

[Gary54]

Thanks very much for your help in resolving this.

Gary

[roeter]

Patch is committed in V1724.

Regards,

Rob Roeterdink