[Coolhand101]

Hi Carlo

Well the automatic signal turned out to be a "normal" type fix distant that shows up on the track monitor. However, it is behaving exactly like an automatic as the "!enabled" function is not included in the script file.

I just ran Route Riter to list the 3A and 4a automatic signals for original MEP+ - Even though their shapes and scripts/CFG are present, there NO automatic signals installed on the original MEP+!

You can still test this activity. BTW, I started further back so I can test the waiting points.



Default ~MEP-31-5544-Loco consist:-

1. Depart Swineshead station.

2. Stop at Heckington Station - Red signal - Waitpoint 20 seconds

3. Stop at fixed distant - approach_2 - Waitpoint 20 seconds

Before the waitpoint expires, the fixed distance does not show on the track monitor.
After the waitpoint expires, the fixed distance shows on the track monitor.

This does not fully prove the error, as I need to test an actual automatic signal.

Carlo, I have the USA2 route( unmodified), if you could create a test activity that worked for you before and I adjust the USA2 Signal for automatic operation? I can report back if this error does/does not occur ?

About the DMMU physics. I understand this is work in progress, however, I believe the DMMU ENG files need to be updated for the new functions that are now present in a certain latest OR version?. I'm, unsure which one?

Thanks

Attached File(s)

•  Waitpoint Auto Test.zip (2.14K)
  Number of downloads: 49

[Csantucci]

I could reproduce the problem with USA2. I'll try to solve it when I get time for it.

[Coolhand101]

Hi Carlo.

Thanks for the confirmation.

[Csantucci]

Coolhand,
can you please write here the name of the automatic signal of the mep route, so that I can find it in the signal files?

[Coolhand101]

Csantucci, on 07 May 2023 - 12:59 PM, said:

Coolhand,
can you please write here the name of the automatic signal of the mep route, so that I can find it in the signal files?

Hi Carlo

Although the route comes with automatic signals, there are none installed. There are two types:-

SignalType ( "UK3Lightauto" 
           Shape    rt3aspsiga.s

SignalType ( "UK4Lightauto"
           Shape    rt4aspsiga.s

These are 3 and 4 aspect signals. The signals are listed in the sigCFG and SCR!

I'm hoping other members can identify automatic signals in other routes.

Thanks

[Csantucci]

I've tested and believe I have understood the code logic.
The code logic doesn't handle the influence of a WP before an automatic signal, and I think that the main reason is that it is hard to understand why there should be a WP that should influence an automatic signal. in general an automatic signal goes to STOP only if the section after it is occupied by another train or if there is a switch thrown in the wrong direction after it. This is defined by its script. So a WP can't bring an automatic signal to stop.
This explains why the signal lights are not showing stop.
In non-automatic signals instead, STOP occurs also if the signal is not enabled by the train, and this is the condition generated by the WP.
Why isn't the automatic signal in front of the train not displayed in track monitor and extended HUD when there is a WP before it? For next signal to be displayed there, at least one of following conditions must be met:
1) signal is at STOP
2) signal is enabled.
Neither of these conditions occur in case of a WP before an automatic signal.

I'm not a signal expert, but how could it be possible in the real world to set an automatic signal to stop if the two conditions above don't occur? If this is something that the dispatcher can do, the same can be done with the OR dispatcher window. Or, instead of a WP, there could be an activity event generating a message requesting the player train to stop.

AI trains recognize the WP and stop for the required time interval, even if the signal is not at STOP.

[roeter]

In real life, there are automatic signals which can be held at stop automatic until after a specified delay, which is triggered by a train occupying a section ahead of the signal.
Here in the Netherlands, such signals are used where there is a level crossing just beyond a station. To avoid extensive delays to road traffic, the signal between the station and the level crossing is held at danger which allows the crossing to remain open during the station stop. When the train has arrived at the station, the delay (which is about the average station dwell time) is triggered, and when this has expired, the level crossing is closed and the signal clears. This is all automatic, without any intervention of the dispatcher or train staff.
On routes where there are both stopping trains and non-stopping trains, the dispatcher must select the appropriate setting when clearing the route. When non-stopping is selected, the signals clear as normal automatic signals, when stopping is selected, the signals are held as described above.
In timetable mode, the $hold setting could be used to simulate this, though sadly the level crossing will not work properly, that behaviour is in fact completely wrong.
In activity mode, $hold cannot be set for specific stations so I see no way how this could be worked properly for activity mode.

Regards,
Rob Roeterdink

[Coolhand101]

Hi Carlo and Rob.

Thanks for the testing and the logic behind all this.

In the UK, 90% of all colour light signals(1980/90s) were automatic. Most of the freeware UK MSTS routes did not feature automatic signals, however, the two commercial providers, Making Tracks and EuropeanBahn did!

Bit of a catch 22 now. I was planning to update my OR versions of Dorset Coast and Thames-Mersey with automatic signals where appropriate, even to the real fact of not placing an automatic signal behind a control signal if the 'overlap' was less than 200 yards to any points(switches). As DC and TM had no automatic signals, the wait-points in these routes activities may not work as intended, ie a proceed aspect other than stop.

I only came across this when I place an automatic signal that 'protects' an automatic half barrier level crossing at a station. I use no wait-points for a non stopping service, and a wait-point to hold the signal at danger, which also keeps the barriers raised, until the train comes to a stop, as Rob also stated.

It doesn't look like an easy solution but also as Carlo said, there is hardly a real reason to use a wait-point at automatic signal other than what has been mentioned.

I know in the UK, the signalman(dispatcher) also had the means to place an automatic signal to Red(stop)at stations. I'm unsure if is possible for OpenRails in the foreseeable, to detect an automatic signal at a station only and allow the proper use of a wait-point as described above. And if I remember correctly, some of the wait-points in activities to hold a signal at stop on Dorset Coast, that did not feature any points/switches/junctions ahead, were at stations.

Thanks