[Coolhand101]

Hi

I have mentioned the particular details on another thread.

When a wait-point is used to hold an automatic(normal type) signal at red, the wait-point causes the signal to display a Green aspect instead of a Red. Also, the signal does not appear on the track monitor or the extended HUD. As soon as the wait-point time has elapsed, the signal re-appears on the track monitor and the extended HUD.

It appears, the wait-point is causing the signal to function like a temporary 'Distant' signal, then after the allotted wait-point time has passed, the signal reverts back to a 'Normal' type.


This may be a bug and could someone please check this on the latest OR versions!

Thanks

[Csantucci]

I've rerun my test activities and they work correctly. Signal is appearing on the track monitor and it displays a red aspect. Are you able to provide to me a sample activity showing the problem?

[Coolhand101]

Csantucci, on 03 May 2023 - 08:25 AM, said:

I've rerun my test activities and they work correctly. Signal is appearing on the track monitor and it displays a red aspect. Are you able to provide to me a sample activity showing the problem?

Hi Carlo.

Are you using an automatic signal ie Normal type without the '!enabled' function?

Controlled signals are not affected by this.

Any route that has automatic signals could have this behaviour!

Thanks

[Coolhand101]

Carlo

The only routes that I know of that uses some automatic signals is the UK Chiltern and Mideast plus(MEP) route. Not sure if you have these routes, maybe MEP+?

The script for these automatic signals -

MEP

Spoiler

SCRIPT UK3Lightauto

// RT 3 aspect auto signal

	extern float	block_state ();
	extern float	route_set ();
	extern float	next_sig_lr ();
	extern float	def_draw_state ();
	extern float	state;
	extern float	draw_state;
	extern float	enabled;
	float			next_state;

// If required, show the appropriate 'stop' indication.
	if ( // !enabled ||							// Not enabled/cleared to show natural state?
		block_state() !=# BLOCK_CLEAR ||		// Block ahead not clear?
		!route_set())	// Switch not set as per link?
	{
		state = SIGASP_STOP;
	}
// Signal head is enabled and the block ahead is clear - update based on state of
// next signal head.
	else
      {
		next_state = next_sig_lr (SIGFN_NORMAL);

		if (next_state ==# SIGASP_STOP ||
			next_state ==# SIGASP_STOP_AND_PROCEED ||
			next_state ==# SIGASP_RESTRICTING)
		{
			state = SIGASP_APPROACH_1;
		}
		else if (next_state ==# SIGASP_APPROACH_1)
		{
			state = SIGASP_CLEAR_2;
		}
		else //if (next_state ==# SIGASP_APPROACH_2 ||
			//	next_state ==# SIGASP_CLEAR_2)
		{
			state = SIGASP_CLEAR_2;
		}
	}

// Get draw state
	draw_state = def_draw_state (state);

Chiltern

Spoiler

SCRIPT LUL-NR3A

// LUL National Rail 3-light (Automatic)
// Red (stop) if block occupied.
// Else tests state of next signal: yellow if next is red, else green

	extern float	block_state ();
	extern float	next_sig_lr ();
	extern float	def_draw_state ();
	extern float	state;
	extern float	draw_state;
	float			next_state;

// If required, show the 'stop' indication.

	if (block_state() !=# BLOCK_CLEAR)	// Block occupied?
	{
		state = SIGASP_STOP; // Red
	}

// Block ahead is clear - update based on state of
// next signal head.

	else
	{
		next_state = next_sig_lr (SIGFN_NORMAL);

		if (next_state ==# SIGASP_STOP ||
		    next_state ==# SIGASP_RESTRICTING)
		{
			state = SIGASP_APPROACH_1; //  Yellow
		}
		else
		{
			state = SIGASP_CLEAR_2; // Green 
		}
	}

// Get draw state
	draw_state = def_draw_state (state);

However, you can test this on any basic colour light stop signal by using the forward slashes to comment out this function :

if ( // !enabled || 

This should make the stop signal act as an automatic, which clears the block automatically after a train has pass the next stop signal. If you can try a wait-point on this signal again and see if you get any different results!

Thanks

[Csantucci]

Coolhand,
I did a test by modifying the USA2 signals, but the WPs continue working. I have the MEP, so, if you can provide me a simple activity on that route, I can test it.

[Coolhand101]

Csantucci, on 04 May 2023 - 12:12 PM, said:

Coolhand,
I did a test by modifying the USA2 signals, but the WPs continue working. I have the MEP, so, if you can provide me a simple activity on that route, I can test it.

Hi Carlo

That is good news about the USA2 signals under automatic with Wait-points. I'm creating a test activity on MEP+ that uses these automatic signals. You can test this shortly.

Thanks

[Coolhand101]

Hi Carlo

I just ran my activity using a wait-point at a controlled and automatic signal.

1. Leave Sturton-Le Steeple closed station with signal showing one yellow.

2. Stop at the next controlled signal - Wait-point set at 20 seconds.

3. Stop at the next automatic signal - Wait-point set at 20 seconds.

On my version, the wait-point at the automatic signal had no affect on the signal. This signal was showing one yellow(approach_1) and was not appearing on the track monitor. As before, as soon as the wait-point time expired, the signal showed up on the track monitor and HUD.

If this does not happen for you, then this problem is fixed on the latest OR versions.

Thanks

Attached File(s)

•  Waitpoint Auto Test.zip (2.26K)
  Number of downloads: 55

[Csantucci]

Hi Coolhand,
first two notes (tests with ORNYMG 141.1):
1) My MEP geared DMUs opens it traction cut-off relay as soon as I raise throttle after having inserted the first gear; is there something that has to be adapted to OR in the .eng files for such geared DMUs?
2) Your path ends before the automatic signal, so the WP hasn't effect on it; so I moved the path end point farther (two-three signals farther). I run the activity, and everything works correctly, as you can see on following two pictures.

Train waiting for WP expiration before automatic signal:


Automatic signal clears after WP expiration:


This is my logfile (maybe you discover some difference with your options setting - Forced red at station stops?)
 OpenRailsLog.txt (15.99K)
Number of downloads: 57

This is my longer path file
 Waitpoint Auto Test.pat.txt (1.79K)
Number of downloads: 50

Latest official OR Testing release works well too here.

[Csantucci]

About the traction cut-off relay opening: stable OR 1.4 works correctly, while OR 1.5.1 does not: traction cut-off relay opens and the DMU doesn't move.
IMHO this seems a bug; if these trainsets worked under MSTS and up to OR 1.4, they should continue working, even if their original .eng files aren't (maybe) perfect.
However physics is not my specialty, so I won't investigate this further, and hope that someone more knowledgeable will do that.

[Coolhand101]

Carlo, I must apologize. In my haste, the activity I sent you was for my modified version of MEP+. In the original MEP+, there are only two signals. In my modified version, there are three signals. Thats why your results where completely different.

I will check to see if that signal on the original MEP+ is an automatic. I'm 99% certain it is not!.

Edit

The signals in that activity were not automatic. I found another automatic signal on the original MEP+. I'm testing the activity shortly and will send to you( or anyone ) again if the same error I experience does occur!

Thanks