[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