[Coolhand101]

Hi

I have a certain automatic signal(semi), that needs to display a proceed aspect when faced with trailing points(switches) that are set for the signal and a stop aspect when the points are set against the signal.

I have been informed that any automatic signals with no path set and facing any switches will automatically be set to stop, but I was wondering if there was a way around this by a certain signal script?

Can it be done?

Thanks

[Traindude]

Coolhand101, on 18 April 2023 - 09:04 AM, said:

Hi

I have a certain automatic signal(semi), that needs to display a proceed aspect when faced with trailing points(switches) that are set for the signal and a stop aspect when the points are set against the signal.

I have been informed that any automatic signals with no path set and facing any switches will automatically be set to stop, but I was wondering if there was a way around this by a certain signal script?

Can it be done?

Thanks

Not sure what you mean. This signaling tutorial (see "Departure Signals") should clarify things, but it was written with MSTS in mind. Hope that helps (to some degree).

[Laci1959]

Hello.

The problem is that the OR tries to cover the railway switch ( Pnt ) at all costs. At any cost! Even if the relevant setting is missing from the script. Permissive flags are never followed by a railway switch ( Pnt ), so it is not necessary to use BLOCK_JN_OBSTRUCTED in the flag script. Due to calculation errors in the MSTS, it was necessary to install a virtual railway switch (Pnt) in the track at station intervals longer than 10 kilometers. The program tries to cover this invisible, non-adjustable railway switch ( Pnt ) in a violent way. Even when you shouldn't.
This is just like when MSTS gave priority to the player's train at all costs. At least it can be avoided.
You can't do that, and that's the point. They forced something on the user. After that, what is the point of the signal script? There is no need because the program does what it wants. I look at it and get annoyed.

Sincerely, Laci1959

[Coolhand101]

Thanks for the replies.

Semi-Automatic signals are placed at key locations such like protecting emergency crossovers on a main line that is rarely used or trailing points from a ground frame. 90% of the time, these signals act like normal automatic signals which are controlled by the actual passage of trains.

I was hoping for a solution that if the trailing switch ahead is set against the signal, this signal will show a RED and when the trailing switch is set for the signal, the signal will display a proceed aspect if the block is clear and no path is set for the signal(automatic).



Thanks

[ebnertra000]

A trailing switch being open should drop a signal to red, since that will make the block_state BLOCK_JN_OBSTRUCTED. If a test in the sigscr for block_state() != BLOCK_CLEAR (is block anything other than clear?) is used, it should drop, but if the test is only for block_state() == BLOCK_OCCUPIED (is block occupied by a train?), switch states probably won't be picked up.

Admittedly, I haven't tested this on routes with 0° nodes (those weird dummy switch things from the MSTS days) since none of my routes have them. Also, I assume automatic signals still require the train to stop and stay? I hope so, or AI trains might pass it anyway

[Coolhand101]

ebnertra000, on 19 April 2023 - 04:48 AM, said:

Admittedly, I haven't tested this on routes with 0° nodes (those weird dummy switch things from the MSTS days) since none of my routes have them. Also, I assume automatic signals still require the train to stop and stay? I hope so, or AI trains might pass it anyway

So any node which is placed ahead from an automatic signal, will force that signal to red when no path is set?

Yes, most definitely these signals require ALL trains to stop and stay!

Thanks

[Coolhand101]

Rather than start a new subject, I've notice another new behavior with automatic signals and wait-points.

I'm unsure if this issue has been address with the latest OR versions.


I have a automatic signal that is protecting an automatic half barrier( AHB) level Crossing at a station. In reality, these signals are based on two different timers, one for trains stopping at the station and the other for non-stopping trains.

To simulate this, I have been using a wait-point of 7 seconds that holds the signal at red and keeps the crossing open until the train has stopped. Once the allotted time as past, the signal changes from Red to Green and the level crossing barriers are lowered. No waiting point is used on non stopping trains through this station!

Where I have been modifying my route using automatic signals where appropriate, I notice an odd behavior if an automatic signal is used for this level crossing instead of a controlled signal(!enabled).

When a wait-point is placed just before the automatic signal, the signal 'disappears' from the track monitor and behaves like a 'distance' type signal. The level crossing barriers still remain open. The signal remains green. There is no indication of this signal anywhere in-game or the extended HUDs, other than visually in game, but I do get a AWS bell 200 yards from the signal, like with all the other type of distance signals.

Here comes the interesting bit. As soon as the wait-point expires, the signal returns on the track monitor and the extended HUDs. If I replace the (!enabled) function in the script for this signal, this problem does not occur!

It's the first time I have probably used waiting points at an automatic signal, but I was wondering if any others have experience this. Looking through the latest OR manual, I did not find any reference for this odd behavior.

Just to point out that this wait-point is placed between the furthest platform marker and the signal! Also nothing in the OR log regarding any signal errors.

Thanks