[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: 277
•  sigscr.zip (14.05K)
  Number of downloads: 259

[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?

[roeter]

disc, on 17 November 2014 - 04:24 AM, said:

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.

That's correct - the STOP should not be changed.
If a NORMAL signal is used to reset speed, the signal before it should be set up thus that it checks not only the section up to the 0F_FELOLDO signal, but also the section beyond this, through the state of 0F_FELOLDO - so if 0F_FELOLDO is at STOP, so should be the signal before it.

If 0F_FELOLDO is indeed only used to reset speed, one option is to change its type to "SPEED". This will indeed reset the speed, but the signal will now no longer be a 'block' signal and the section will run between the preceeding and following NORMAL signals.
The 'state' of 0F_FELOLDO may now be used to set the required speed limit, linked through the definition in the sigcfg.dat file.

Quote

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

No, that's not possible. The signals are in the route's .tdb file and are therefor processed into the track circuit section data. As soon as a train finds a signal in its path, it will change to SIGNAL mode.

Regards,
Rob Roeterdink

[disc]

Changing the type to SPEED makes main signals stay red forever. As NORMAL, by replacing all STOP_AND_PROCEED and RESTRICTED to CLEAR_1 seems to work with AI, however running the same service as player interrupted by the usual random "System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary." exeption...

It seems in MSTS i need to savegame frequently because of memory errors, in OR i need to save because of System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary errors... Or i just need to forget the timetable mode.

[roeter]

If you change the 0F_FELOLDO to SPEED signals, you must change the script for the preceding NORMAL signals such that these no longer copy the STOP state of the next signal - in particular if multiple NORMAL signals are followed by 0F_FELOLDO signals this condition would indeed lock everything.

I still don't understand why you get that crash. I run in Timetable mode all the time, on a route which has both double and single track sections and even some alternative path definitions, and I never have a crash. And that timetable contains 1500 trains running over 24 hours, so it's not for lack of chance. Have you removed all alternative paths and tried what happens then?

Regards,
Rob Roeterdink

[disc]

Yes i did remove passing paths where that error constantly happens, however there is no other train to pass. (that what i wrote about in the other topic, the crash happens where only one train is, but the crash is triggered by including services in timetable that are never go there where the exeption happens. Without those services, the crashing train doesn't crash).
But this crash that happened just now, does not happened when the AI was driving just before i tried, so this is totally random, i've seen such several times. Probably if i try again it won't happen.
And as i can't remove the signals i can't find out what causing this, but probably the signals do as the probability of the crash at the most places depends on the signal setting (if no $hold or $forcehold is set, then the probabilty of crash is much higher).

[roeter]

We're drifting :) - but never mind.
It's not relevant whether there is another train to pass or not - the only thing which is relevant is if any train has defined an alternative path in that area.
Simplified, what happens is if an alternative path is available at a particular location, no path is allocated to the train at that location but that allocation is postponed until the train reaches that location. Then, the possible paths are checked and the most proper available path is allocated.
In your situation, the error occurs because the system thinks alternative paths are available and so no default path is allocated, but when the train gets to that location no paths are defined at all. I cannot find how this can happen. The problem in finding this error is, ofcourse, that the crash as such is not the actual error - the crash results from incorrect data. The error is how this data became corrupted, but how and when that does happen is still shrouded in mystery. That changing signal settings can influence the crash only deepens that mystery as there is no direct link between signal settings and the path allocation logic.
These signal settings can influence the timing, but this data is assumed to be stable and so should not be affected by timing aspects.

In all - I have no clue as to what goes wrong :wtf01: .

Regards,
Rob Roeterdink