[Gary54]

Good afternoon,

I've started to generate some rather simple activities to test signals. The attached screenshot illustrates an interesting situation. I had set this up so that the AI train on the left of us (track 2) would pass us, switching onto our track up ahead. We see red over red in front of us (track 1) - so we are stopped. The AI train, however, is facing a yellow over red aspect (approach). However, this train's route will take him around us a short distance up ahead (moving from track 2 to track 1), which is what happens. Eventually, we get permission to move expressed by an approach (yellow over red) aspect.

The problem is that the AI train should have been facing at least a red over yellow aspect advising him to be ready to switch from track 2 to track 1 up ahead. When running this in MSTS, the AI train actually received a red over flashing yellow aspect - diverging approach medium.

The confusing issue is not so much diverging approach medium versus diverging approach or even diverging clear. Rather, I would have liked to have seen any sort of aspect indicating that the AI train was about to make the move from track 2 to track 1.

Perhaps I have set something up wrong here; however, the AI train does what it should do when I run the activity.

Any thoughts on this would be appreciated. I understand that OR is in the development phase of signaling, but I thought I might bring this to the attention of the developers.

Gary

Attached thumbnail(s)

• 

[Lindsayts]

Just a point to consider although I am definitely no signalling expert...............

The signalling in MSTS is fairly simple, the program does not have direct control of the signal lignts. When the signalling is setup (via the signal script) a specfic number of signalling states are set apparently based on speed only. This means the light patterns will almost always be a compromise as a simple system has to try an simulate a more complex system. Signalling for switching appearing to be a problem as one cannot specify any special states. I notice a smiliar problem in Victorian routes, ie signalling protecting switching not showing the correct states. I did have a look through the config, there appears to be little one can do at this stage.

MSTS's signalling is in fact quite weak, it being it appears speed based using track circuits. There being no provision for a signalling system based on the use of "tokens" or "staffs" to indicate track occupancey.

Signalling is a very complex subject AND it differs widely from place to place even in the same country (Note 1) this makes simulating acurately it a major challenge.


Note 1: The systems in Victoria and New South Wales in Australia spring to mind, neihboring states in Aus, with two quite different systems, each state totally convinced they have the best system.

Lindsay

[Gary54]

Thanks very much for the response, Lindsay. I didn't want to give the impression that I was looking for a specific aspect that would be governing the AI move from Track 2 to Track 1 (the track the player train is stopped on). In fact, another AI train following the first one by five minutes received the same aspect (i.e., yellow over red). However, this train remained on track 2. Basically, my question has to do with not seeing the movement through the turnout up ahead expressed in the signal (the AI train did, in fact, make the move from 2 to 1 as planned by its path). Actually, this activity was based on personal experience; i.e., sitting at that same signal in as a high priority stack train (on Track 2 to our left) shifted onto our track (Track 1) through the interlocking plant up ahead moving ahead of us.

You are quite right regarding variations from place to place. Having worked on the Pittsburgh Sub during Conrail days, I had the opportunity to see a variety of signaling.

What I mean regarding the example that I gave is that I was hoping to see some indication (regardless of the details of the aspect) that the AI train would be switching tracks immediately up ahead.

Gary

Lindsayts, on 11 August 2013 - 01:24 PM, said:

Just a point to consider although I am definitely no signalling expert...............

The signalling in MSTS is fairly simple, the program does not have direct control of the signal lignts. When the signalling is setup (via the signal script) a specfic number of signalling states are set apparently based on speed only. This means the light patterns will almost always be a compromise as a simple system has to try an simulate a more complex system. Signalling for switching appearing to be a problem as one cannot specify any special states. I notice a smiliar problem in Victorian routes, ie signalling protecting switching not showing the correct states. I did have a look through the config, there appears to be little one can do at this stage.

MSTS's signalling is in fact quite weak, it being it appears speed based using track circuits. There being no provision for a signalling system based on the use of "tokens" or "staffs" to indicate track occupancey.

Signalling is a very complex subject AND it differs widely from place to place even in the same country (Note 1) this makes simulating acurately it a major challenge.


Note 1: The systems in Victoria and New South Wales in Australia spring to mind, neihboring states in Aus, with two quite different systems, each state totally convinced they have the best system.

Lindsay

[roeter]

As Lindsay allready indicated, what aspects are shown, and when, is not determined by the OR program as such but is defined in the route-related signals definition files sigcfg.dat and sigscr.dat.
The file sigcfg.dat defines which aspects can be shown, and sigscr.dat defines the logic on when a specific aspect is shown.
So, if you do not get the aspects you are expecting, it is these files which you have to look into.

The programs 'only' ensures that the rules as defined in sigscr.dat are correctly processed, and that the related aspect as defined in sigcfg.dat is shown.

Regards,

Rob Roeterdink

[Gary54]

I was afraid that it would, in some way, be related to the sigcfg.dat and sigscr.dat files. My thinking was that as the rather primitive MSTS signaling protocol gave the proper aspect, this would occur using the OR program.

I need to look into the sigcfg.dat and sigscr.dat files.

Thanks for the insight.

Gary

roeter, on 12 August 2013 - 12:27 AM, said:

As Lindsay allready indicated, what aspects are shown, and when, is not determined by the OR program as such but is defined in the route-related signals definition files sigcfg.dat and sigscr.dat.
The file sigcfg.dat defines which aspects can be shown, and sigscr.dat defines the logic on when a specific aspect is shown.
So, if you do not get the aspects you are expecting, it is these files which you have to look into.

The programs 'only' ensures that the rules as defined in sigscr.dat are correctly processed, and that the related aspect as defined in sigcfg.dat is shown.

Regards,

Rob Roeterdink

[rdamurphy]

MSTS signaling is NOT "speed based," although a speed based system can be written using the scripts. I'm not sure exactly what you mean by that, but signalling really is a simple system, even on the prototype. Regardless of where in the world a railway is located, you really only need to know two things: Is the next track occupied, or can I drive on it?

MSTS had some difficulties with some of the more complicated systems, yes, but most of those were overcome with programming. For instance, indications which require two heads to display (Approach Diverging, for instance).

I'm actually rather confused as to what aspect you want to see? A Diverging Approach Medium is actually correct: It tells the (AI) engineer to proceed, at Medium Speed, through the crossover, and that the next signal is Approach.

Your train is facing a STOP indication to protect the movement.

A Diverging Approach would indicate to the AI engineer to proceed through the turnout prepared to STOP at the next signal.

The signal isn't going to indicate R/Y versus Y/R until the switch is actually changed. In this case, it appears the path isn't set until the AI approaches the signal.

Robert

[Gary54]

The attached screenshot will hopefully straighten some of this out. I am (player train) facing the stop at the home signal for this interlocking plant (red over red); the moving AI train (on the left - the Conrail unit) is overtaking me and will proceed through the turnout onto my track immediately up ahead. Therefore, I would think that the aspect the AI engineer should see would be red over yellow (there is a slow moving train up ahead) - diverging approach. In fact, the AI train does proceed through the turnout onto my track yet you wouldn't know that based on the aspect. There is no other signal between this signal and the switch.

When I run the same activity in MSTS, the AI engineer sees a red over flashing yellow, diverging approach medium, and makes the move through the turnout.

In short, MSTS shows the correct aspect.

The V0.9 operations manual points out that the Sigcfg and Sigscr (.dat) files for MSTS routes are supported to the tune of 80% at the present time. Perhaps we are seeing that in this example(?).

Gary

Attached thumbnail(s)

• 

[rdamurphy]

Can you see the switch points up ahead? Are they lined for the diverging route?

Robert

[Gary54]

Yes – the points are lined up correctly for the diverging route.

I decided to try a few experiments. In the first case shown in the first screenshot, the player train on track 1 was to diverge to track 2 (on the immediate left). You can see a yellow over red aspect (approach), yet we diverged to the left on the turnout just ahead as planned by the path.

In the second case (the second screenshot), the player train in on track 2 and will diverge to the right onto track 1 up ahead. Again, you see a red over yellow. However, we made the move from track 2 to track 1.

I’m at a loss to explain this. I do know that the signaling for this route (Austin Yoder’s Horseshoe Curve) in MSTS is quite reliable. Perhaps this falls within the 20% of the MSTS signaling capabilities not yet supported by OR.

One point that I should add to this. I have noticed the following line of text as OR opens;

Extra tokens found at the end of block distance-levels

I have no idea what this means or if it has anything to do with the signal problem.

Thanks again for any help.

Gary

Attached thumbnail(s)

• 
• 

[rdamurphy]

I emailed Rob and he's assigned me to the case (CSI Openrails? LOL!). I have the Horseshoe Curve route, could you send me the activity files? Or just attach them here? I don't have any Streamlines locos to test them with, however, so I'll have to change them out for default items...

Also, have you tried doing this on any other routes? If not, I'll give that a try. As Rob indicated, it could be a parsing error.

Either way, it looks like something we need to get fixed, since the indications are obviously wrong.

Robert