[jonas]

I am currently working on so-called Sv-signals of the Berlin S-Bahn which should allow "driving on sight" among other things. It must be distinguished whether a block is influenced by a train or an obstructing switch. After successfully testing and finishing programming for the signal in the sigscr.dat for MSTS, it turns out that it was extremely(!) different in OR. After a few hours of troubleshooting, here is my astonished summary:

At least the BLOCK_values OCCUPIED and JN_OBSTRUCTED, as well as the variable "enabled" work basically different in OR than in MSTS.

BLOCK_OCCUPIED
In MSTS, this value indicates that a block is being occupied by a train (the direction of travel or if the train has stoped is irrelevant).
In OR in addition the direction of travel seems to play a role. To opposite direction driving trains seems not to lock the block in OR.

BLOCK_ JN_OBSTRUCTED
In MSTS, this value indicates that a block is impassable by an obstructing switch.
In OR, switches do not seem to have any influence! However, trains in the block are registered. It's almost as if the "JN" for juction in "JN_OBSTRUCTED" would not matter. Instead, trains in the block are taken into account. Irritating...

extern float enabled
In MSTS, a signal can be declared as defective in the AE with this variable. In the game, it will never to be changed by train passing the signal.
In OR, the signal becomes "disabled" after a train is passing the signal, wow! enabled is thus always set to false after passing a train.

The same signal script therefore leads in OR to fundamentally different signal aspects and, as in the latter case, ever to the "failure" of the signal due to the simple passing of a train.

I did not trust my eyes when I realized this mistakes. Has nobody noticed this or similar yet? Hm...or where do I go wrong?

The differences between MSTS and OR for the Block_Values were confirmed after I found the comments in the code of OR:

OR code
publicenum MstsBlockState
{
CLEAR, // Block ahead is clear and accesible
OCCUPIED, // Block ahead is occupied by one or more wagons/locos notmoving in opposite direction
JN_OBSTRUCTED,// Block ahead is impassable due to the state of a switch or occupied by moving train or not accesible
}

MSTS manual description
CLEAR -Block ahead is clear
OCCUPIED -Block ahead is occupied by one or more wagons/locos
JN_OBSTRUCTED -Block ahead is impassable due to the state of a switch

My used code from the sigscr.dat:

SCRIPT Sig28SvHSicht_Vmax_Jm
	extern float enabled;
	extern float block_state();
	extern float state;			
	extern float route_set();

	if ( !enabled || (block_state() ==# BLOCK_JN_OBSTRUCTED) ) //If Signal inactiv or block ahead obstructed by switch...
		state = SIGASP_STOP;   				//...then state is STOP				(Hp0)
	else if ( !route_set() )   				//If aim-route NOT reachable...
		state = SIGASP_APPROACH_1;   			//...then state is APPROACH_1			(Hp2)
	else if ( block_state() ==# BLOCK_OCCUPIED )   		//If block ahead is occupied...
		state = SIGASP_RESTRICTING;   			//...then "drive on sight"				(Sv0)  
	else   							//any else...
		state = SIGASP_CLEAR_2;   				//...state is CLEAR_2				(Hp1)

	if ( (block_state() ==# BLOCK_OCCUPIED) && !route_set() )  //If block ahead occupied but aim route NOT reachable...
		state = SIGASP_STOP;   				//...then state is STOP				(Hp0)  

[ebnertra000]

A couple of things I see here:

Enabled; has nothing to do with whether the signal is set to malfunction. If a signal is not enabled, it means that the AI dispatcher has not set a path for a train to pass that signal, either because a train is on a conflicting route or there is no train coming from any direction. Use of enabled; is typically associated with control points, or another dispatcher-controlled signals (not automatic signals).

As far as block states, I typically use if (block_state !=# BLOCK_CLEAR) when I'm stating conditions to set a signal at stop. I might use if (enabled && block_state ==# BLOCK_OCCUPIED) to allow someone to drive on sight past a controlled signal.

Hope these help a little

[jonas]

ebnertra000, on 13 December 2018 - 11:43 AM, said:

Enabled; has nothing to do with whether the signal is set to malfunction. If a signal is not enabled, it means that the AI dispatcher has not set a path for a train to pass that signal, either because a train is on a conflicting route or there is no train coming from any direction. Use of enabled; is typically associated with control points, or another dispatcher-controlled signals (not automatic signals).

MSTS manual says:
"enabled - Contains TRUE (non-zero) if the current signal instance is enabled to show its natural state, or FALSE otherwise."

When using this simple code for a signal...

    if (enabled)
		state = SIGASP_CLEAR_2;
	else
		state = SIGASP_STOP;

...you will see that OR changes Enabled from True to False after a train passed the signal. In MSTS Enabled will stay True.

[ebnertra000]

If enabled is FALSE, a signal will show whatever state is specified for that condition, rather than being governed by block states, route settings, etc. (its 'natural state'). Usually, the state specified for "!enabled" is Stop, so the dispatcher can override a signal's natural state, and force it to red if he/she/it doesn't want a train to pass that signal for some reason.

When you do these tests, what mode are you using? If I recall, in MSTS Explore Mode all signals were enabled (the only reds were because of block or route states). But in OR explore mode, only signals in front of or behind the train are enabled (none on adjacent tracks or on the same track as the train but facing away). In Activities...I don't know how that works, probably pretty similar to OR explore mode

[jonas]

Ok, now I have understood better the role "enabled" plays in the simulator and in reality. Thank you so far ebnertra000!

I did the tests both in MSTS and in OR in Explore and Activity mode. "Enabled" behaves differently in MSTS after the player train is passing a signal than in OR, no matter which mode. This could then leads to different script executions (if-branches), one can easily imagine.

But what I consider much more serious is the different interpretation of the BLOCK_values (CLEAR, OCCUPIED, JN_OBSTRUCTED)! All three are evaluated by OR differently than in MSTS, which can already be found in the comments in the OR code (see yellow text in post #1).

For example, in OR BLOCK_ JN_OBSTRUCTED does not consider obstructing switches, but whether a train is in the block. In MSTS BLOCK_OCCUPIED is used for that.
So: Why this differences!?

[eugenR]

jonas, on 13 December 2018 - 08:29 PM, said:

Ok, now I have understood better the role "enabled" plays in the simulator and in reality. Thank you so far ebnertra000!

I did the tests both in MSTS and in OR in Explore and Activity mode. "Enabled" behaves differently in MSTS after the player train is passing a signal than in OR, no matter which mode. This could then leads to different script executions (if-branches), one can easily imagine.

But what I consider much more serious is the different interpretation of the BLOCK_values (CLEAR, OCCUPIED, JN_OBSTRUCTED)! All three are evaluated by OR differently than in MSTS, which can already be found in the comments in the OR code (see yellow text in post #1).

For example, in OR BLOCK_ JN_OBSTRUCTED does not consider obstructing switches, but whether a train is in the block. In MSTS BLOCK_OCCUPIED is used for that.
So: Why this differences!?

My idea for that:
"OCCUPIED, // Block ahead is occupied by one or more wagons/locos notmoving in opposite direction"
For Mountain-Railways is sometime allowed, that more the one Train can enter in a block in the same direction, because of the limited length of the trains.
With the OR_definition of OCCUPIED, the signal-logic can find out if the train in the block is rolling in the same direction, and can set the corresponding signals.

But I think this fact should be described in the Manual.

Regards
EugenR

[roeter]

There is a funny contradiction in your arguments. You want to implemented the "driving on sight" (call-on in English). MSTS never could handle this properly for AI trains - AI trains would ignore one another and often run straight through eachother, which usually ended in a crash. The signalling in OR is different and does properly handle this situation. Yet you complain that OR is different. If OR were a copy of MSTS, this function would never work.

Another important point is that OR is compatible - that is not the same as copy. A basic MSTS script will still work in OR, but there are detail differences. These are quite deliberate and for very good reasons.

As for the reasons : the first main reason is that signalling in MSTS does not work properly. As mentioned, "call-on" for AI trains never worked in MSTS. And that is just one of the many problems with MSTS signalling. The second reason is that the exact logic of the MSTS signalling is not known. There are no documents or whatever which describe how signalling is implemented in MSTS.

All this means that signalling for OR had to be developped from scratch.
Two groundrules form the base of the OR signalling :

• OR has no dispatcher function. Each train functions as its own dispatcher and has to clear and set its own route.
  
• There is no distinction between types of train, so AI train and player train are processed in the same way.

Two other decisions were made wich had an impact on the logic. One was that call-on for AI trains should be made possible. The other was that the basic script functions would be maintained, making existing scripts compatible with regard to basic functions.

However, the groundrules as defined above made it necessary that some slight changes were made w.r.t. the definition of the blockstates and the 'enabled' variable.
The definitions are :

• BLOCK_JN_OBSTRUCTED
  The section ahead is blocked for the approaching train. When this condition is returned, the signal should never be allowed to clear.
  In principle, this state is returned under the following conditions :
  
  • Another train has cleared or is occupying a path through the section such that it locks a switch in an unaligned position.
    
  • Another train has cleared or is occupyinh a path through the section and is moving (or intending to move) in opposite direction.
  
  Note that, in most cases, the second rule automatically implies the first rule - for if not, it would lead to a deadlock (trains facing eachother in opposite directions). The only situation where the second rule applies but the first does not, is if that particular train is to reverse in the section in question.
  
  
• BLOCK_OCCUPIED
  The section ahead is occupied by another train but that train is stationary or is moving in the same direction. Any switches in the section up to the position of the train ahead are properly aligned as required.
  Defining this state in this manner allows proper working of call-on functionality.
  If BLOCK_OCCUPIED would be returned rather that BLOCK_JN_OBSTRUCTED in case of a train moving in opposite direction, implementation of call-on would not have been possible as no distinction could have been made for trains standing still or moving in same direction (when call-on would be allowed), or trains running in opposite direction (when call-on would never be allowed). So without this change in definition, call-on could never have been implemented.
  
  
• BLOCK_CLEAR
  All other states, i.e. there is no other train which has cleared a path though the section or is occupying the section.
  In this situation, the actual state of switches in this section is irrelevant. Remember that there is no dispatcher function and the train has to set its own path, so the train itself has to aling all switches ahead. A switch ahead could be misaligned as that is the state in which the previous train running over that switch may have left it. If, in this situation, BLOCK_JN_OCCUPIED would be returned, the train would never be able to continue - for without a dispatcher function, there is no function within the program which would align that switch. End of story. So if a switch is misaligned but is 'available', i.e. there is no route cleared over it by another train, the state BLOCK_CLEAR is returned thus allowing the signal to clear and in that process, to properly align the switch.
  
  
• enabled variable
  Taking the definition literally : "if signal is enabled by dispatcher", the variable would always be 'false' as OR has no dispatcher function.
  So the meaning behind this definition is used, and the variable is defined such that it allows definition of two types of signal control:
  
  • controlled signal
    Default position of such a signal is 'stop'. The signal is only cleared if a path is set from this signal. In real life, this is done by a dispatcher. In OR, this is done by the train itself.
    
  • automatic signal
    Default position of such a signal is 'clear'. The signal is in stop state only if the section ahead is blocked.
  
  The enabled variable is defined in such a way that if this variable is tested, the signal operates as a 'controlled signal'; if not, the signal operates as an 'automatic signal'. The variable is 'true' when a path is requested from that signal. As there is no dispatcher, this implies it is the train itself which makes this request. When the train passes a signal, there is no longer a request for that signal to clear a path, so enabled drops back to false.

Since the basic implementation of signalling, many more functions have been added, including proper call-on functions. More detailed control of all trains including AI trains has been made available through these new functions, even more so in timetable mode as commands defining interaction between trains and signals as well as between two trains were defined for timetables, offering functionality that MSTS never provided.
OR offers far greater control over AI trains than MSTS ever could, for instance including coupling/uncoupling of AI trains. The price to pay was a slight difference in definition of the signal script variables. If these definitions had been maintained as an exact copy of what they were in MSTS, expanding the functionality beyond what MSTS could offer would not have been possible.

Regards,
Rob Roeterdink

[eugenR]

Hi Rob,
Thank you for the comprehensive Explications of the Function of this signalscript-variables in OpenRails.
To complet the Story, has the variable Route_Set() the same Function as in MSTS? I think so?

Regards
EugenR

[ebnertra000]

EugenR,

In my experience, route_set() does function the same as in MSTS

[jonas]

Rob, thanks for the detailed answer. I appreciate the time spent on this and, of course, the extensive time and effort invested in OR signal programming.

Meanwhile I tested the three BLOCK_Values with a simple signal (script) . Here is the result:  BLOCK_Values_eng.zip (136.71K)
Number of downloads: 439
According to this I have to apologize and correct myself in comparison to post # 1, because I have now seen that OR responds to at least all BLOCK_Values, while MSTS e.g. apparently not react to BLOCK_JN_OBSTRUCTED (!) at all, wow!

For my understanding, I would still like to ask again, why were the MSTS BLOCK_Values are used for the new expanded signal functions of OR instead of using OR-own variables?

roeter, on 14 December 2018 - 02:55 AM, said:

There is a funny contradiction in your arguments. You want to implemented the "driving on sight" (call-on in English). MSTS never could handle this properly for AI trains - AI trains would ignore one another and often run straight through eachother, which usually ended in a crash. The signalling in OR is different and does properly handle this situation. Yet you complain that OR is different. If OR were a copy of MSTS, this function would never work. ...

My point is not to question the improved signal function of OR for "call-on". On the contrary, I welcome these, but in MSTS it unfortunately uses me nothing. I just mentioned "drive on sight" to make the background of my problem transparent. If I had written only briefly, "Why are the BLOCK values in OR different from those in MSTS?", then questions would have come as to why I want to know that at all and what I need it for.

roeter, on 14 December 2018 - 02:55 AM, said:

...There are no documents or whatever which describe how signalling is implemented in MSTS. ...

Do you exclude here the MSTS file: "How_to_make_Signal_config_and_Script_files.doc"?

I may be the last "dinosaur" to still update a current route that needs to run on both simulators, MSTS and OR, as technically similar as possible. There are (still! :-) some people using MSTS for this route, which amazes me too. Therefore, for me final tests are always for both simulators to make and thats why I notice ofen the differences.
Since I do everything on the route myself, modelling locomotivs, TDB file, 3D-objects etc. and the signal construction too, I'm glad that I have a default orientation with the MSTS as the "lowest common denominator". So it's not an ignorance or disrespect if I do not use some of the new OR functions, since they do not help me in MSTS.

Many greetings
jonas