Elvas Tower: Proposal to introduce signal variables - 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.
Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Proposal to introduce signal variables Rate Topic: -----

#1 User is offline   roeter 

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

Posted 07 March 2017 - 03:13 AM

This is the first proposal related to the signal processing, it aims at introducing signal variables as described in this blueprint :
Signal Variables

Signal variables will introduce a complete new level of communication between signals, making this independent from the actual signal state and thus allowing for much more information to be passed on between signals than presently possible.

One of the possible uses is to create signals which can handle many more than the present maximum of 8 aspects.
Such a 'signal' would be a combination of a single 'NORMAL' signal which handles all required functions.
This 'NORMAL' signal would set a 'signal state' which will be picked up by the trains as such, but it would also set one or more variables defining a specific aspect. One or more 'INFO' signals (or any other none-normal signal type) would 'pick up' these variables and display the required aspect. Many more aspects can now be displayed by 'mapping' multiple aspects on a specific state. The state is only used to control AI trains and set any cab-aspect display in the cabview. The variable(s) are used to display the aspect.

As the variables can be accessed through 'normal' signal functions which are also available as functions within the program itself, it is also possible to define scripts for cab-aspect displays which use these variables rather than the signal states.

Regards,
Rob Roeterdink

#2 User is offline   Jovet 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 2,240
  • Joined: 14-January 08
  • Gender:Male
  • Location:Omaha, Nebraska.
  • Simulator:MSTS/Open Rails
  • Country:

Posted 08 March 2017 - 03:27 AM

Rob, one point to remember with this proposal:

In MSTS, variables defined in signal scripts are already global. You can create a variable in one script and assign it a value. Another script may come along after that, declare the same variable, and it will have the same value that was assigned to it by the previous script. MSTS only cares about the variable name, not about which script is actually using it. It is a bit of a dirty hack, but I have used this "feature" to allow some global options to be set in some signal systems' programming by sticking important variable assignments into a commonly-used script.

#3 User is offline   roeter 

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

Posted 08 March 2017 - 04:00 AM

View PostJovet, on 08 March 2017 - 03:27 AM, said:

Rob, one point to remember with this proposal:

In MSTS, variables defined in signal scripts are already global. You can create a variable in one script and assign it a value. Another script may come along after that, declare the same variable, and it will have the same value that was assigned to it by the previous script. MSTS only cares about the variable name, not about which script is actually using it. It is a bit of a dirty hack, but I have used this "feature" to allow some global options to be set in some signal systems' programming by sticking important variable assignments into a commonly-used script.


Hello Joseph,

the script variables in OR are not global but strictly restricted to the script in which they are defined and used. Script variables are volatile - they do not exist outside the script. Given the way the script processing is organised, that is impossible to change without a full rewrite of the script processing - and that is not on the cards.
These new variables are not actually script variables as such. What perhaps is not immediately clear is that the variables are organised per signal, not per signal-head. This means that all heads on a signal 'share' the same set of variables. Access is through the designated script functions, for both reading and writing. In all I think that is a much 'cleaner' solution than using an 'accidental' side-effect of how the program was set up.

Regards,
Rob Roeterdink

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