Elvas Tower: Expand potential of TCS scripting - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 13 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Expand potential of TCS scripting 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 01 February 2020 - 02:18 AM

TCS (Train control System) scripting allows for the implementation of specific train control systems, rather than the generic and simple TCS that MSTS allows.
Nowaday real world TCS can be very sophisticated and, although they may have some principles in common, they may differ quite significantly.
In the past years gpz and Serana have implemented in OR the hooks that allow to write TCS scripts, and based on this some scripts have been developed. In particular Serana has developed the scripts for the various French TCSs. I believe something exists also fro Magyar TCSs.
IMHO having on board the simulation of a real TCS improves significantly the driving experience of the OR user, so I would like to see more, and more complete TCS scripts implemented.
In studying what is available, and trying to apply it to a simple real case (AWS) I noticed that the work of gpz and Serana has lead to a remarkable, powerful and flexible (and unfortunately undocumented) feature; however I also noticed that hooks should be added to allow the implementation of more complex or particular systems and features.
The following is a (not exhaustive) list of hooks that would be needed:
- the TCS man/machine interface may be very complex; as of now in the hooks there is practically no provision for specific cabview controls; so it is not possible to have further buttons added, or further display indications; therefore the provision for generic, further cabview controls is needed (there is instead already the provision for generic sounds dedicated to the TCS);
- some route info is missing, e.g. signal type;
- no hooks on the route side are available now; these could be provided at the full route level (e.g. adding to the OR extension of the .trk file TCS specific indications, e.g. the existence of a specific TCS on the route); more difficult is to provide them inside the route itself, e.g. to identify beacon positions and their function, or to identify starting and ending points of the TCS and so on.

Most likely only a part of this can be implemented, for various reasons. Moreover things should be as far as possible compatible with the existing scripts. However I think it is wise to have an overall framework, and this is a typical feature that can be implemented and used step-by-step.

Blueprint: https://blueprints.l...-of-tcs-scripts
Trello card to be voted: https://trello.com/c...-of-tcs-scripts

#2 User is offline   darwins 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,222
  • Joined: 25-September 17
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 01 February 2020 - 08:57 AM

It would be excellent if different systems could be implemented in different cabs and in different routes and different sections of line within the same OR route.Any step towards that ultimate goal is a good one.
I have some concern regarding:

Quote

there is practically no provision for specific cabview controls; so it is not possible to have further buttons added, or further display indications

This is another aspect of making the driving experience more authentic and more detailed.One of the reasons sometimes given for this is that there are very few keyboard shortcuts left.
Perhaps some review is needed of which controls (and other functions) need keyboard shortcuts and which do not.My own suggestion would be that shortcut keys are only necessary for tasks that must be done when a train is in motion.
There are already a number of 'control' functions on the F9 menu for example like open/close angle cocks, open/close bleed off valve, apply/release handbrake - these are normally only needed for stationary vehicles and thus do need need keyboard shortcuts.
Similarly apart from acknowledge/cancel there are probably not a lot of TCS functions needed when the train is in motion. (I imagine any setting up of systems would normally be done before the start of a run.)
Perhaps additional switches and controls that are less urgently important could be added as mouse only functions when in cab view.


#3 User is offline   Csantucci 

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

Posted 01 February 2020 - 09:18 AM

Hi darwins,
I have the same concern like you about keyboard shortcuts. In my opinion TCS specific cabview controls should in general only be commanded by mouse.

#4 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 01 February 2020 - 12:21 PM

View PostCsantucci, on 01 February 2020 - 09:18 AM, said:

Hi darwins,
I have the same concern like you about keyboard shortcuts. In my opinion TCS specific cabview controls should in general only be commanded by mouse.

I rqather doubt I'll ever be using TCS but the question of keyboard shortcuts is universal. What comes to mind is actually a question but to ask it I must state the circumstances: Many years ago both Walt N. and myself used a 2d drawing package that used 2 character mnemonics for all typed functions. IIRC there was also a toolbar and right mouse click equivalents so whatever way you wanted to interact w/ the software you could.

Why is OR limited to one character data entry when pressing a "normal" key (e.g., not shift, cntl, or alt)? It looks to me as-if the software can deal with multiple keystrokes already. How about mapping the existing keystrokes to two (or three) characters and then appending however many new pairs you need? Put an option somewhere that allows people to select which one they want and then to simplify the software, create another list that holds the current set and based on the value of the option, use one or the other.

For example,

[ equals LR (locomotive brake release)
] equals LA (locomotive brake apply)
{ equals TR (train brake release)
] equals TA (train brake apply)
and so on.

Or perhaps this -- a prefix of CNTL means whatever follows is a cab located (control) command), a prefix of ALT is a trailing rolling stock command, and a prefix of SHIFT has something to do about the camera. Retaining a single letter following the prefix with this method you will free up the 10 digits and a handful of letters and do so w/o changing the meaning of the existing commands.

Putting the lists into flat files (.json or other) might also be helpful for non-english based comands.

Thoughts?

#5 User is offline   roeter 

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

Posted 03 February 2020 - 04:25 AM

If something is worth doing, it's worth doing properly. But to make TCS scripts possible in a proper way requires far more effort than indicated.
Particularly, the present interface between trains and signals falls far short of what is required for proper implementation of TCS systems.
As said, TCS systems come in many shapes and sizes - transponders, balisses, rail-carried indications etc. Some of these systems have the trigger-points (actions between the system and the train) at the location of main signals, but many do not. Presently, OR only has communication between train and signal for NORMAL type signals, which relate to main signals. This falls far short of what is required. There are further complications as in many systems, not all signals which OR defines as NORMAL will actually have active TCS interface.
Ever since someone posted remarks on cab-signalling, which called for a system which showed the aspect as just passed rather than the aspect being approached, I have been thinking about a new setup of the train-signal interface. The ideas are slowly taking shape, but are still some way off implementation.

Here's what on my mind.

First of all, what is needed is an explicit signal-train interaction for TCS systems. This could be provided by a new signal script function, or perhaps a set of functions. Perhaps it would be possible to define signal script functions which could serve as a hook for TCS scripts. This function can be called by any type of signal which would have active interaction with the train.
But, as stated, presently only NORMAl signals interact with trains. Other type of signals cannot be 'seen' by the trains, and neither do these signals 'see' the trains. TCS triggers are therefor presently not possible for other types of signals.

To address this problem needs a rewrite of the Track Circuit logic. Track Circuits are sections of track, presently based on NORMAL signals, nodes and cross-overs.
This system would need to extended, and Track Circuit breaks would be based on the following locations :
  • Any type of signal
  • All speedposts
  • All other objects which are placed in tracks, e.g. platform markers, siding markers.
  • Signal and switch overlap positions
  • Level crossing activation posisions


Splitting the Track Circuits in this manner is actually quite easy, as the present logic can be used.
One major issue however is that a completely new datastructure will be required as interaction between Track Circuits, signals and trains.
Another major change which would follow from this setup is the present use of 'distance travelled triggers'. At present, these triggers, based on the distance a train has travelled, are used to clear Track Circuits, activate speed limits rises etc. However, if the Track Circuits are setup as defined above, these triggers would no longer be required as the Track Circuits could be used directly. It's too complicated to go into full details here, but it would simplify this part of the logic and would also improve behaviour in a number of situations where the present logic is not adequate, in particular for overlap protection. Including level crossing interaction would also finally allow proper interfacing between level crossings and signalling, something which is completely missing at the moment.
But it will be a major rewrite of a significant part of the signalling code.

So what does this have to do with implementation of TCS?
Well, as stated, lots of TCS systems use none-NORMAL signals. And presently there is no interaction between none-NORMAL signals and trains, to create this using the present datastructure is far from straightforward. But worse, if TCS scripts are developed for such systems using the present data structure, a conflict would arise if the above changes would be implemented, either blocking the new Track Circuit setup, or making any TCS scripts using the present data useless.
As TCS scripts are not part of the main program it would not be possible to take these along with the rebuild; but even if they were part, it could add so much more work that possibly it would no longer be achievable.

So, I make a strong plea not to develop TCS systems based on none-NORMAL signals at this point in time. The present system is not adequate for such systems, and trying to implement such systems based on the present datastructure will cause serious conflicts for future development.
So, in my view, this is not the right time to start on these features.

Regards,
Rob Roeterdink

#6 User is offline   darwins 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,222
  • Joined: 25-September 17
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 03 February 2020 - 05:18 AM

What you are suggesting sounds like a path that OR needs to go down.
It also sounds like a big job for those writing the code.


Looking at the list of things that might be included...


Quote

To address this problem needs a rewrite of the Track Circuit logic. Track Circuits are sections of track, presently based on NORMAL signals, nodes and cross-overs.
This system would need to extended, and Track Circuit breaks would be based on the following locations :
  • Any type of signal
  • All speedposts
  • All other objects which are placed in tracks, e.g. platform markers, siding markers.
  • Signal and switch overlap positions
  • Level crossing activation posisions


I would imagine that as part of that you would also need to think about the logic required to join two or more of the new smaller track circuit sections together to work as a single unit (block) - the section from the last home signal of one station to the last home signal of the next normally being one block.

There might then within that block be a number of track circuit sections divided by the various track objects.


This would possibly solve a number of signalling issues as well -

shunt ahead signals - allowing you to move into an occupied section ahead as far as a shunt limit

signal interlocking with level crossings
distant signals that do not clear until all the home signals are cleared up to the next distant

approach speed control signals


Better communication between train and signals might also help with permissive signals - although these also require communication between train and train to prevent collisions.


#7 User is offline   Csantucci 

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

Posted 04 February 2020 - 07:24 AM

Rob,
you are foreseeing problems in developing TCS systems based on none-NORMAL signals at this point in time. I don't think there are such problems, at least for certain TCS, and can demonstrate that by explaining what I had to do to develop the AWS TCS (I have terminated an alpha release and will publish it in short).
To enable AWS I had to add within TrainControlSystem.cs following hooks to the many existing ones:
1) bool DoesNextNormalSignalHaveTwoAspects (in reality the result is true only if the NORMAL Signal has only one head and such head has only two aspects. that are STOP and CLEAR_2;
2) float NextDistanceSignalDistanceM : this returns the distance to next DISTANCE signal
3) Aspect NextDistanceSignalAspect : this returns the aspect of next DISTANCE signal
I have added also a further hook, but it is not needed for AWS, that is
4) bool DoesNextNormalSignalHaveDistanceHead : result is true if next NORMAL Signal has also at least a DISTANCE head. This hook may be of interest for other TCS that are based on DISTANCE signals, together with a missing one, that could be
5) Aspect NextNormalSignalDistanceHeadAspect.

These hooks can't create problems neither to the scripts nor to the OR code, because DISTANCE signals will continue to be there where they are now, and so they will have a DISTANCE from the train and an ASPECT that will remain the same also if a new Track Circuit setup is generated. The scripts (at least TCS_France and AWS, but I foresee also others, at least for their basic functions) don't know nothing about the Track Circuit setup.
So, if the Track Circuit setup will be changed, the since long time existing TCS_France.cs script won't be changed, and the TCS_AWS_UK.cs script I'm publishing won't be changed. What will have to be changed is the code of the script hooks in TrainControlSystem.cs, but this really is a minor task in redoing the Track Circuit setup: it's enough to see how few code lines are used for such script setup.

#8 User is offline   roeter 

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

Posted 04 February 2020 - 09:24 AM

To get the position of the DISTANCE signal, the present data which holds the information with regards to other types of signals within a Track Circuit has to be used. When the Track Circuit setup is changed as explained above, this data will no longer exist, because there are no signals within a Track Circuit. Therefor, any script using this data will fail. So, either the existing data structure will have to be maintained even though it no longer has any function, which is complicated and creates additional work, or the script will have to be rewritten once the Track Circuit revision is completed in order to use the new data.

If the French system also uses none-NORMAL signals it will face the same problems.

Regards,
Rob Roeterdink

#9 User is offline   Csantucci 

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

Posted 04 February 2020 - 12:28 PM

Rob,
you wrote
"Other type of signals cannot be 'seen' by the trains, and neither do these signals 'see' the trains. TCS triggers are therefor presently not possible for other types of signals."
I have demostrated that that is instead possible.
You also wrote
"This system would need to extended, and Track Circuit breaks would be based on the following locations :
Any type of signal"
and now that I have demostrated that it is possible to interact with a DISTANCE signal, you write now that distance data for DISTANCE signal won't be available any more.

I don't know what your intentions are, but if you have the intention to cancel the possibility to get the distance from train to a DISTANCE signal, well, I'm against that. This is an info which is available now and I don't see why you should cancel it. And if you will cancel it, I will restore it for TCS use; fortunately this info is already in the TDB file, and from there it cannot be cancelled.

#10 User is offline   roeter 

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

Posted 05 February 2020 - 02:53 AM

View PostCsantucci, on 04 February 2020 - 12:28 PM, said:

I don't know what your intentions are, but if you have the intention to cancel the possibility to get the distance from train to a DISTANCE signal, well, I'm against that. This is an info which is available now and I don't see why you should cancel it. And if you will cancel it, I will restore it for TCS use; fortunately this info is already in the TDB file, and from there it cannot be cancelled.

Not to worry, I won't be making any changes anymore to the signalling code, or any other code for that matter.
To ensure this I have resigned myself from Github.

Regards,
Rob Roeterdink

  • 13 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

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