Elvas Tower: Problem with TCS scripts and Timetable mode - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Problem with TCS scripts and Timetable mode Rate Topic: -----

#1 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 19 April 2021 - 11:50 AM

A forumer of my country developed a Timetable using the ETR400 HST as one of the trains, which uses a TCS script.
He reported that the TCS script didn't recognize an increase of the allowed speed from 80 to 140 Km/h (due to a speedpost) when in timetable mode (while it was OK in Explore mode), although the 140 Km/h appear in the Track Monitor.
I debugged that, and in fact things work correctly in "Explore in Activity mode" and not in Timetable mode. A check showed that the problem is in this line within TrainControlSystem.cs
                Script.CurrentSignalSpeedLimitMpS = () => Locomotive.Train.allowedMaxSpeedSignalMpS;

In "Explore in Activity mode" allowedMaxSpeedSignalMps returned the max line speed, as all signals are in state CLEAR_2. In Timetable mode, instead, 80 Km/h are returned, also after the speedpost increasing speed.

So I have a question for Rob: what does allowedMaxSpeedSignalMpS represent in Timetable mode? Is there maybe another variable in Timetable mode, that returns the present allowed max signal speed?

I attach here two pictures, before and after the speedpost raising speed. The speed raise is recognized by the Track Monitor, however it is not by the TCS script (even if this does not appear from the picture; but if I try to increase the speed above 80, I get an emergency brake triggered by the script).

The test has been done with ORNYMG 96, but the Unstable release behaves the same way.

Attached Image: Situation1.jpg

Attached Image: Situation2.jpg

#2 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 20 April 2021 - 10:38 AM

Good Grief! It's been years since I looked at that bit of code. I don't even know if the present code is still what I created, or indeed what I have in my version.

But let's see what can be done.
Three things come to mind.
First, there is that well-known difference between activity/explorer mode and timetable mode regarding the interaction of speed limits set by signals and speed limits set by speedposts. So that things work differently in timetable mode compared to explorer mode does not really come as a surprise.
(NB - for anyone interested in these differences and the background therof - there is many a lengthy thread on this subject here in the vaults of Elvas Tower).

Second, it all works well without TCS scripts. I don't want to point any fingers, but ....

Third, any raise in speed limit is handled through a distance-travelled action event. So let's pick up the trail there and see where it will lead us.
Well, this trail leads directly to the method "SetPendingSpeedLimit" in train.cs, where the action event is processed.

This is (most of) the code of that method - well, at least in my version :

        public void SetPendingSpeedLimit(ActivateSpeedLimit speedInfo)
        {
            float prevMaxSpeedMpS = AllowedMaxSpeedMpS;

            if (speedInfo.MaxSpeedMpSSignal > 0)
            {
                allowedMaxSpeedSignalMpS = Simulator.TimetableMode ? speedInfo.MaxSpeedMpSSignal : allowedAbsoluteMaxSpeedSignalMpS;
                AllowedMaxSpeedMpS = Math.Min(speedInfo.MaxSpeedMpSSignal, Math.Min(allowedMaxSpeedLimitMpS, allowedMaxTempSpeedLimitMpS));
            }
            if (speedInfo.MaxSpeedMpSLimit > 0)
            {
                allowedMaxSpeedLimitMpS = Simulator.TimetableMode ? speedInfo.MaxSpeedMpSLimit : allowedAbsoluteMaxSpeedLimitMpS;
                if (Simulator.TimetableMode)
                    AllowedMaxSpeedMpS = speedInfo.MaxSpeedMpSLimit;
                else
                    AllowedMaxSpeedMpS = Math.Min(speedInfo.MaxSpeedMpSLimit, Math.Min(allowedMaxSpeedSignalMpS, allowedMaxTempSpeedLimitMpS));
            }
            if (speedInfo.MaxTempSpeedMpSLimit > 0 && !Simulator.TimetableMode)
            {
                allowedMaxTempSpeedLimitMpS = allowedAbsoluteMaxTempSpeedLimitMpS;
                AllowedMaxSpeedMpS = Math.Min(speedInfo.MaxTempSpeedMpSLimit, Math.Min(allowedMaxSpeedSignalMpS, allowedMaxSpeedLimitMpS));
            }


So what does this tell us?
There are three variables here :

  • allowedMaxSpeedSignalMpS : this variable is set only when an explicit speed restriction is set in relation to a signal aspect.
    It is not updated based on aspect only - if the active aspect of a signal has no related speed restriction, the value remains unaltered.
  • allowedMaxSpeedLimitMpS : this variable is set based on the speed limit as set in a speedpost.
  • AllowedMaxSpeedMpS : this is the actual valid speed limit, its value is based on the values of the two variables above, and is derived from these variables according to the appropriate logic.


So, my conclusion is that you are using the wrong variable. The variable AllowedMaxSpeedMpS should be used as that is the actual applied speedlimit.
This actually applies to both activity/explorer mode and timetable mode.

Regards,
Rob Roeterdink

#3 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 20 April 2021 - 12:51 PM

Hi Rob,
thanks for your answer and for your time preparing it. However there are scripts that need to differentiate between current max allowed signal speed and current max allowed speedpost speed. These are recalled by the script by those two calls within TrainControlSystem.cs (I already mentioned the first one)
                Script.CurrentSignalSpeedLimitMpS = () => Locomotive.Train.allowedMaxSpeedSignalMpS;
                Script.CurrentPostSpeedLimitMpS = () => Locomotive.Train.allowedMaxSpeedLimitMpS;

These lines are so in the code also in the last stable release 1.3.1.
So what you write, that in timetable mode "allowedMaxSpeedSignalMpS : this variable is set only when an explicit speed restriction is set in relation to a signal aspect" makes this variable unusable for scripts; in activity mode and in explore mode it is always set (it is set to the line speed if the signal does not set a speed limit).
Maybe within the script I will have to read the next signal speed limit just before a signal, and keep it up to the signal after; it's a bit less comfortable.

#4 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 20 April 2021 - 02:05 PM

Quote

So what you write, that in timetable mode "allowedMaxSpeedSignalMpS : this variable is set only when an explicit speed restriction is set in relation to a signal aspect" makes this variable unusable for scripts; in activity mode and in explore mode it is always set (it is set to the line speed if the signal does not set a speed limit).


Yes, I was expecting that, but actually that's wrong.
Here is an example why that should not be done.

The German signalling system has signals which can set speed limits. These speed limits are imposed until a speedpost, other signal or a specific position as laid down in local rules (there's not alway a speedpost or signal, e.g. at station throats where the limit ends at the last switch).
But in the German system there are also often shunt signals in between the main signal and the end of the speed limit. These shunt signals are of course cleared, but the speed restriction may obviously not be lifted by these shunt signals. The shunt signals themselves cannot set a speed restriction as the speed at which these can be passed will depend on the train's path. So any speed restriction applied from a signal must be maintained even if these shunt signals are cleared, and resetting the speed to line speed by these signals is incorrect.

So by resetting speed in this manner in activity/explorer mode you have actually made it impossible to set up such a signal system correctly.
That's why this logic was not introduced in the original signalling, and that's why I'm certainly not going to change that now, or will indeed agree to such a change.

Regards,
Rob Roeterdink

#5 User is offline   YoRyan 

  • Conductor
  • Group: Status: Active Member
  • Posts: 391
  • Joined: 19-February 20
  • Gender:Male
  • Location:California, United States
  • Simulator:Open Rails/unstable
  • Country:

Posted 20 April 2021 - 04:20 PM

Any TCS script author would assume that CurrentSignalSpeedLimitMpS() works the same way across both modes. We'll just have to add a check for timetable mode that returns the line speed if no signal speed is set.

Personally, like Rob, I favor the timetable mode interpretation. I think it should be unambiguous when there is no signal speed limit in force. But how many TCS scripts are in the wild that are assuming the activity mode interpretation?

#6 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 20 April 2021 - 11:19 PM

I won't restart the discussion whether the way activity and explore mode handle signal speeds is better or worse than the way timetable does. By the way it is known that shunting mode can't be handled well without TCS scripts.
I also think that this is not what generates the problem here. In fact in the specific case I mentioned, those 80 km/h that timetable mode keeps in allowedMaxSpeedSignalMpS is not the signal speed of a preceding signal, because all preceding signals were passed in CLEAR_2 state, with no signal speed limit. These 80 km/h are the speed of a preceding speedpost, but not of the last one passed, which is 140 km/h. So that variable is simply not updated with the last speedpost passed and provides a misleading value.
Ryan, I fear that what you suggest as solution requires an intervention in the main OR code and not in TrainControlSystem.cs. What can be done more simply is that, in case of timetable mode, variable AllowedMaxSpeedMpS is selected for Script.CurrentSignalSpeedLimitMpS and not allowedMaxSpeedSignalMpS. That would be better than now, even if it is not what that script variable is expected to return (btw it's not me that introduced that variable).

#7 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 25 April 2021 - 08:09 AM

I've inserted a temporary fix for this in OR NewYear MG rev. 97.

#8 User is offline   Serana 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 489
  • Joined: 21-February 13
  • Gender:Male
  • Location:St Cyr l'Ecole (France)
  • Simulator:Open Rails
  • Country:

Posted 09 May 2021 - 02:40 AM

Hi,

Changing the definition of CurrentSignalSpeedLimitMpS will indeed break some scripts (the French script is one).

And I still don't understand why there should be a difference in timetable mode and activity mode : the speed limits set in the route should be the same for both modes.

And on French high speed lines, the timetable speed limit calculation provokes a lot of problems with AI trains: the signal speed limit is not modified by the following signal (whereas it works perfectly in activity/explorer mode).
On the high speed lines (with TVM), the speed post speed limits are not used (SpeedResume at the entrance of the HSL and no SpeedSign until the train exits the HSL). So I have AI TGVs running at 170 kph while the signal speed limit is 320 kph and there is no speed post speed limit...
By the way, on these French lines, to release a speed limit set by a normal signal, an invisible normal signal is always used (yes, it's not very clean, but that was what was used for routes created for MSTS).

The example of Germany cannot be reproduced everywhere: in Switzerland, the speed limit of the signal is not to be overriden by a speed post. If the signal says 60 kph, it's 60 kph until the next principal signal is passed.

And for the French light signals, the signal speed limit set by a vertical double yellow is not impacted by speed posts: it's 30 kph or 60 kph till the switches are cleared by the train, not until a speed post is passed.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users