[RustyXL]

When I was testing a timetable for a Hungarian route I have, I noticed that trains seemed to be slowing down for no apparent reason. After some investigating I figured out that a certain type of signal that was used to restore the speed limit after switches with restricted speeds was causing the problem. Even though there's nothing ahead of an AI train, the "virtual" signals have a stop and proceed aspect until the AI train passes the signal immediately before it, after that they change to clear (see attached pictures). This causes AI trains to slow down unnecessarily.

Is there anything I could change in the sigcfg or sigscr files to keep this from happening, or would there need to be a change in the Open Rails code to fix this?

Attached thumbnail(s)

• 
• 

[eugenR]

MSTS and OR don't use SignalNumClearAhead ( 3 ) in the file sigcfg.dat in the same way:
MSTS use the highest valour he can find in the file for all signals.
OR use for every signal his individual valour.

So I think, in the first picture, the Signal where the train stand before has only
SignalNumClearAhead ( 2 )
So only this signal and the "virtual" signal will be cleared, the next signal will show stop,
so the "virtual" Signal has to show STOP_AND_PROCEED.
But in the Sigcfg.dat are other signals with SignalNumClearAhead ( 3 )

You can change for the first Signal:
SignalNumClearAhead ( 3 )

In OpenRails you can also transform this "virtual"-signals in a new type of Speedsignals,
so this virtual signals don't no longer work as real signals,
they only change the speedlimit to the limit of the last Speedplate.
http://www.elvastowe...__1#entry152479
show example 2:
SignalType ( "SpeedReset"

[disc]

How did you displayed those graphical signal and path debug informations?

BTW the problem exists even if all SignalNumClearAhead are set to 5

[eugenR]

disc, on 16 November 2014 - 03:55 AM, said:

How did you displayed those graphical signal and path debug informations?

Ctrl+Alt+F11

[roeter]

RustyXL, on 15 November 2014 - 11:34 PM, said:

Is there anything I could change in the sigcfg or sigscr files to keep this from happening, or would there need to be a change in the Open Rails code to fix this?

That question can only be answered if I know what's in the sigcfg and sigscr files.
So can you please provide more details - such as : which route, location, type of signal etc.
Uploading the OR logfile and the sigscr file would also help a lot.

Regards,
Rob Roeterdink

[disc]

roeter, on 16 November 2014 - 11:56 AM, said:

That question can only be answered if I know what's in the sigcfg and sigscr files.
So can you please provide more details - such as : which route, location, type of signal etc.
Uploading the OR logfile and the sigscr file would also help a lot.

Regards,
Rob Roeterdink

Here

First you need to download the main files either from google drive or simtreni

Then the patches below from google drive.

The problem (stop and proceed aspect of virtual signal) above happens at every station's switch area, if the next main signal is red. But does not in MSTS.

[RustyXL]

roeter, on 16 November 2014 - 11:56 AM, said:

That question can only be answered if I know what's in the sigcfg and sigscr files.
So can you please provide more details - such as : which route, location, type of signal etc.
Uploading the OR logfile and the sigscr file would also help a lot.

Regards,
Rob Roeterdink

The route I was using was actually Nova-tó but it has the same type of signal as the route disc linked to. The signals are used after every switch as far as I can tell in this route. The name of the signal is "0F_FELOLDO". I've attached the signal files for the route as well as the logfile.

Attached File(s)

•  OpenRailsLog.txt (12.7K)
  Number of downloads: 217
•  sigscr.zip (14.05K)
  Number of downloads: 208

[roeter]

Thanks for the files.
This signal does seem to be about 10 signals in one depending on the user flags which does not make it any easier to sort out what is happening, but these lines seem to show up for most options :

			else if ( next_sig_lr (SIGFN_NORMAL) ==# SIGASP_STOP_AND_PROCEED || next_sig_lr (SIGFN_NORMAL) ==# SIGASP_STOP)
			{
				state = SIGASP_STOP_AND_PROCEED;
			}

So, with the next signal at stop, this signal will be at SIGASP_STOP_AND_PROCEED.
And that is exactly what an AI train will do : stop, then proceed. That's what the aspect says it should do!
Well, it does not quite fully stop, but it does slow down to just about 5 kph or thereabouts.
Similar for RESTRICTING, by the way.

If this signal is not supposed to be showing any lights anyway, I suggest you use a less restrictive aspect.
I appreciate it would take a bit of work, but all aspects could be shifted one as CLEAR_2 is never used.

Regards,
Rob Roeterdink

[RustyXL]

well, with a combination of the above suggestions it seems like I've solved the problem. I changed the sigcfg entry of the "0F_FELOLDO" signal to have the OR_SPEEDRESET feature, changed all the signals with SignalNumClearAhead ( 2 ) to 5, and changed all of the states of "0F_FELOLDO" in the sigscr file to SIGASP_CLEAR_1. After doing all of those steps the AI train was able to travel the length of the route without slowing down for a signal. I haven't tried an activity or timetable with multiple trains to see if there are any negative effects though.

[disc]

RustyXL, on 17 November 2014 - 01:11 AM, said:

well, with a combination of the above suggestions it seems like I've solved the problem. I changed the sigcfg entry of the "0F_FELOLDO" signal to have the OR_SPEEDRESET feature, changed all the signals with SignalNumClearAhead ( 2 ) to 5, and changed all of the states of "0F_FELOLDO" in the sigscr file to SIGASP_CLEAR_1. After doing all of those steps the AI train was able to travel the length of the route without slowing down for a signal. I haven't tried an activity or timetable with multiple trains to see if there are any negative effects though.

I've tried this, but when a train follows another, and the followed train passes the link of this 0F_FELOLDO, the main signal behind that clears, and lets the following train enter to the same signal block. So the SIGASP_STOP should be left as is maybe just replacing restricting and stop and proceed aspects to clear could solve the problem.

BTW is it possible to disable signals in OR, so to make it use nodes instead of signals, for testing?