[Serana]

Here's the commit that I introduced for the check distance to correspond to the SNCA value of the first signal encountered by the train.
https://github.com/o...f82382576b6d7f3


This modification was introduced because, on high speed lines, the signals far away were not opening due to the lack of reservation of the route, provoking a slowdown of the train until 5 km before the signal.
In this commit, I unified all check distances to be the same (minCheckDistanceM replaced by CheckDistanceM).

I took another look at the log file.
In this case, it seems that the PresentPosition used to the signals to calculate the check distance is unusable during initialization (we are in the InitializeAPTrains function of Simulator class, in the PostInit function of AITrain class)
Here, it seams that, during initialization, PresentPosition[0 or 1].TCSectionindex is still equal to -1 (the train doesn't know where it is) in this phase and the calculation fails.

So I think Carlo's fix is enough to cover this initialization case.

[Klaus]

Hello!

Reading this thread I would ask, if the error I posted - perhaps in the wrong thread - ( http://www.elvastowe...71-and-earlier/ ) is also related to the changes discussed in the upper posts im MG Rel. 71?
Could You clarify this? I could not interpret the errormessages and have no idea to fix the problem.

Thanks Klaus

[Serana]

Hello,

On your side, it seems like it is an error when executing the signal script file (in the route_set).
I don't think it is linked to the topic' subject.

[gpz]

Serana, on 31 August 2020 - 03:59 PM, said:

So I think Carlo's fix is enough to cover this initialization case.

Primarily the code degradation described by Rob should be addressed, replacing that with a proper logic, in my opinion. If that would still not be enough, additionally Carlo's fix could also be applied.

Let us keep in mind, that none of us understand this part of the code satisfyingly, so if Rob says he sees an issue here, then there is an issue.

Rob, maybe you could suggest a proper fix for dissolving the 5 km limit triggered this problem?

[roeter]

The signal limit in Explorer mode is a known issue which has been around since the 'new' signalling code was created.
It was introduced because it was envisaged that explorer mode would only be used to, well, explore the route, hopping about, checking branches and sidings etc., and not to run trains as one would do in 'normal' mode.
Well, apparantly that assumption was wrong - my fault.
I can appreciate the need to change this in explorer mode, but the way this change has been implemented is completely wrong.
I had a look at the new code and I can only assume that it has been set up this way due to a complete misunderstanding of the use of the minCheckDistanceM constant.

So, first I will explain the use of this constant. It's intended use is only for signal initiation. The maximum distance defined in minCheckDistanceM is only intended to avoid a needless search along lengthy paths for signals which probably are not there, or are so far out as not to affect the train when it is started.
Actually, the signalling does not just use this constant, but it uses either this constant or a range depending on max. speed and time required to stop for a signal at danger, whatever distance is further. This choice was introduced to avoid problems with trains entering the sim at speed and not finding the first signal in time.
As soon as the first signal is found, the constant will not be used anymore in any way. From that moment on, the search for further signals in dictated by the signal logic.
A 'side' use for this variable is in the deadlock processing. A check is made for a common section if this section is protected by signals. Again, it's no use checking the full path, so again this variable is used to limit the search. It takes a lot of imagination to assume a signal at certain location is actually protecting a junction some 10 miles away. That's just not how signalling works in real life.

Then to explorer mode. This same constant was used - or abused, if you like - to set up the limits for the checks in explorer mode as explained above. But this certainly is not the main function of this constant.

So, if a change is needed in explorer mode to extend the search, the first thing to do is to drop the use of this constant. This use is not what this constant is intended for, so leave it to its intended function and set up another limit check for explorer.

What this change has introduced is that the search limit for the first signal is based on the location of the first signal. Even writing it down makes no sense.
It makes it all needlessly complicated, and its useless for, as stated, once a signal is found the constant is not used anymore.
So I would strongly suggest to revert this change and restore the constant for use in signal initiation and deadlock processing. It's clear, it's simple, and it has been working without any problems for many years.

That leaves the point of what to do with explorer mode. The method where this is all done is CheckExplorerPath, and that is where the changes should be made, and those changes need to be restricted to this method.
One option is to use the calculation as now introduced, but obviously for explorer mode only. But I would argue against that as it is needlessly complicated.
Another option is to determine the maximum scan range in a similar way as for signal initiation, that is either based on this constant, or on the product of max. speed and required reaction time. The reaction time of the TCS systems in known so this would be a quite simple and clear change.
The best option, however, is simply to remove the scan restriction alltogether. By removing the constant minCheckDistanceM from the call to ScanRoute and replacing it by the value -1, the scan is performed for the full (remaining) route of the train, which is similar as to its use in other modes. The only problem could be the bit of code following the scan, which extands or shrinks the scanned area based on the train's progress along its route. It would need to be tested what should be done with this bit of logic, but it's quite well possible it can be removed completely. Removing the scan limit will sort all problems and will make behaviour of the signalling in explorer mode much more like that in the normal modes.

So this is what I would suggest :

• Revert the changes which introduced the present problems, and restore the constant minCheckDistanceM for signal initiation and deadlock processing.
  
• Remove the scan limit from ScanRoute in CheckExplorerPath.
  
• Test what needs to be done with the logic which expands and shrinks the path in explorer mode, also in CheckExplorerPath.

This will keep the code clean and simple, restores the working of signal initiation and deadlock to what it was, and sorts the problems in explorer mode.
As bonus, behaviour of signalling in explorer mode will be more like that in normal mode.

Regards,
Rob Roeterdink

[Serana]

I understand a bit better. There was indeed a bit of misunderstanding. But then I am now confused about why it works with my code and not with the previous one.

Some comments:

roeter, on 01 September 2020 - 03:10 PM, said:

As soon as the first signal is found, the constant will not be used anymore in any way. From that moment on, the search for further signals in dictated by the signal logic.

This could have been explained in comments. I add a lot of trouble to understand the code.
And another thing that doesn't help is having a lot of classes in the same file. It makes it difficult to look at two locations at the same time. That is something I will probably try to change later.

roeter, on 01 September 2020 - 03:10 PM, said:

Actually, the signalling does not just use this constant, but it uses either this constant or a range depending on max. speed and time required to stop for a signal at danger, whatever distance is further.

In fact, the value used (2 minutes) wasn't enough. All european railway infrastructure managers consider that it takes 3 minutes to stop a train in case of a signal closure (we talked about that in a professional meeting with people from other infrastructure managers).
But even that value was not enough. In the routes, the signals are not always placed like in reality. On the French HSL, the spacing of the signals is 1500m or 2000m depending on the technology. It takes 7 block sections to go from 320 kph to 0, so the signal that must be opened is at about 12 to 15km from the train (there are some margins added for system response). For all of the routes I used for testing, the spacing used is 3 km (because the creator wanted to reduce his workload I suppose). So the signal to be opened is at 21 km from the train, a simple calculation is not enough.
That's why I used the SNCA value to calculate the distance.

roeter, on 01 September 2020 - 03:10 PM, said:

It takes a lot of imagination to assume a signal at certain location is actually protecting a junction some 10 miles away. That's just not how signalling works in real life.

And that's not what I think also. But you have to understand how other signalling systems works.
For the TVM system used on French, British, Belgian and Korean HSL: there is of course a signal (marker board) where the train has to stop before the junction. Before this signal, the speed is progressively reduced until stop on each block sections (320kph => 300 => 270 => 230 => 170 => 80 => stop for example).
So the block section after the marker board 12km away from the junction must be cleared at 320 kph (or said differently, a closed signal has an impact on the train 12km before).

roeter, on 01 September 2020 - 03:10 PM, said:

What this change has introduced is that the search limit for the first signal is based on the location of the first signal. Even writing it down makes no sense.

Then you have misunderstood what the new code did. It's not based on the location of the first signal but on how much signals must be cleared ahead of the first signal.

roeter, on 01 September 2020 - 03:10 PM, said:

It's clear, it's simple, and it has been working without any problems for many years.

It has never worked properly on high speed lines. Remember the bug report I did a lot of years ago... I recently had to do a lot of modifications on the TVM part of my TCS script and I was really annoyed when the signals were not clearing during the tests. That's why I tried to find a solution.

Alright, that being said, and as I said before, I am now confused why my code works (minus the crash problem) and not the previous one. Perhaps the route passed to requestClearSignalExplorer was not long enough?


Let's look at your proposal.

roeter, on 01 September 2020 - 03:10 PM, said:

That leaves the point of what to do with explorer mode. The method where this is all done is CheckExplorerPath, and that is where the changes should be made, and those changes need to be restricted to this method.
One option is to use the calculation as now introduced, but obviously for explorer mode only. But I would argue against that as it is needlessly complicated.

Seems alright to me.

roeter, on 01 September 2020 - 03:10 PM, said:

Another option is to determine the maximum scan range in a similar way as for signal initiation, that is either based on this constant, or on the product of max. speed and required reaction time. The reaction time of the TCS systems in known so this would be a quite simple and clear change.

It depends on the type of signalling system and how the signals were placed by the creator. I don't think that's the best solution.

roeter, on 01 September 2020 - 03:10 PM, said:

The best option, however, is simply to remove the scan restriction alltogether. By removing the constant minCheckDistanceM from the call to ScanRoute and replacing it by the value -1, the scan is performed for the full (remaining) route of the train, which is similar as to its use in other modes. The only problem could be the bit of code following the scan, which extands or shrinks the scanned area based on the train's progress along its route. It would need to be tested what should be done with this bit of logic, but it's quite well possible it can be removed completely. Removing the scan limit will sort all problems and will make behaviour of the signalling in explorer mode much more like that in the normal modes.

So this is what I would suggest :

• Revert the changes which introduced the present problems, and restore the constant minCheckDistanceM for signal initiation and deadlock processing.
• Remove the scan limit from ScanRoute in CheckExplorerPath.
• Test what needs to be done with the logic which expands and shrinks the path in explorer mode, also in CheckExplorerPath.

Indeed, this solution seems the best.
I send a new PR today or tomorrow with the revert and this new proposal.

Thank you.

[roeter]

Serana, on 01 September 2020 - 07:30 PM, said:

I understand a bit better. There was indeed a bit of misunderstanding. But then I am now confused about why it works with my code and not with the previous one.

I assume you are talking about explorer mode. It's no surprise that the new code made a change to explorer mode as you effectively lifted the scan limit.

Quote

And another thing that doesn't help is having a lot of classes in the same file. It makes it difficult to look at two locations at the same time. That is something I will probably try to change later.

Train.cs is a mess, it always has been. Not only does it have many classes, class Train itself is an hopeless garbage bin of all sorts of calculations which have no relation to eachother whatsoever. The whole thing needs to be split up into at least 20 or 30 different classes and files.
But ... this is a hopeless task. It would be an immense amount of work, taking probably a year or so to complete. In that sense it is comparible to the creation of the new signalling which also took about a year. But the signalling could be develloped in isolation as it was completely new and had no reference to the old code, so any changes made to that code were of no relevance. But that can't be done for Train.cs. So, either there must be a blanket ban on any changes to Train.cs during the rewrite - which I don't see happening - or during the rebuild one must try to keep up with all changes. That would make the task twice as hard and it will therefor take twice as long.
And allthough everbody has known about this for years, nobody has ever had the courage to start on this.

As for trying to find out where or how a variable is used, I always use "find all references". Sometimes you get hundreds of 'hits', which makes it a bit of a challenge. For this variable, though, there were only 18 references, 7 of which are in CheckExplorerPath. That's not bad at all.

About the additional check on first signal using max.speed and reaction time :

Quote

In fact, the value used (2 minutes) wasn't enough. All european railway infrastructure managers consider that it takes 3 minutes to stop a train in case of a signal closure (we talked about that in a professional meeting with people from other infrastructure managers).

No point in adapting that value. But, if the signal spacing is 1500 to 2000m as you state below, this value would not have any effect as the first signal would always be in the standard 5km check, and so the signalling would always be activated immediately. The additional check is mainly for routes with 'sparse' signalling like some US routes.

Quote

But even that value was not enough. In the routes, the signals are not always placed like in reality. On the French HSL, the spacing of the signals is 1500m or 2000m depending on the technology. It takes 7 block sections to go from 320 kph to 0, so the signal that must be opened is at about 12 to 15km from the train (there are some margins added for system response). For all of the routes I used for testing, the spacing used is 3 km (because the creator wanted to reduce his workload I suppose). So the signal to be opened is at 21 km from the train, a simple calculation is not enough.
That's why I used the SNCA value to calculate the distance.

The value is only used to locate the first signal, it is not used to clear signals further ahead. That task is left to the signalling. Again, you are confused between how signalling works, and the restrictions in explorer mode due to the scan limit. All problems you encountered are due to this scan limit, and not to the use of this constant or the working of the signalling.

About the check for first signal in deadlock mode :

Quote

And that's not what I think also. But you have to understand how other signalling systems works.
For the TVM system used on French, British, Belgian and Korean HSL: there is of course a signal (marker board) where the train has to stop before the junction. Before this signal, the speed is progressively reduced until stop on each block sections (320kph => 300 => 270 => 230 => 170 => 80 => stop for example).
So the block section after the marker board 12km away from the junction must be cleared at 320 kph (or said differently, a closed signal has an impact on the train 12km before).

That's not what the deadlock processing is looking for. The only interest is if there is a signal protecting that junction. As you say yourself, there is a signal close to that junction. That's all deadlock needs to know. To ensure that the signal is cleared early enough, such that signals ahead of it are also cleared, is the task of the signalling and has nothing to do with deadlock processing.

Quote

It has never worked properly on high speed lines. Remember the bug report I did a lot of years ago... I recently had to do a lot of modifications on the TVM part of my TCS script and I was really annoyed when the signals were not clearing during the tests. That's why I tried to find a solution.

Explorer mode again. Have you ever tried how things worked out in activity or timetable mode?
In my view, such tests should be done in activity or timetable mode as in those modes the signalling works fully according to the definitions in the signal script. Apart from the limitations, there are other exceptions to the signalling in explorer mode. For example, in explorer mode signals will clear to paths which normally would be blocked by signal links, just in order to allow the player to go everywhere as one might expect a player would whish to do in explorer mode.
But it makes this mode unsuitable for proper signal testing.

Quote

Alright, that being said, and as I said before, I am now confused why my code works (minus the crash problem) and not the previous one. Perhaps the route passed to requestClearSignalExplorer was not long enough?

Right on the spot. There is a reference to this variable in requestClearSignalExplorer which could well be the source of much of the trouble, perhaps even more so than the scan limit for ScanRoute in CheckExplorerPath. This limitation in requestClearSignalExplorer would definitely have to be removed.

Anyway, thanks for reverting this change (and with that, also Carlo's patch).

As for signalling problems - please don't hesitate to ask for help or advice. The present signalling has enormous potential beyond what MSTS could offer. And if required, I'm always willing to add the odd additional signal function, as I have done recently for additional callon functions.
For instance, you may not be aware that SNCA no longer is just a constant defined for all signals in the signals config file. The SNCA value can be adapted per individual signal, regardless of its value as defined in the config file. This can be done not only through additional signal parameters, but also actively using signal script functions.
For signalling along high speed lines, I would set SNCA for all intermediate signals (i.e. block signals not protecting a junction) to -1. This means that, by definition, the 'clear' request will be propagated to all signals upto the next signal protecting a junction. This would only leave the signal furthest out from the junction which would be the first signal encountered by a train where there would be a restriction if the junction signal is not cleared. That is the only signal for which a specific SNCA value must be set to clear the junction signal in time. The SNCA value for that signal could be set as fixed value, based on the number of signals between it and the junction signal, or perhaps it could be made adaptive, by checking the state of the junction signal or the last signal ahead of it.

Regards,
Rob Roeterdink

[Serana]

roeter, on 02 September 2020 - 02:07 AM, said:

Explorer mode again. Have you ever tried how things worked out in activity or timetable mode?
In my view, such tests should be done in activity or timetable mode as in those modes the signalling works fully according to the definitions in the signal script. Apart from the limitations, there are other exceptions to the signalling in explorer mode. For example, in explorer mode signals will clear to paths which normally would be blocked by signal links, just in order to allow the player to go everywhere as one might expect a player would whish to do in explorer mode.
But it makes this mode unsuitable for proper signal testing.

I mostly use explorer and a bit of timetable too, but not usually on HSL.
Explorer mode is the mode mostly used in multiplayer so this is something that has to work properly.

roeter, on 02 September 2020 - 02:07 AM, said:

For signalling along high speed lines, I would set SNCA for all intermediate signals (i.e. block signals not protecting a junction) to -1. This means that, by definition, the 'clear' request will be propagated to all signals upto the next signal protecting a junction. This would only leave the signal furthest out from the junction which would be the first signal encountered by a train where there would be a restriction if the junction signal is not cleared. That is the only signal for which a specific SNCA value must be set to clear the junction signal in time. The SNCA value for that signal could be set as fixed value, based on the number of signals between it and the junction signal, or perhaps it could be made adaptive, by checking the state of the junction signal or the last signal ahead of it.

I will try this on my side and tell the French creators about this.
On MSTS, on HSL, they used a SNCA value of 15 which is too much (as I said, 7 block sections must be cleared before the marker board before the junction).

[cjakeman]

May I just pop in to say a big "thank you" to everyone who is collaborating and helping in such positive and timely ways to tackle this issue.

I am much more confident now that you will be able to give us all a satisfactory solution.

[Serana]

Here's the pull request : https://github.com/o...nrails/pull/270

Here's the commit containing the new fix : https://github.com/o...851949d2234cd96

Can you review it?


Indeed, I had to remove the extension/shrinking of the scanned route.

[cjakeman]

Serana, on 03 September 2020 - 03:30 PM, said:

Here's the pull request : https://github.com/o...nrails/pull/270

Here's the commit containing the new fix : https://github.com/o...851949d2234cd96

Can you review it?

Many thanks, Cedric, for coming up with this solution.

Rob, are you happy with the content of this fix?

[roeter]

cjakeman, on 06 September 2020 - 02:44 AM, said:

Many thanks, Cedric, for coming up with this solution.

Rob, are you happy with the content of this fix?

I have approved the proposed changes, it's in line with what I would have expected.

Regards,
Rob Roeterdink