23.2 Dossiers utilisés par Open Rails

Les dossiers suivants sont également écrits par Open Rails.

(Dans ce tableau, nous supposons un utilisateur appelé Joe.)

23.3 Fonctions des signaux

Il s'agit d'un aperçu des fonctions disponibles dans OR pour une utilisation dans des scripts de signal, appelées fonctions SIGSCRIPT.

23.3.1 Fonctions MSTS d'origine

Voici les fonctions MSTS de base :

BLOCK_STATE

ROUTE_SET

NEXT_SIG_LR

NEXT_SIG_MR

THIS_SIG_LR

THIS_SIG_MR

OPP_SIG_LR

OPP_SIG_MR

DIST_MULTI_SIG_MR

SIG_FEATURE

DEF_DRAW_STATE

23.3.2 Fonctions MSTS étendues

Les éléments suivants sont des extensions des fonctions MSTS de base.

NEXT_NSIG_LR(SIGFN_TYPE, N)

Extension de NEXT_SIG_LR

Renvoie l'état du Nième signal de type SIGFN_TYPE. Notez que l'état SIGASP_STOP est renvoyé si un quelconque signal intermédiaire de type SIGFN_TYPE est mis à cet état.

DIST_MULTI_SIG_MR_OF_LR(SIGFN_TYPE, SIGFN_ENDTYPE)

Extension de DIST_MULTI_SIG_MR

Le DIST_MULTI_SIG_MR d'origine excluait toutes les têtes pour lesquelles le lien (route_set) n'était pas valide. Toutefois, lorsque les signaux sont acheminés via des signaux de définition d'itinéraire plutôt que via des liaisons, cette exclusion échoue et, par conséquent, la fonction ne renvoie pas l'état correct. Cette fonction étendue vérifie toutes les têtes requises sur chaque signal et utilise l'aspect le moins restreint sur ce signal comme état pour ce signal. Il retourne l'état le plus restrictif des états ainsi déterminés pour chaque signal intermédiaire jusqu'à ce qu'un signal de type SIGFN_ENDTYPE soit trouvé.

23.3.3 Fonctions SIGNAL IDENT

Lorsqu'une fonction est appelée et nécessite des informations sur un signal suivant, une recherche est effectuée le long de l'itinéraire du train pour localiser le signal requis. Si plusieurs informations sont requises à partir de ce signal, et par conséquent plusieurs fonctions sont appelées nécessitant ce signal suivant, une telle recherche est effectuée pour chaque appel de fonction.

Ce processus peut être rendu beaucoup plus efficace en utilisant l'identificateur de signal du signal requis. Chaque signal d'un itinéraire a un identifiant unique. Un ensemble de fonctions est disponible pour obtenir l'identificateur de signal du signal requis. Des fonctions équivalentes aux fonctions de signal normales sont également disponibles, mais utilisent l'identificateur de signal et n'effectuent pas de recherche du signal requis. Évidemment, en utilisant ces fonctions, il faut vérifier que l'identifiant du signal récupéré est valide (c'est-à-dire qu'un signal valide est trouvé), et l'intégrité de la variable

la tenue de cet ident doit être assurée (la valeur ne doit jamais être modifiée).

Les fonctions suivantes sont disponibles pour obtenir l'identificateur de signal requis. Les fonctions renvoient l'identificateur de signal pour le signal tel qu'il a été trouvé. Si aucun signal valide n'est trouvé, la valeur -1 est renvoyée.

NEXT_SIG_ID(SIGFN_TYPE)

Renvoie l'identificateur de signal du signal suivant de type SIGFN_TYPE.

NEXT_NSIG_ID(SIGFN_TYPE, N)

Renvoie l'identificateur de signal du Nième signal de type SIGFN_TYPE.

OPP_SIG_ID(SIGFN_TYPE)

Renvoie Signal Ident signal suivant de type SIGFN_TYPE dans la direction opposée.

Les fonctions suivantes sont équivalentes aux fonctions de base mais utilisent Signal Ident pour identifier le signal requis.

ID_SIG_ENABLED(SigID)

Renvoie 1 si le signal identifié est activement activé (c'est-à-dire qu'un train a dégagé un itinéraire menant à ce signal)

ID_SIG_LR(SigId, SIGFN_TYPE)

Renvoie l'aspect le moins restreint des têtes de type SIGFN_TYPE du signal identifié.

Notez qu'il existe d'autres fonctions qui utilisent également l'identificateur de signal comme détaillé ci-dessous.

23.3.4 Fonctions du sous-objet Signal

Dans la définition de signal MSTS d'origine, un certain nombre de sous-objets de signal spécifiques pourraient être utilisés comme indicateurs (USER_1 . . . USER_4). D'autres éléments (NUMBER_PLATE et GRADIENT) pouvaient également être utilisés comme indicateur mais étaient liés à des éléments physiques sur le signal. Le nombre de drapeaux ainsi disponibles était très restreint. Dans OU, une fonction supplémentaire a été créée qui peut vérifier pour n'importe quel sous-objet de signal si ce sous-objet est inclus pour ce signal particulier ou non. Cette fonction peut être utilisée sur tout type de sous-objet Signal.

En définissant des sous-objets de type 'DECOR', des drapeaux supplémentaires peuvent être définis pour tout type de signal. Les sous-objets définis de cette manière n'ont pas besoin d'être définis physiquement dans le fichier de forme. Les informations sont disponibles au niveau du signal, de sorte que toutes les têtes sur un signal peuvent utiliser ces informations. La fonction utilise le numéro de sous-objet pour identifier le sous-objet requis, le nom du sous-objet n'est pas pertinent. Le maximum de sous-objets totaux pour n'importe quelle forme est de 32 (n° 0 . . . 31), ceci inclut les têtes de signal réelles.

HASHHEAD(N)

Renvoie 'true' (1) si SubObject avec le numéro N est disponible sur ce signal.

23.3.5 Approach Control Functions

Le contrôle d'approche est une méthode utilisée dans certains systèmes de signalisation qui maintient un signal en danger jusqu'à ce que le train qui approche soit à une distance spécifique du signal ou ait réduit sa vitesse en dessous d'une certaine limite. Cette fonctionnalité est utilisée dans les situations où une réduction significative de la vitesse est requise pour le train qui approche, et le maintien du signal en danger garantit que le train a effectivement réduit sa vitesse à proximité ou en dessous de la limite requise.

L'ensemble suivant de fonctions de contrôle d'approche est disponible en OR.

La distance et la vitesse requises peuvent être définies comme des constantes (les dimensions sont m et m/s, ces dimensions sont fixes et ne dépendent d'aucun réglage d'itinéraire).

Il est également possible de définir la distance ou la vitesse requise dans la définition du type de signal dans sigcfg.dat. Les valeurs ainsi définies peuvent être récupérées à l'aide des variables prédéfinies Approach_Control_Req_Position et Approach_Control_Req_Speed.

APPROACH_CONTROL_POSITION(APPROACH_CONTROL_POSITION)

Le signal sera maintenu en danger jusqu'à ce que le train ait atteint la distance devant le signal comme défini. Le signal sera également maintenu en danger s'il n'est pas le premier signal devant le train, même si le train se trouve à la distance requise.

APPROACH_CONTROL_POSITION_FORCED(APPROACH_CONTROL_POSITION)

Le signal sera maintenu en danger jusqu'à ce que le train ait atteint la distance devant le signal comme défini. Le signal s'effacera également même s'il ne s'agit pas du premier signal devant le train.

APPROACH_CONTROL_SPEED(APPROACH_CONTROL_POSITION,

APPROACH_CONTROL_SPEED)

Le signal sera maintenu en danger jusqu'à ce que le train ait atteint la distance devant le signal comme défini et que la vitesse ait été réduite en dessous de la limite requise. La limite de vitesse peut être fixée à 0, auquel cas le train doit s'arrêter devant le signal avant que le signal ne soit effacé. Le signal sera également maintenu en danger s'il n'est pas le premier signal devant le train, même si le train se trouve à la distance requise.

APPROACH_CONTROL_NEXT_STOP(APPROACH_CONTROL_POSITION,

APPROACH_CONTROL_SPEED)

Parfois, un signal peut avoir un contrôle d'approche mais le signal peut être maintenu en danger si le signal suivant n'est pas autorisé. Normalement, si un signal est maintenu pour le contrôle d'approche, il ne propagera pas la demande de signal, ce qui signifie que le prochain signal ne sera jamais effacé. Cela pourrait conduire à un blocage du signal, le premier signal étant maintenu pour le contrôle d'approche et, par conséquent, le signal suivant ne peut pas être dégagé. Cette fonction est spécifiquement destinée à cette situation. Il permettra la propagation de la demande de dégagement même si le signal est maintenu en danger pour le contrôle d'approche, permettant ainsi au prochain signal de se dégager. Le fonctionnement de cette fonction est similaire à APPROACH_CONTROL_SPEED.

APPROACH_CONTROL_LOCK_CLAIM()

Si un signal devant un train est tenu en danger, le train peut réclamer des sections au-delà de ce signal afin d'assurer une voie libre à partir de ce signal dès que possible. Si cette fonction est appelée dans une séquence de script qui définit également un contrôle d'approche actif, aucune réclamation ne sera faite pendant que le signal est maintenu pour le contrôle d'approche.

23.3.6 Fonctions CallOn

Les fonctions CallOn permettent aux trains de se diriger vers une section de voie déjà occupée par un autre train. Les fonctions CallOn ne doivent pas être confondues avec les signaux « permissifs » souvent utilisés dans les systèmes de signalisation nord-américains.

Un signal « permissif » permettra toujours à un train de continuer sur une voie occupée, à la suite d'un train précédent. De tels signaux ne sont généralement utilisés que dans des situations où un signal ne couvre qu'une section de «ligne libre», c'est-à-dire une section de voie sans aiguillage ni croisement, etc.

L'installation CallOn, d'autre part, ne permettra au train de continuer que dans certaines situations spécifiques et est principalement utilisée dans les gares et les zones de triage.

Les fonctions CallOn sont spécifiquement destinées à être utilisées en mode horaire et sont directement liées à un certain nombre de commandes d'horaire. Les trains seront autorisés à continuer sur la base de ces commandes.

Fonctions CallOn en mode horaire

Les conditions suivantes permettront à un train de continuer.

• L'itinéraire au-delà du signal mène à un quai et le paramètre $callon est défini pour l'arrêt de gare associé.

• Le train a une commande $attach, $pickup ou $transfer définie pour un arrêt en gare ou dans le champ #dispose, et le train dans la section au-delà du signal est statique ou est le train référencé dans la commande (le cas échéant) . Si la commande est définie pour un arrêt en gare, l'itinéraire au-delà du signal doit déboucher sur un quai attribué à cette gare. Si la commande est définie dans le champ #dispose, il n'y a pas d'autres conditions.

• L'action train fait partie d'une commande $stable dans le champ #dispose.

• L'itinéraire au-delà du signal est un chemin de Stockage de Groupe, et le train est réservé pour être stocké dans ce groupe.

CallOn peut également être autorisé si la route ne mène pas à une plate-forme en fonction de l'appel de fonction.

Fonctions CallOn en mode activité

CallOn n'est jamais autorisé si la route au-delà du signal mène à une plate-forme. CallOn peut être autorisé dans d'autres emplacements en fonction de l'appel de fonction réel.

Fonctions disponibles

TRAINHASCALLON()

TRAINHASCALLON_RESTRICTED()

Ces fonctions sont similaires, sauf que TRAINHASCALLON autorisera toujours CallOn si l'itinéraire ne mène pas à un quai, et agit donc comme un signal "permissif" dans cette situation. La fonction TRAINHASCALLON_RESTRICTED n'autorisera CallOn que lorsque l'un des critères est rempli, comme indiqué ci-dessus.

23.3.7 Fonctions SignalNumClearAhead

La valeur SignalNumClearAhead (SNCA) définit le nombre de signaux devant lesquels un signal devra être effacé afin de pouvoir montrer l'aspect le moins restrictif requis. La valeur est définie comme une constante pour chaque type de signal spécifique dans le fichier sigcfg.dat. Cependant, il se peut que certaines options de signal nécessitent que cette valeur soit modifiée. Par exemple, un type de signal qui peut éventuellement afficher un aspect d'approche avancée nécessite une valeur plus élevée pour SNCA au cas où cette approche avancée serait requise. Cela peut même dépendre de la

l'itinéraire défini à partir de ce signal. En OR, des fonctions sont disponibles pour ajuster la valeur de SNCA selon les besoins, ce qui évite d'avoir à toujours définir la valeur la plus élevée possible, ce qui pourrait conduire à un signal de dégagement d'un itinéraire trop loin devant. Notez que ces fonctions utilisent toujours la valeur par défaut de SNCA telle que définie dans sigscr.dat comme valeur de départ. Des appels répétés de ces fonctions ne conduiront pas à des valeurs invalides ou absurdes pour SNCA.

INCREASE_SIGNALNUMCLEARAHEAD(n)

Augmentez la valeur de SNCA de n, en partant de la valeur par défaut.

DECREASE_SIGNALNUMCLEARAHEAD(n)

Diminuez la valeur de SNCA de n, en partant de la valeur par défaut.

SET_SIGNALNUMCLEARAHEAD(n)

Définissez la valeur de SNCA sur n.

RESET_SIGNALNUMCLEARAHEAD()

Réinitialisez la valeur de SNCA à la valeur par défaut.

23.3.8 Variables de signalisation locales

À l'origine, le seul moyen d'interfaçage entre les signaux, ou entre les têtes de signal au sein d'un signal, passe par les états d'aspect du signal. Cela définit une restriction sévère de la quantité d'informations pouvant être transmises entre les signaux ou les têtes de signal.

En RO, des variables de signal locales ont été introduites. Ces variables sont spécifiques à un signal. Les variables sont persistantes, c'est-à-dire qu'elles conservent leur valeur d'une mise à jour à l'autre. Étant donné que les variables sont attribuées par signal, elles sont disponibles pour toutes les têtes de signal qui font partie de ce signal. Les variables sont également accessibles par d'autres signaux.

Chaque tête de signal qui fait partie d'un signal peut accéder aux variables à la fois pour la lecture et l'écriture.

Chaque tête de signal des autres signaux peut accéder aux variables en lecture uniquement.

Chaque variable est identifiée par un nombre entier. Les variables ne peuvent contenir que des valeurs entières.

MAGASIN_LVAR(IDENT, VALEUR)

Définit la variable identifiée par IDENT sur VALUE. La fonction n'a pas de valeur de retour.

THIS_SIG_LVAR(IDENT)

Renvoie la valeur de la variable identifiée par l'IDENT de ce signal.

NEXT_SIG_LVAR(SIGFN_TYPE, IDENT)

Renvoie la valeur de la variable identifiée par IDENT du premier signal devant le type SIGFN_TYPE.

Si aucun signal de ce type n'est trouvé, la fonction renvoie la valeur 0.

ID_SIG_LVAR(SIGID, IDENT)

Renvoie la valeur de la variable identifiée par IDENT du signal identifié par l'identificateur de signal SIGID.

23.3.9 Fonctions pour le sous-type de tête normale

Bien qu'il puisse y avoir différents types de signaux, et OR permet la définition et l'ajout de n'importe quel nombre de types, seuls les signaux de type NORMAL affecteront les trains.

Certains systèmes de signalisation, cependant, ont différents types de signaux, par ex. signaux principaux et shunt, qui nécessitent un comportement différent ou une réponse différente. Afin de pouvoir distinguer ces signaux, OR a introduit un sous-type qui peut être défini pour un signal NORMAL.

Le sous-type peut être défini pour n'importe quel signal dans le fichier sigcfg.dat, de la même manière que le type de signal. Un certain nombre de fonctions sont disponibles pour interroger un signal afin d'identifier son sous-type.

THIS_SIG_HASNORMALSUBTYPE(SIGSUBTYPE)

Renvoie la valeur 1 (vrai) si ce signal a une tête de type NORMAL avec le sous-type requis.

NEXT_SIG_HASNORMALSUBTYPE(SIGSUBTYPE)

Renvoie la valeur 1 (vrai) si le signal suivant avec une tête de type NORMAL a une tête avec le sous-type requis.

ID_SIG_HASNORMALSUBTYPE(SIGIDENT, SIGSUBTYPE)

Renvoie la valeur 1 (vrai) si le signal identifié par SIFIDENT a une tête de type NORMAL avec le sous-type requis.

23.3.10 Fonctions de vérification de la libération totale ou partielle de l'itinéraire

Comme mentionné, certains systèmes de signalisation font la différence entre les signaux principaux et de dérivation (par exemple en Allemagne, au Royaume-Uni). Cela peut affecter la suppression d'un signal dans des endroits où ces deux types se produisent sur le même itinéraire. Si un train nécessite l'itinéraire complet d'un signal principal au signal principal suivant, dans des endroits où il y a des signaux de dérivation entre les deux, le premier signal principal peut ne pas s'effacer tant que l'itinéraire complet vers le signal principal suivant n'est pas disponible, et s'effacera alors pour un aspect principal. Si, toutefois, le train ne nécessite qu'un itinéraire partiel (par exemple pour une manœuvre), le signal peut disparaître dès que (une partie de) cet itinéraire est disponible, et ne s'effacera alors généralement qu'à un aspect restreint ou auxiliaire (aspect shunt).

Les fonctions de signal MSTS d'origine ne pouvaient pas prendre en charge une telle situation, car le signal serait toujours dégagé dès que la première partie de l'itinéraire deviendrait disponible, car il n'était pas possible de faire la distinction entre les différents types de signal.

En raison de l'introduction du sous-type normal comme détaillé ci-dessus, une telle configuration n'est pas possible. Un certain nombre de fonctions ont été introduites pour soutenir cela.

L'utilisation de ces fonctions est cependant assez compliquée et seule une brève description de ces fonctions est fournie dans ce document.

TRAIN_REQUIRES_NEXT_SIGNAL(SIGIDENT, REQPOSITION)

Renvoie la valeur 1 (vrai) si le train nécessite l'itinéraire complet jusqu'au signal identifié par SIGIDENT.

Si REQPOSITION est réglé sur 0, l'itinéraire est vérifié jusqu'à et y compris la dernière section avant le signal pertinent.

Si REQPOSITION est réglé sur 1, l'itinéraire est contrôlé jusqu'au premier tronçon compris immédiatement après le signal correspondant.

TROUVER_REQ_NORMAL_SIGNAL(SIGSUBTYPE)

Renvoie l'identificateur de signal du premier signal NORMAL qui a une tête avec le SIGSUBTYPE requis, ou -1 si un tel signal est introuvable.

ROUTE_CLEARED_TO_SIGNAL(SIGIDENT)

Renvoie la valeur 1 (true) si la route requise est claire et disponible.

ROUTE_CLEARED_TO_SIGNAL_CALLON(SIGIDENT)

Comme ROUTE_CLEARED_TO_SIGNAL, mais renverra également la valeur 1 (true) si l'itinéraire est disponible car le train est autorisé à faire appel.

23.3.11 Fonctions diverses

Un certain nombre de fonctions diverses qui ne font partie d'aucun des groupes détaillés ci-dessus.

ALLOW_CLEAR_TO_PARTIAL_ROUTE (RÉGLAGE)

Si l'itinéraire d'un train passant devant un signal s'arrête avant le signal suivant (aucun autre signal NORMAL n'est trouvé sur cet itinéraire), le signal correspondant ne s'effacera que si le train s'approche de ce signal, c'est-à-dire qu'il s'agit du premier signal du train. chemin.

Ce réglage peut être annulé par cette fonction.

Si SETTING est réglé sur 1, le signal s'effacera si nécessaire et l'itinéraire est disponible, même si aucun autre signal NORMAL n'est trouvé.

Si SETTING est réglé sur 0, le fonctionnement normal est restauré.

THIS_SIG_NOUPDATE()

Une fois que le signal a été traité une fois, il ne sera plus mis à jour. Ceci est utile pour les signaux fixes, par ex. en fin de voie comme les feux d'arrêt tampon, mais aussi pour les signaux fixes comme les signaux de contrôle d'itinéraire ou d'information d'itinéraire. L'appel de cette fonction dans le script pour de tels signaux exclut ces signaux des mises à jour normales, ce qui économisera du temps de traitement.

Notez que les signaux sont toujours traités une fois, donc le script sera exécuté une fois pour régler le signal sur l'état fixe requis.

COMMUTATEUR(ASPECT_STATE_0, ASPECT_STATE _1)

Fonctions spéciales pour les signaux utilisés comme commutateur. Un lien direct est établi entre le commutateur et le signal, de sorte que le signal est immédiatement mis à jour au fur et à mesure que l'état du commutateur est modifié.

Le signal sera défini sur ASPECT_STATE_0 lorsque le commutateur est défini sur la route 0 et sur ASPET_STATE_1 lorsque le commutateur est défini sur la route 1. Il n'est pas nécessaire de lier le signal aux routes du commutateur.

L'utilisation de cette fonction pour les interrupteurs élimine le retard qui peut normalement se produire entre le changement d'état de l'interrupteur et l'état du signal, en raison du traitement indépendant du signal.

Notez que le signal peut être exclu du processus de mise à jour normal car il sera mis à jour via le lien direct avec le commutateur.

23.3.12 Fonctions de temporisation

Ces deux fonctions permettent des actions temporisées sur des signaux, par ex. une temporisation fixe à l'effacement etc..

Activate_Timing_Trigger() : active un déclencheur de temporisation.

Check_Timing_Trigger(n) : vérifie le déclencheur de synchronisation et renvoie vrai s'il a été défini il y a plus de n secondes.

23.4 Ajouts spécifiques à la RO dans les fichiers SIGCFG

Ci-dessous sont détaillés les ajouts spécifiques à l'OR qui peuvent être définis dans le fichier SIGCFG pour définir des caractéristiques spécifiques ou améliorer la fonctionnalité des types de signaux.

23.4.1 Définitions générales

Les définitions générales suivantes doivent être définies avant les définitions des types de signaux, immédiatement après les définitions des textures lumineuses et des tabulations lumineuses.

23.4.2 ORTSSignalFunctions

Des types de signaux supplémentaires peuvent être définis dans OR, en plus des types de signaux MSTS standard. Les types supplémentaires doivent être prédéfinis dans le fichier sigcfg.dat à l'aide de la définition ORTSSignalFunctions.

Les types de signal ORTS définis peuvent être définis dans la définition du type de signal et utilisés dans les fonctions de script de signal de la même manière que les types MSTS par défaut.

Par défaut, une fonction de signalisation personnalisée aura le même comportement qu'une fonction de signalisation INFO : elle n'aura aucun impact sur les sections de bloc et ne pourra pas définir de limite de vitesse. Vous pouvez indiquer au simulateur de considérer une fonction personnalisée comme ayant le même comportement que l'une des fonctions de signal MSTS. Vous pouvez ajouter une fonction MSTS comme deuxième paramètre au paramètre ORTSSignalFunctionType. L'utilisation de la fonction signal NORMAL est actuellement interdite. Pour définir plusieurs types de signaux NORMAL, veuillez utiliser le paramètre ORTSNormalSubtypes.

Notez que SPEED est un type de signal fixe qui est disponible en OR sans définition explicite (voir ci-dessous pour plus de détails sur les signaux de type SPEED). Notez également que toute définition de type commençant par "OR_" ou "ORTS" n'est pas valide, ces noms sont réservés pour les futurs types par défaut dans OR.

Syntax:

ORTSSignalFunctions ( n

ORTSSignalFunctionType ( "CUSTOM_SIGNAL_FUNCTION" )

ORTSSignalFunctionType ( "CUSTOM_SPEED_SIGNAL_FUNCTION" "SPEED" )

. . .

)

Des types de signaux supplémentaires peuvent être définis dans OR, en plus des types de signaux MSTS standard. Les types supplémentaires doivent être prédéfinis dans le fichier sigcfg.dat à l'aide de la définition ORTSSignalFunctions.

23.4.3 Sous-types ORTSNormal

Comme détaillé ci-dessus, des sous-types peuvent être définis pour les signaux de type NORMAL, ce qui permet de distinguer différents utilisation de signaux de type NORMAL.

Le sous-type normal doit être prédéfini dans le fichier sigcfg.dat à l'aide de la définition ORTSNormalSubtypes.

Le sous-type peut être défini dans la définition de type pour les signaux de type NORMAL à l'aide de l'ORTSNormalSubtype déclaration, voir ci-dessous.

Le sous-type peut être utilisé dans des fonctions de script de signal spécifiques comme détaillé ci-dessus.

Syntaxe:

ORTSNormalSubtypes ( n

ORTSNormalSubtype ( "subtype" )

. . .

)

La valeur n indique le nombre total de définitions. Le sous-type de valeur est le nom du sous-type.

23.4.4 Définitions des types de signaux

La section suivante détaille OU les ajouts spécifiques à la définition du type de signal.

Paramètres de lueur

Signal Glow est une fonctionnalité de OR pour améliorer la visibilité des signaux à de plus grandes distances. Le paramètre de lueur requis peut être défini par type de signal dans la définition du signal. La valeur est un nombre réel et définit l'intensité de la lueur. La valeur 0,0 définit qu'il n'y a pas d'effet de lueur.

Les valeurs de programme par défaut pour la lueur sont :

Valeur jour = 3,0 ;

Valeur nuit = 5,0 ;

Remarques :

• Pour les types de signaux dont l'indicateur « Sémaphore » est défini, la valeur Jour = 0,0.

• Pour les signaux de type INFO et SHUNTING, les valeurs Jour et Nuit sont réglées sur 0,0 (pas de lueur).

Syntaxe:

ORTSDayGlow ( d )

ORTSNightGlow ( n )

Les valeurs d et n sont les valeurs de lueur diurne et nocturne, sous forme de nombres réels.

23.4.5 Interrupteur d'éclairage

Il y avait de nombreux systèmes de signalisation où les signaux de sémaphore ne montraient pas de lumières pendant la journée. Cet effet peut être simulé à l'aide du paramètre ORTSDayLight.

Syntaxe:

ORTSJourLumière( l )

La valeur l est une valeur logique, si elle est définie sur faux, le signal n'affichera pas de lumière pendant la journée.

23.4.6 Fonction de script

Normalement, chaque type de signal doit avoir un script de signal lié, avec le même nom que celui défini pour le type de signal. Cependant, il existe souvent une série de types de signaux dont la définition peut différer, par ex. en raison de différences dans la position des lumières, mais qui ont les mêmes scripts logiques.

Dans OR, un type de signal peut avoir une définition qui fait référence à un script particulier que ce type de signal doit utiliser. Différents types de signaux qui ont la même logique peuvent donc tous utiliser le même script. Ce script peut être défini en utilisant le nom de l'un de ces types de signaux, ou il peut avoir un nom générique non lié à un type de signal existant.

Syntaxe:

ORTSScript( nom )

Le nom de la valeur est le nom du script de signal tel que défini dans le fichier sigscr.dat.

23.4.7 Sous-type normal

Comme détaillé ci-dessus, un type de signal de type NORMAL peut avoir une définition de sous-type supplémentaire.

Syntaxe:

ORTSNormalSubtype( sous-type )

Le sous-type de valeur est le nom du sous-type et doit correspondre à l'un des noms définis dans ORTSNormalSubtypes.

23.4.8 Paramètres de contrôle d'approche

Les valeurs requises pour les fonctions de contrôle d'approche pour un type de signal particulier peuvent être définies dans la définition du type de signal. Ces valeurs peuvent être référencées dans le script de signal tel que défini pour les fonctions de contrôle d'approche.

Syntax:

ApproachControlSettings (

PositionDefinition ( position )

SpeedDefinition ( speed )

)

Définitions de poste possibles

Positionkm

Positionmiles

Positionm

Positionyd

Définitions de vitesse possibles

Speedkph

Speedmph

La position de valeur est la valeur de position requise dans la dimension telle que définie par le paramètre correspondant. La valeur de vitesse est la valeur de vitesse requise en dimension telle que définie par le paramètre correspondant. L'inclusion de la définition de la vitesse est facultative et n'a pas besoin d'être définie si seules les fonctions de position de contrôle d'approche sont utilisées.

23.4.9 Paramètres d'aspect du signal

Les paramètres suivants peuvent être inclus dans les définitions d'aspect du signal.

or_speedreset

Peut être utilisé en combinaison avec un réglage de vitesse. Sa fonction, associée au réglage de la vitesse, est la suivante.

En mode activité :

• Si elle est définie, la vitesse telle qu'elle est définie s'applique jusqu'à ce qu'elle soit annulée par un speedpost ou un signal suivant définissant une valeur de vitesse supérieure ;

• Si elle n'est pas définie, la vitesse définie s'applique jusqu'au signal suivant et ne sera pas annulée par une borne de vitesse.

En mode horaire :

• La vitesse définie s'applique toujours jusqu'à ce qu'elle soit annulée par une borne de vitesse ou un signal suivant définissant une valeur de vitesse supérieure, ce drapeau n'a aucun effet en mode horaire.

or_nospeedreduction

Pour les aspects de signal "STOP_AND_PROCEED" et "RESTRICTING", les trains réduiront la vitesse à une valeur faible à l'approche du signal. Si ce drapeau est activé, les trains sont autorisés à passer le signal à la vitesse de ligne normale.

23.4.10 Signal VITESSE



Un nouveau type de signal standard, "SPEED", a été ajouté à OR.

Les signaux définis comme type "SPEED" sont traités comme des speedposts et non comme des signaux. La limite de vitesse requise peut être définie à l'aide du paramètre de vitesse de la définition de l'aspect du signal.

Les avantages de l'utilisation des signaux « SPEED » par rapport aux speedposts sont :

• Les signaux « SPEED » peuvent être scénarisés et peuvent donc être conditionnels, par ex. une restriction de vitesse n'est définie qu'à l'approche d'un carrefour si un itinéraire restreint est défini via ce carrefour.

• Les signaux « SPEED » peuvent définir un état en fonction de leur réglage, et cet état peut être vu par un signal précédent. Cela peut être utilisé pour configurer des panneaux d'avertissement de vitesse variable.

Une tête de signal "SPEED" peut faire partie d'un signal qui contient également d'autres têtes, mais pour la clarté du fonctionnement, cela n'est pas conseillé.