[Coolhand101]

Csantucci, on 06 February 2020 - 09:56 AM, said:

OK, I have a first answer. This occurs in Explore Route mode. If you run in Activity mode, or in Explore in Activity mode, you get the pings at the light signals. I will now check why Explore Route does not work well.

Hi Carlo

I get the AWS sound warning and AWS TCS warning at green signals in all modes.( I actually tried activity mode first ). Could it be my older version of OR causing this problem?

Thanks

[darwins]

Alternatively is there something different in the signal script in the route that I chose?

[Coolhand101]

Well..... I tested the same trainset in MEP+ and the AWS Bell works. I was testing on EuropeanBahn commercial route London South Coast. The signal scripts are made by Tony Formoso, which also caters for the most of the commercial routes by Making Tracks. It would appear that green signals in that route are defined as Clear_1, the consist information HUD also confirms the cab aspect displaying Clear_1.
Could this be a problem with AWS with green lights on them routes.

Btw, tested the AWS advance warning speed reduction and this works 100%.

Thanks

[Csantucci]

That's good, Coolhand, things are beginning to roll. So, what should I do? Handle Clear_1 like Clear_2? Is it OK for all UK routes?

@ darwins, no, there was really a problem in Explore mode. I have now uploaded OR NewYear MG Rev 52.3 at the usual address as well as a new release of the mep_AWS_demo_pack_Rev3.zip on the usual post http://www.elvastowe...post__p__255510 .

@ Coolhand: If I have time, I prepare you a new release of the zipped simulation dll. P.S. It'll be tomorrow, sorry.

[Coolhand101]

Csantucci, on 06 February 2020 - 01:48 PM, said:

That's good, Coolhand, things are beginning to roll. So, what should I do? Handle Clear_1 like Clear_2? Is it OK for all UK routes?

I have to double check as I cannot remember the definition of Clear_1. However, if you look in the MEP+ signal scripts, Clear_1 is used for these signals:

"BR_E_2AspectSearchlightD" = A colour light distant
"BRSemHomeBranch" = Two semaphore stop signals for diverging routes - Main And Branch
"BRSemSide" = Semaphore Siding signal

I believe if the HomeBranch signal has one distant. Then the distant will show caution even if the branch signal off? It uses Clear_1 so this could be the case?

Member Roeter( Or anyone else) could confirm this correctly?

If Clear_1 cannot be change to address the AWS green light problem, then what I can do, is to change all the main signals to Clear_2 in signal scripts for routes that use it, and place the signal scripts in the Open Rails Route directory.

Csantucci, on 06 February 2020 - 01:48 PM, said:

@ Coolhand: If I have time, I prepare you a new release of the zipped simulation dll.

I appreciate your support for my old system :wink:

Thanks

[Coolhand101]

Hi Carlo.

Looking at some of my other commercial routes that use TF signal scripts, Clear_1 is only used. The only exception is the 4-aspect signal, which uses 'Clear_1' and 'Clear_2'. However, OR will show this signal as 'Clear_1'.

From the OR MSTS signal Aspect enumeration-

STOP	                Stop (absolute)
STOP_AND_PROCEED	Stop and proceed
RESTRICTING	        Restricting
APPROACH_1	        Final caution before 'stop' or 'stop and proceed'
APPROACH_2	        Advanced caution
APPROACH_3	        Least restrictive advanced caution
CLEAR_1	                Clear to next signal
CLEAR_2	                Clear to next signal (least restrictive)
UNKNOWN	                Signal aspect is unknown (possibly not yet defined)

The TF signals do have unique "approach control" scripts for diverging routes, and also for high speed diverging routes. I'm unsure if this is the reason for "Clear_1" on all their signals? However, even the semaphore home signals have "Clear_1".

Looking at some of my other UK routes, "Clear_1" is used for 'Normal' semaphore siding/shunt signals and the home/branch stop signal.

So judging from that data. An AWS warning will operate on 'Stop' and 'Clear' for "Clear_1" signals for the AWS script as it stands now. Is that correct?


But handling 'Clear_1' for 'Clear_2' would benefit any commercial routes with TF scripting plus 'normal' shunt/ground signals will have correct AWS as it stands now.

Trying to think of a correct way of the AWS script ignoring 'Normal' light/semaphore shunt signals? All of my 'normal' shunt/ground signals are RESTRICTING, with the exception of a Semaphore Siding signal, which has Clear_1.


Thanks

[darwins]

I would be tempted to think the other way.

Ignore if a signal has CLEAR_1 or CLEAR_2

Look for a caution aspect instead

Any signal that has APPROACH_1 or APPROACH_2 or APPROACH_3 should have AWS.

If a CLEAR aspect is given then you get a ping. If a CLEAR aspect is not given you get an alert.


That way home signals, either semaphore or colour light are ignored because they have only CLEAR and STOP aspects.

So long is the approach controlled signal has one of the above, which I believe they all do in real life, there should be no problem with it.

[Csantucci]

OK Darwin,
I'll proceed as you suggest, and will consider CLEAR_1 and CLEAR_2 as equivalent. If this will show some drawbacks in the future, a route-related parameter will be introduced to state how to cope with CLEAR_1.

[darwins]

Lets give it a try.
I am of course assuming the logical converse.
Any signal that does not have APPROACH_1 or APPROACH_2 or APPROACH_3 should be ignored.
The potential is looking good.
Just working on an eng file and realised there is an even more simple TCS - London Transport trip cock system. All that happens is that you get a full emergency brake application if you pass a STOP signal.

[Csantucci]

OK,
an updated demo pack (rev. 4 )is available here http://www.elvastowe...post__p__255510 , and OR NewYear MG Rev 52.4 can be downloaded from the usual link.