Elvas Tower: New signalling functions - 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.
  • 8 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

New signalling functions OR specific signalling functions added in version 2266 Rate Topic: -----

#1 User is offline   roeter 

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

Posted 31 May 2014 - 02:06 AM

The recently introduced option to have OR-specific sigcfg.dat and sigscr.dat files have opened up the possibility to create new, OR-specific signalling functions.
The first of such functions have now been created and are available in release 2266.

Here is a description of what these are and how they work.
First, for those who do not yet know, details of how to set OR-specific sigcfg.dat and sigscr.dat files.

How to set OR specific signal files.

The following steps will create OR-specific signal definition files :
  • Create a directory named OpenRails in the route's main directory.
  • Copy the existing sigcfg.dat file to this new OpenRails directory.
    Do not change the file name or extension.
  • Check the sigcfg.dat file for all required signal script files (defined in Scriptfiles statement at end of sigcfg.dat file).
    Copy all required script files to the OpenRails directory.
    Do not change the file name or extension.


Please note that the OR-files are full replacement files - these are not 'include' files or additional files, but the OR-specific files must contain all required definitions for signal types and signal shapes, as well as all required scripts.

Important note.
Because for route editing we still depend on the MSTS route editor, if any new signal types or signal shapes are introduced in the OR-specific files, similar named entries must also be included in the original MSTS files, otherwise these new signals can not be placed in the route.
If a new signal has an OR-specific signal function type, the definition in the MSTS files must be set to one of the original signal function types. When the route is still used in MSTS, care must be taken that this signal type does not conflict with existing signalling. If the route is no longer used in MSTS, then obviously this does not matter.

New signal types and signal functions will be detailed in the nexts set of posts.

Regards,
Rob Roeterdink

#2 User is offline   roeter 

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

Posted 31 May 2014 - 02:15 AM

SPEED signals - new signal function type

The SPEED signal function type allows a signal object marker to be used as a speed sign.

The advantages of such use are :
  • The signal object marker only applies to the track on which it is placed.
    Original speed signs always also affect any nearby lines, making it difficult and sometimes impossible to set a specific speed limit on just one track in complex areas.
  • As signal object, the SPEED signal can have multiple states defined and a script function to select the required state, e.g. based on route selection.
    This allows different speed limits to be defined for different routes through the area, e.g. no limit for the main line but specific limits for a number of diverging routes.


The SPEED signal is fully processed as a speed limit and not as a signal, it has no effect on any other signals.

Limitation : it is not possible to define different speeds related to type of train (passenger or freight).

Definition and usage
Definition is similar as for any other signal, with SignalFnType set to "SPEED".
It allows definition of drawstates and aspects like any other signal. Different speed values can be defined per aspect as normal.

An aspect can be set to not have an active speedlimit. If this aspect is active, the speed limit will not be changed. This can, for instance, be used if a route-linked speed limit is required. This aspect can then be set for a route for which no speed limit is required.
An aspect can also be set to not have an active speedlimit but with a special signal flag : OR_SPEEDRESET.
If this flag is set, the speed limit will be reset to the limit as set by the last speedlimit sign. This can be used to reset any limit imposed by a specific signal aspect. Note that this does not overrule any speed limits set by another SPEED signal as those limits are processed as if set by a speedlimit sign.

Example :

        SignalType ("SpeedSignal"
		SignalFnType ( SPEED )
		SignalLightTex ( "ltex" )

		SignalDrawStates ( 5
			SignalDrawState ( 0
				"speed25"
				)
			)
			SignalDrawState ( 1
				"speed40"
				)
			)
			SignalDrawState ( 2
				"speed50"
				)
			)
			SignalDrawState ( 3
				"speed60"
				)
			)
			SignalDrawState ( 4
				"speed70"
				)
			)
		)
		SignalAspects ( 5
			SignalAspect ( APPROACH_1	"speed25"	SpeedMPH ( 25 ) )
			SignalAspect ( APPROACH_2	"speed40"	SpeedMPH ( 40 ) )
			SignalAspect ( APPROACH_3	"speed50"	SpeedMPH ( 50 ) )
			SignalAspect ( CLEAR_1	 	"speed60"	SpeedMPH ( 60 ) )
			SignalAspect ( CLEAR_2	 	"speed70"	SpeedMPH ( 70 ) )
		)
		SignalNumClearAhead ( 2 )
        )


Notes :
  • The SignalNumClearAhead value must be included to satisfy syntax but has no function.
  • The actual speed can be set either using fixed aspect selection through user functions, or can be route linked.
    The actual use is defined in the related script and the related shape definition.


Example 2 :

        SignalType ( "SpeedReset"
                SignalFnType ( SPEED )
                SignalLightTex ( "ltex" )

                SignalDrawStates ( 1
                        SignalDrawState ( 0
                            "Red"
                        )
                )

                SignalAspects ( 1
                        SignalAspect ( STOP       "Red"  signalflags (OR_SPEEDRESET) )
                )
                SignalNumClearAhead ( 2 )
       )


This example resets the speed to the limit as set by the last speedsign, overruling any speed limits set by signal aspects.

Regards,
Rob Roeterdink

#3 User is offline   roeter 

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

Posted 31 May 2014 - 02:48 AM

Approach control functions.

Approach control signals are used, specifically in the UK, to keep a signal at 'danger' until the train is within a specific distance ahead of the signal, or has reduced its speed to a specific value. Such control is used for diverging routes, to ensure the speed of the train is reduced sufficiently to safely negotiate the switches onto the diverging route.

For use in OR, two script functions have been defined which can be used to control the signal until the train has reached a specific position or reduced its speed.

These functions are :

  • APPROACH_CONTROL_POSITION(position)
  • APPROACH_CONTROL_SPEED(position, speed)


These functions are Boolean functions, returned value is 'true' if a train is approaching the signal and is within required distance of the signal and, for APPROACH_CONTROL_SPEED, has reduced its speed below the required values.

Parameters :
position : required distance of train approaching the signal, in meter.
speed : required speed, in meter/sec.

Note that the speed is checked only when the train is within the defined distance.

Important note :
Allthough the script uses 'float' to define local variables, these are in fact all integers.
This is also true for the values used in these functions : if direct values are used, these must be integer values.

The values may be set directly in the signalscript, either as variables or as numbers in the function call.
However, it is also possible to define the required limits in the sigcfg.dat file as part of the signal definition.

The syntax definition for this is :

ApproachControlLimits ( <definitions> )

Allowed definitions :
  • Position :
    • Positionm : position in meter.
    • Positionkm : position in kilometer.
    • Positionmiles : position in miles.
    • Positionyd : position in yards.

  • Speed :
    • Speedkph : speed in km / hour.
    • Speedmph : speed in miles / hour.


These values are referenced in the script file using the following variable names :

  • Approach_Control_Req_Position
  • Appraoch_Control_Req_Speed


These variables must not be defined as floats etc., but can be used directly without prior definition.
Note that the values as defined in the sigcfg.dat file will be converted to meter and meter/sec and rounded to the nearest integer value.

Example.
This example is a three-head search light signal, which uses Approach Control if the route is set to the 'lower' head.
Route selection is through 'dummy' DISTANCE type route-selection signals.

Signal defintion :

	SignalType ( "SL_J_40_LAC"

		SignalFnType ( NORMAL )
		SignalLightTex ( "bltex" )
		SigFlashDuration ( 0.5 0.5 )

		SignalLights ( 8
			SignalLight ( 0 "Red Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 1 "Amber Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 2 "Green Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 3 "Red Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 4 "Amber Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 5 "Green Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 6 "Amber Light"
				Position ( 0 2.7 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 7 "White Light"
				Position ( 0 2.7 0.11 )
				Radius ( 0.125 )
			)
		)
		SignalDrawStates ( 8
			SignalDrawState ( 0
				"Red"
				DrawLights ( 1
					DrawLight ( 0 )
				)
			)
			SignalDrawState ( 1
				"TopYellow"
				DrawLights ( 1
					DrawLight ( 1 )
				)
			)
			SignalDrawState ( 2
				"TopGreen"
				DrawLights ( 1
					DrawLight ( 2 )
				)
			)
			SignalDrawState ( 3
				"TopYellowMidGreen"
				DrawLights ( 2
					DrawLight ( 1 )
					DrawLight ( 5 )
				)
			)
			SignalDrawState ( 4
				"MidYellow"
				DrawLights ( 2
					DrawLight ( 0 )
					DrawLight ( 4 )
				)
			)
			SignalDrawState ( 5
				"MidGreen"
				DrawLights ( 2
					DrawLight ( 0 )
					DrawLight ( 5 )
				)
			)
			SignalDrawState ( 6
				"LowYellow"
				DrawLights ( 3
					DrawLight ( 0 )
					DrawLight ( 3 )
					DrawLight ( 6 )
				)
			)
			SignalDrawState ( 7
				"LowWhite"
				DrawLights ( 3
					DrawLight ( 0 )
					DrawLight ( 3 )
					DrawLight ( 7 SignalFlags ( FLASHING ))
				)
			)
		)
		SignalAspects ( 8
			SignalAspect ( STOP			    	"Red" )
			SignalAspect ( STOP_AND_PROCEED			"LowWhite" SpeedMPH(25) )
			SignalAspect ( RESTRICTING			"LowYellow" SpeedMPH(25) )
			SignalAspect ( APPROACH_1			"MidYellow" SpeedMPH(40) )
			SignalAspect ( APPROACH_2			"TopYellowMidGreen" )
			SignalAspect ( APPROACH_3			"TopYellow" )
			SignalAspect ( CLEAR_1				"MidGreen" SpeedMPH(40) )
			SignalAspect ( CLEAR_2				"TopGreen" )
		)

                ApproachControlSettings (
                        PositionM  ( 500 )
                        SpeedMpH   ( 10  )
                )

		SignalNumClearAhead ( 5 )
        )


Signal function (reduced to show use of approach control only).
This function uses approach control for the 'lower' route.

///////////////////////////////////////////////////////////////////////////////

SCRIPT SL_J_40_LAC

// Searchlight Top Main Junction
	extern float	block_state ();
	extern float	route_set ();
	extern float	def_draw_state ();
	extern float    next_sig_lr ();
	extern float    sig_feature ();
	extern float	state;
	extern float	draw_state;
	extern float	enabled;

//
// Returned states
// drawn :
//      SIGASP_STOP
//
//   Top Cleared :
//      SIGASP_APPROACH_3
//      SIGASP_APPROACH_2
//      SIGASP_CLEAR_2
//
//   Middle Cleared :
//      SIGASP_APPROACH_1
//      SIGASP_CLEAR_1
//
//   Lower Cleared :
//      SIGASP_RESTRICTING
//      SIGASP_STOP_AND_PROCEED
//
  
//
// User Flags
//
// USER1 : copy top approach
// USER2 : top approach junction
// USER3 : copy middle approach
// USER4 : no check block for lower
//

    float           clearstate;
    float           setstate;
    float           diststate;
    float           adiststate;
    float           nextstate;
    float           routestate;
    float           blockstate;

    blockstate = 0;
    clearstate = 0;
    routestate = 0;
    setstate   = 0;
    nextstate  = next_sig_lr(SIGFN_NORMAL);
    diststate  = next_sig_lr(SIGFN_DISTANCE);
    adiststate = diststate;

    if (diststate ==# SIGASP_CLEAR_1)
    {
       diststate = SIGASP_CLEAR_2;
    }
    if (diststate ==# SIGASP_APPROACH_1)
    {
       diststate = SIGASP_APPROACH_3;
    }

// get block state

   if (!enabled)
    {
        clearstate = -1;
    }

    if (block_state () ==# BLOCK_JN_OBSTRUCTED)
    {
        clearstate = -1;
    }

    if (block_state() ==# BLOCK_OCCUPIED)
    {
        blockstate = -1;
    }

// check if distant indicates correct route

    if (diststate ==# SIGASP_STOP)
    {
        clearstate = -1;
    }

// top route

    state = SIGASP_STOP;

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_CLEAR_2)
    {
        // aspect selection for top route (not shown)
        .......
    }

// middle route

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_APPROACH_3) 
    {
        // aspect selection for middle route (not shown)
        .......
    }

// lower route

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_RESTRICTING) 
    {
        if (Approach_Control_Speed(Approach_Control_Req_Position, Approach_Control_Req_Speed))
        {
            state = SIGASP_RESTRICTING;
        }
    }

// Get draw state
	draw_state = def_draw_state (state);


Regards,
Rob Roeterdink

#4 User is offline   roeter 

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

Posted 31 May 2014 - 03:07 AM

TrainHasCallOn function

This function is intended specifically to allow trains to 'call on' in Timetable mode when allowed to do so as defined in the timetable.
The use of this function allows a train to 'call on' into a platform in Timetable mode without jeopardizing the functionality in normal Activity mode.

It is a Boolean function and returns state as follows :

  • Activity Mode :
    • Returns true if :
      • Route from signal is not leading into a platform.

  • Timetable Mode :
    • Returns true if :
      • Route from signal is not leading into a platform.
      • Route from signal is leading into a platform and the train has a booked stop in that platform, and either of the following states is true :
        • Train has $CallOn command set for this station.
        • Train has $Attach command set for this station.
        • Train is part of RunRound command, and is to attach to the train presently in the platform.


The use of this function must be combined with a check for blockstate ==# BLOCK_OCCUPIED.

Note : this function must NOT be used in combination with blockstate ==# JN_OBSTRUCTED.
The state JN_OBSTRUCTED is used to indicate that the route is not accesible to the train (e.g. switch set against the train, opposite movement taking place etc.).
Some signal scripts allow signals to clear on blockstate ==# JN_OBSTRUCTED. This can lead to all kinds of incorrect situations.
These problems are not due to programming errors but to route signal script errors.

Example (part of script only) :

if (enabled && route_set() )
{
     if (block_state == #BLOCK_CLEAR)
     {
     // normal clear, e.g.
             state = #SIGASP_CLEAR_1;
     }
     else if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )
     {
     // clear on occupied track and CallOn allowed
            state = #SIGASP_STOP_AND_PROCEED;
     }
     else
     {
     // track is not clear or CallOn not allowed
            state = #SIGASP_STOP;
     }
}


Regards,
Rob Roeterdink

#5 User is offline   Stefan PAITONI 

  • Fireman
  • Group: Status: Active Member
  • Posts: 118
  • Joined: 26-February 13
  • Gender:Male
  • Location:Belgium,
  • Simulator:MSTS & OR
  • Country:

Posted 31 May 2014 - 03:50 AM

Hello Rob,
Good work Rob, I have some jobs to do in order to take care of those improvements.

Stef

#6 User is offline   Csantucci 

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

Posted 31 May 2014 - 11:03 AM

Good extension! Philosophy seems quite similar to the one I proposed some time ago... :)
I assume the .tdb file (and the world files) have also to be modified?

#7 User is offline   roeter 

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

Posted 31 May 2014 - 11:38 AM

View PostCsantucci, on 31 May 2014 - 11:03 AM, said:

But I assume the .tdb file (and the world files) have also to be modified?


If you properly alter the MSTS (original) sigcfg.dat file, such that the new signals you want are defined here as well (obviously without the OR specific functions), you can add the signals (or replace existing signals) using the MSTS route editor.
In that case there is no need to modify .tdb or worldfiles. The .tdb file references the SignalType name, the world files reference the SignalShape. The actual functions are derived from the sigcfg.dat file through these references, and so will automatically now load the OR specific functions.

If you simply want to add the new signalscript functions to existing signals there is even no need to edit these in the route editor.

Regards,
Rob Roeterdink

#8 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 02 June 2014 - 06:58 AM

Hi, I have one question. Fixes a bug in the new signaling multiplayers?
When I control lights do not work manually so as to have something new patch?

http://s26.postimg.org/ppsyphwt1/screen_1.jpg

http://s26.postimg.org/w283zbzv9/screen_2.jpg

#9 User is offline   roeter 

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

Posted 02 June 2014 - 08:30 AM

No, there are no changes to behaviour of signalling in multiplayer.

Regards,
Rob Roeterdink

#10 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 02 June 2014 - 08:32 AM

a will? or I have to go elsewhere?

  • 8 Pages +
  • 1
  • 2
  • 3
  • Last »
  • 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