Notez que ce document détaille le comportement en mode solo uniquement. Pour le mode multijoueur, des règles différentes peuvent s'appliquer.
Pour une liste complète des paramètres, voir Développement de contenu OR - Paramètres et jetons
OR a pour objectif de faire fonctionner de manière compatible la plupart des activités écrites pour MSTS.
De plus, des activités spécifiquement pour OR peuvent être créées, en utilisant les fonctions OR supplémentaires, comme Extended AI Shunting. Des discussions sur l'exécution de certaines fonctions dans ORTS et MSTS sont données ici.
Si le chemin du joueur nécessite qu'un interrupteur soit aligné dans les deux sens, l'alignement qui est le dernier sur le chemin est utilisé. Si un train IA croise le chemin du joueur avant que le train du joueur n'y arrive, le train IA laissera les aiguillages alignés pour l'itinéraire principal (le réglage par défaut pour la plupart des aiguillages)
Si vous lancez un interrupteur pour entrer dans une voie d'évitement, l'interrupteur à l'extrémité de la voie d'évitement est aligné pour vous permettre de partir lorsque votre train occupe la voie d'évitement pour la première fois. Mais après cela, il ne revient pas à son réglage d'origine. Si l'interrupteur est lancé dans l'autre sens, vous pouvez laisser le revêtement avec l'interrupteur mal aligné. Si vous désaccouplez et reconnectez le train alors qu'il occupe l'aiguillage mal aligné, l'arrière du train changera de voie.
Fonctionnalité de base de l'IA
• OU prend en charge les trains AI. Le système d'IA devient de plus en plus avancé avec de nouvelles fonctionnalités.
• OR prend en charge deux manières distinctes de contrôler les trains : il prend en charge les activités traditionnelles en compatibilité avec MSTS, et il prend également en charge le mode Horaires. Notez que diverses options et paramètres sont parfois limités au mode activité ou horaire.
• Les trains AI peuvent se rencontrer si les deux chemins ont des sections de passage définies au même endroit, ou si leurs chemins les mènent à des voies différentes à la gare de rencontre.
• Les points d'attente et les points de retour fonctionnent. Les points inverses peuvent être utilisés dans les modes Activité et Horaires, tandis que les points d'attente ne peuvent être utilisés qu'en mode Activité.
• Les trains IA déclenchent des aiguillages mal alignés avant de les engager.
• En mode activité, les trains AI peuvent effectuer des manœuvres.
• Priorités : Les trains IA doivent démarrer comme prévu tant qu'il n'y a pas d'autre train IA déjà sur un chemin de conflit.
Le mode de contrôle définit les interactions entre le joueur et le système de contrôle, ainsi que le niveau de contrôle du joueur sur les signaux et les interrupteurs. Il existe deux modes de base : le mode automatique et le mode manuel. Utilisez la touche <Ctrl+M> pour basculer entre ces modes.
En mode automatique, le système de contrôle définit la trajectoire et les signaux du train, et le joueur ne peut pas modifier le réglage des aiguillages ou demander que les signaux en danger soient dégagés. L'itinéraire du train est tiré du chemin tel que défini dans l'éditeur d'activité ou la définition d'horaire, et le système tentera d'effacer l'itinéraire devant le train conformément aux règles de signalisation et à l'interaction avec les autres trains.
Aucun itinéraire n'est autorisé dans le sens inverse car le train est supposé ne pas rouler en sens inverse. La sélection d'une cabine inversée ou la modification de la position de l'inverseur ne change pas la direction de l'itinéraire. En effet, l'itinéraire ne s'inversera qu'aux points d'inversion définis dans le sillon du train. À ces points d'inversion, l'itinéraire s'inversera automatiquement dès que le train s'arrêtera.
Si le train recule accidentellement, par ex. en raison d'un glissement ou d'un recul après dépassement d'un quai, seuls les contrôles de sécurité sont effectués pour l'extrémité arrière du train en ce qui concerne les signaux, l'alignement des aiguillages, les autres trains et l'extrémité de la voie. Il n'y a aucun contrôle des limites de vitesse derrière le train.
Le réglage des commutateurs à l'aide de la fenêtre F8 ou de <G>/<Maj+G> n'est pas autorisé. Le réglage des aiguillages à l'aide de Alt + clic gauche de la souris est possible, mais n'est pas autorisé pour les aiguillages sur la trajectoire du train. Cependant, tous les interrupteurs réglés manuellement seront automatiquement réinitialisés par un train qui approche en fonction de la trajectoire de ce train. Ainsi, en mode Auto, le train ne peut pas dévier de la trajectoire définie.
Une demande d'effacement d'un signal devant le train à l'aide de la commande Tab n'est autorisée que lorsque la voie devant est occupée par un autre train qui est à l'arrêt, et lorsque cette voie se trouve dans l'itinéraire du train. Une demande d'effacement d'un signal qui ferait dévier le train de son itinéraire n'est pas autorisée. Une demande d'effacement d'un signal derrière le train à l'aide de Shift+Tab n'est pas non plus possible.
Le mode automatique est destiné à un fonctionnement normal sous contrôle des signaux ou du contrôle de la circulation. Des mouvements de manœuvre peuvent être effectués s'ils sont entièrement définis dans la trajectoire du train, en utilisant des points d'inversion, etc.
Détails sur le mode automatique : signal automatique et nœud automatique
Il existe deux sous-modes pour le mode automatique : signal automatique et nœud automatique.
La signalisation automatique est le mode normal sur les itinéraires signalés. Le parcours du train est généralement dégagé de signal en signal. Ce n'est que dans des situations spécifiquement définies que les itinéraires peuvent être dégagés avant un signal, comme indiqué ci-dessous.
Le nœud automatique est défini lorsque le train n'a encore rencontré aucun signal, par ex. sur des itinéraires non signalés ou au début de l'itinéraire lorsqu'il n'y a pas de signal le long du trajet du train dans la mesure où il peut être dégagé - par ex. dans les triages où le train démarre mais n'a pas encore d'itinéraire clair jusqu'au premier signal.
Le nœud automatique peut également être défini si l'itinéraire à venir ne peut pas être entièrement dégagé jusqu'au prochain signal, et un dégagement partiel est autorisé.
Un certain nombre de sous-états sont définis dans Auto Node, selon la raison pour laquelle l'autorisation est terminée. Dans la liste ci-dessous, (A) indique un sous-type qui peut se produire si aucun signal n'a encore été rencontré, (B) indique un sous-type lorsqu'une route à partir d'un signal est partiellement dégagée.
Les états suivants sont possibles :
• (A) la route devant vous est dégagée jusqu'à la distance maximale pour laquelle la voie est dégagée. Le mode de contrôle est réglé sur Auto Node – Max Distance.
• (A) l'itinéraire en avant est bloqué à un aiguillage qui est aligné et occupé ou réservé par un autre train. Le mode de contrôle est défini sur Auto Node – Commutateur mal aligné.
• (A)(B – uniquement si le signal permet l'accès à la voie occupée, ou après la commande <Tab>) l'itinéraire devant est occupé par un train à l'arrêt ou un train se déplaçant dans la même direction. Le mode de contrôle est défini sur Auto Node
– Entraînez-vous à l'avance.
• Notez que, pour (A), il ne devrait pas être possible que l'itinéraire devant soit occupé par un train se déplaçant dans la direction opposée - dans ce cas, il devrait toujours y avoir un aiguillage mal aligné sur la trajectoire du train.
• Pour (B), un signal ne s'effacera jamais lorsque le train devant se déplace dans la direction opposée, et la demande de tabulation ne sera pas non plus accordée.
• (A)(B) le chemin défini du train se termine avant le signal suivant, ou il y a un point d'inversion avant le signal suivant, et il y a au moins un aiguillage entre ce point et le signal suivant. Le mode de contrôle passe à Auto Node – End of Path. Notez que s'il n'y a pas de commutation entre le point d'arrivée ou d'inversion et le signal suivant, l'itinéraire est automatiquement prolongé jusqu'au signal suivant.
• (A)(B) le train a dépassé le dernier signal avant la fin de la voie, ou le train a atteint la fin de la voie sans rencontrer aucun signal. Le mode de contrôle passe à Auto Node – End of Track.
Les changements de nœud automatique à signal automatique et vice-versa sont automatiques et ne peuvent pas être influencés par le joueur.
Il existe deux sous-modes pour le mode automatique : signal automatique et nœud automatique.
La signalisation automatique est le mode normal sur les itinéraires signalés. Le parcours du train est généralement dégagé de signal en signal. Ce n'est que dans des situations spécifiquement définies que les itinéraires peuvent être dégagés avant un signal, comme indiqué ci-dessous.
Le nœud automatique est défini lorsque le train n'a encore rencontré aucun signal, par ex. sur des itinéraires non signalés ou au début de l'itinéraire lorsqu'il n'y a pas de signal le long du trajet du train dans la mesure où il peut être dégagé - par ex. dans les triages où le train démarre mais n'a pas encore d'itinéraire clair jusqu'au premier signal.
Le nœud automatique peut également être défini si l'itinéraire à venir ne peut pas être entièrement dégagé jusqu'au prochain signal, et un dégagement partiel est autorisé.
Un certain nombre de sous-états sont définis dans Auto Node, selon la raison pour laquelle l'autorisation est terminée. Dans la liste ci-dessous, (A) indique un sous-type qui peut se produire si aucun signal n'a encore été rencontré, (B) indique un sous-type lorsqu'une route à partir d'un signal est partiellement dégagée.
Les états suivants sont possibles :
• (A) la route devant vous est dégagée jusqu'à la distance maximale pour laquelle la voie est dégagée. Le mode de contrôle est réglé sur Auto Node – Max Distance.
• (A) l'itinéraire en avant est bloqué à un aiguillage qui est aligné et occupé ou réservé par un autre train. Le mode de contrôle est défini sur Auto Node – Commutateur mal aligné.
• (A)(B – uniquement si le signal permet l'accès à la voie occupée, ou après la commande <Tab>) l'itinéraire devant est occupé par un train à l'arrêt ou un train se déplaçant dans la même direction. Le mode de contrôle est défini sur Auto Node
– Entraînez-vous à l'avance.
• Notez que, pour (A), il ne devrait pas être possible que l'itinéraire devant soit occupé par un train se déplaçant dans la direction opposée - dans ce cas, il devrait toujours y avoir un aiguillage mal aligné sur la trajectoire du train.
• Pour (B), un signal ne s'effacera jamais lorsque le train devant se déplace dans la direction opposée, et la demande de tabulation ne sera pas non plus accordée.
• (A)(B) le chemin défini du train se termine avant le signal suivant, ou il y a un point d'inversion avant le signal suivant, et il y a au moins un aiguillage entre ce point et le signal suivant. Le mode de contrôle passe à Auto Node – End of Path. Notez que s'il n'y a pas de commutation entre le point d'arrivée ou d'inversion et le signal suivant, l'itinéraire est automatiquement prolongé jusqu'au signal suivant.
• (A)(B) le train a dépassé le dernier signal avant la fin de la voie, ou le train a atteint la fin de la voie sans rencontrer aucun signal. Le mode de contrôle passe à Auto Node – End of Track.
Les changements de nœud automatique à signal automatique et vice-versa sont automatiques et ne peuvent pas être influencés par le joueur.
11.3.2 Mode manuel
Lorsqu'il est nécessaire qu'un train sorte de sa trajectoire définie, un joueur peut passer son train en mode manuel. Cela permettra au joueur de régler les commutateurs et de demander à effacer les signaux de son chemin. Cependant, il existe un certain nombre de restrictions lors de la conduite d'un train en mode manuel.
En mode manuel, un itinéraire est dégagé du train dans les deux sens, devant et derrière le train. L'itinéraire est effacé sur une distance plus courte par rapport au mode automatique et n'est jamais effacé automatiquement au-delà du premier signal. Si un train se déplace et passe un signal dans la direction opposée, l'itinéraire derrière le train se rétractera automatiquement à ce signal car il s'agit maintenant du signal suivant dans l'itinéraire inverse. Les mêmes restrictions s'appliquent en ce qui concerne les signaux en avant lorsque le train circule en marche arrière.
L'orientation de l'itinéraire ne changera pas, quelle que soit la direction dans laquelle le train circule. Il est fixé à l'orientation de l'itinéraire tel qu'il était au moment où le joueur est passé en mode manuel. Ainsi, le passage à une cabine orientée vers l'arrière ou la modification de la position de l'inverseur de la locomotive ne change pas la direction de l'orientation de l'itinéraire. Ce n'est pas une limitation au comportement du train, car les itinéraires sont toujours dégagés dans les deux sens. Cela affecte cependant l'affichage des fenêtres F4 et F8, car le sens haut/bas de ces fenêtres est lié au sens de l'itinéraire et ne changera donc pas si le train fait marche arrière. Pour aider le joueur à s'orienter dans quelle direction le train se déplace, un "œil" a été ajouté à ces affichages symbolisant la direction de la cabine, et une "flèche" a été ajoutée pour symboliser la direction de l'inverseur.
Le joueur peut régler tous les aiguillages de la trajectoire du train à l'aide de la fenêtre F8 ou des touches <G>/<Maj+G>. La touche G placera le premier aiguillage devant le train (tel que défini par la direction de l'itinéraire), Shift+G placera l'aiguillage derrière le train. Il est également possible de définir des commutateurs selon les besoins à l'aide de la commande Alt + clic gauche de la souris. Les aiguillages peuvent être réglés même s'ils se trouvent sur la voie du train et qu'un signal a été effacé sur cette voie. Les aiguillages, bien sûr, ne peuvent pas être réglés s'ils sont déjà réglés dans le cadre d'un itinéraire dégagé pour un autre train.
Les règles suivantes s'appliquent au réglage des interrupteurs :
• tous les aiguillages resteront dans la position dans laquelle ils ont été réglés par le dernier train passant sur cet aiguillage. Si aucun train n'est encore passé sur l'aiguillage, il est dans sa position par défaut.
• en mode manuel, les aiguillages arrière ne seront pas automatiquement alignés pour le train du joueur qui approche, sauf :
• lorsqu'un itinéraire est dégagé par un signal en mode manuel, tous les aiguillages de fin de trajet du train jusqu'à la fin de l'autorité (par exemple, le prochain signal) seront alignés. Notez que dans ce cas, les commutateurs de queue dans le chemin effacé par le signal ne peuvent plus être réinitialisés. Les signaux auxquels le train s'approche ne seront pas effacés automatiquement. Le joueur doit demander l'autorisation de tous les signaux rencontrés, en utilisant les touches <Tab> ou <Shift+Tab>.
La touche <Tab> effacera le signal devant le train (selon la direction de l'itinéraire), la touche <Shift+Tab> effacera le signal derrière le train. L'utilisation répétée de (<Maj> + )``<Tab>`` effacera le signal suivant au-delà du premier signal effacé, etc., mais seulement jusqu'à la distance de dégagement maximale.
Les signaux seront toujours dégagés sur demande sauf lorsque la section immédiatement derrière le signal est déjà dégagée pour un train venant de la direction opposée. Les limitations normales d'établissement d'itinéraire, etc. sont ignorées. Le signal ne passera qu'au premier aspect le plus restrictif disponible au-dessus de Stop.
Notez que, contrairement à la situation en mode Auto, comme le signal s'effacera même si l'itinéraire complet derrière le signal n'est pas disponible, un signal effacé n'est pas une indication de la distance dégagée au-delà de ce signal. Il se peut que le premier aiguillage au-delà du signal soit déjà autorisé pour un autre train. Par conséquent, en mode manuel, l'utilisation de la fenêtre F4 ou de la fenêtre Dispatcher pour vérifier la disponibilité de l'itinéraire est essentielle lors de l'exécution dans une zone avec du trafic AI.
En mode manuel, le traitement de prévention des interblocages est désactivé. En effet, les changements d'itinéraire et de direction du train susceptibles de se produire en mode manuel pourraient compromettre la stabilité du traitement des blocages. Il faut donc faire attention lors de l'utilisation du mode manuel dans une zone avec du trafic AI, en particulier sur les sections à voie unique.
Le passage du mode automatique au mode manuel peut être effectué avec le train à l'arrêt ou avec le train en mouvement. La touche <Ctrl+M> bascule entre le mode automatique et le mode manuel. Lors du passage du mode automatique au mode manuel, tous les signaux déjà effacés seront réinitialisés et de nouveaux itinéraires sont effacés devant et derrière le train sur la distance maximale si possible, ou jusqu'au premier signal.
Pour revenir du mode manuel au mode automatique, l'avant du train doit être sur le chemin défini dans l'éditeur d'activité. Si le chemin contient des points d'inversion, le train doit se trouver entre les mêmes points d'inversion que lorsqu'il est passé en mode manuel (c'est-à-dire le même sous-chemin).
Si le train se déplace dans la direction définie par le chemin, le retour en mode automatique peut être effectué pendant que le train se déplace. L'arrière du train n'a pas besoin d'être sur le chemin défini, seulement l'avant.
Si le train se déplace dans la direction opposée, il doit être à l'arrêt pour repasser en mode Auto. Si l'orientation de l'itinéraire du train a été inversée d'une manière ou d'une autre (par exemple en se déplaçant à travers une ligne de ballon ou une section en Y) et diffère de la direction dans le chemin défini, l'avant et l'arrière doivent être sur le chemin défini. Dans cette situation, l'orientation reviendra à la direction définie dans le chemin.
Il s'agit d'un mode spécial. Normalement, le train du joueur ne devrait pas être dans ce mode. Le mode hors de contrôle est activé lorsque le joueur enfreint une règle de sécurité. Ces incidents sont :
• lorsque le train joueur passe un signal de danger (SPAD) ;
• lorsque le train du joueur passe sur un aiguillage mal aligné ;
• lorsque le train du joueur dépasse la fin du sillon autorisé.
Ces actions placeront le train du joueur en mode hors de contrôle. Dans cette situation, le frein d'urgence est activé et maintenu jusqu'à l'arrêt du train. Le joueur n'a aucun contrôle sur son train jusqu'à ce qu'il soit à l'arrêt.
Une fois le train à l'arrêt, le joueur peut passer en mode manuel pour tenter de revenir à une situation correcte (ex. : revenir devant le signal en danger, cheminement autorisé etc.). Une fois qu'une situation normale a été restaurée, le joueur peut revenir en mode automatique. Si l'action a conduit le train du joueur sur une section de voie déjà dégagée pour un autre train, ce train est également arrêté.
Lorsque OU est démarré en mode explorateur au lieu d'une activité, le train est défini sur le mode explorateur. Le joueur a un contrôle total sur tous les commutateurs. Les signaux s'effaceront normalement mais les signaux peuvent être effacés sur des routes qui ne sont normalement pas disponibles en utilisant les commandes <Tab> ou <Maj+Tab>.
Tous les trains dégagent leur propre chemin. En mode Auto Signal, une partie de cette fonction est transférée aux signaux.
En mode Auto Node, les trains dégageront leur chemin jusqu'à 5000 mètres, ou la distance parcourue en 2 minutes à la vitesse maximale autorisée, selon la plus grande. En mode Auto Signal, le nombre de signaux effacés devant le train est tiré de la valeur du paramètre SignalNumClearAhead tel que défini dans le fichier sigcfg.dat pour le premier signal devant le train.
En mode manuel, la distance dégagée est de 3000 mètres maximum, ou limitée par des signaux.
Les distances en mode Explorer sont similaires à celles en mode Auto.
Si un train est arrêté à un signal, il peut réclamer la voie devant lui en s'assurant qu'il aura la priorité comme prochain train sur cette section, mais pour éviter le blocage inutile d'autres itinéraires possibles, aucune réclamation n'est faite si le train devant est également arrêté.
Aucune distinction n'est faite entre les types de train et il n'y a pas de règles de priorité.
Lorsqu'un train est démarré, il vérifiera sa trajectoire par rapport à tous les autres trains (y compris ceux qui n'ont pas encore démarré). Si une section est trouvée sur laquelle ce train et l'autre train sont dus dans des directions opposées, les limites de cette section commune totale sont déterminées et des pièges à blocage sont installés à ces limites, pour chaque train dans la direction appropriée. Ces limites sont toujours des nœuds de commutation. Lorsqu'un train passe un nœud qui a un piège de blocage pour ce train, le piège est déclenché. Lorsqu'un train s'approche d'un nœud qui a un blocage actif, il s'arrêtera à ce nœud, ou au dernier signal devant lui s'il y en a un. Ce train déclenchera désormais également ses pièges à impasse et réclamera la totalité de la section commune de cette impasse pour s'assurer qu'il sera le prochain train autorisé sur cette section. Les pièges d'interblocage sont supprimés lorsqu'un train passe le nœud d'extrémité d'une section d'interblocage.
Lorsqu'un train est démarré et que le sillon du train comprend un ou plusieurs points d'inversion, les blocages ne sont vérifiés que pour la partie du sillon jusqu'au premier point d'inversion. Lors de l'inversion, les interblocages sont vérifiés pour la partie suivante, etc.
Les pièges de blocage sont supprimés lorsqu'un train passe en mode manuel. Lorsque le train repasse en mode Auto, la vérification d'interblocage est à nouveau effectuée.
Il n'y a pas de contrôle de blocage en mode explorateur car il n'y a pas de trains IA lorsqu'ils fonctionnent dans ce mode.
Si un chemin alternatif est défini (à l'aide de la définition du chemin de passage dans l'éditeur d'activité MSTS) et que le train définit un itinéraire vers le nœud de départ de ce chemin alternatif, il vérifiera si un blocage est défini pour le nœud d'extrémité associé. Si c'est le cas, et que le chemin alternatif est libre, il empruntera le chemin alternatif, permettant à l'autre train d'utiliser le chemin principal. Si le chemin alternatif est déjà occupé, le train attendra avant le nœud où le chemin commence (ou le dernier signal devant, le cas échéant); ceci afin d'éviter de bloquer les deux voies, ce qui laisserait le train opposé nulle part où aller.
Autres règles d'utilisation des chemins alternatifs :
• Les trains dans les deux sens doivent avoir le même chemin principal à travers la zone.
• Si un seul train a un sillon alternatif défini et que les trains doivent passer, ce train utilisera toujours le sillon alternatif ; l'autre train utilisera toujours le chemin principal, quel que soit le train qui arrive en premier.
• Si les deux trains ont un chemin alternatif défini et que les trains doivent passer, le premier train à libérer son itinéraire empruntera le chemin alternatif. Notez qu'il n'est pas toujours nécessaire que ce soit le premier train à arriver - il se peut que le train qui se dégage le premier prenne beaucoup plus de temps pour se rendre réellement à la boucle de dépassement.
Si un point d'inversion est défini, le chemin sera prolongé au-delà de ce point jusqu'à la fin de la section, c'est-à-dire jusqu'au prochain aiguillage ou signal ou jusqu'à la fin de la voie.
Le point de divergence est déterminé - il s'agit du nœud de commutation où la route inverse diverge de la route entrante. À partir de ce point, une recherche est effectuée pour le dernier signal faisant face à la direction inverse qui est situé de telle sorte que le train complet s'insère entre le signal et la fin du chemin. S'il y a un tel signal, cela deviendra le point de divergence. Pour qu'un train puisse faire marche arrière, l'arrière du train doit être dégagé de ce point de divergence.
L'inversion pour les trains AI se produit comme dans MSTS ; c'est-à-dire lorsque la première voiture du train AI atteint le point d'inversion. Si à ce point l'arrière du train n'a pas encore franchi le point de divergence, l'inversion a lieu plus tard, lorsque le point de divergence est franchi.
Pour les trains de joueurs, l'inversion peut avoir lieu à partir de 50 mètres avant le point d'inversion à condition que le point divergent soit dégagé. La couleur de l'icône du point d'inversion dans le TrackMonitor est verte si le point divergent a été effacé (ce qui signifie que le train du joueur peut déjà faire demi-tour, même s'il n'a pas encore atteint le point d'inversion), alors qu'elle est blanche dans le cas contraire. (ce qui signifie que le train du joueur doit avancer plus loin vers le point de divergence, l'atteignant éventuellement si la couleur ne passe pas au vert, avant de revenir).
Comme dans MSTS, des points d'inversion doubles peuvent être utilisés pour mettre un signal au rouge après ces points d'inversion. Cependant, des points d'attente sont recommandés pour cela, comme expliqué dans le paragraphe suivant.
Des points d'attente (WP) fixés dans un sillon utilisé par un train AI sont régulièrement respectés par le train, et exécutés lorsque la tête du train atteint le WP.
Contrairement au MSTS, les points d'attente n'influencent pas la longueur du chemin réservé, sauf lorsque le WP est suivi d'un signal dans la même section de voie (pas de nœuds - c'est-à-dire de commutateurs - entre les deux).
Les WP placés dans un chemin utilisé par un train de joueur n'ont aucune influence sur la circulation du train, sauf - encore une fois - lorsque le WP est suivi d'un signal dans la même section de voie. Dans de tels cas, pour les trains AI et le train des joueurs, le signal est mis au rouge lorsque le train s'approche du WP.
Pour les trains AI, le signal revient au vert (si les conditions de bloc après le signal le permettent) une seconde après l'expiration du WP.
Pour les entraînements de joueurs, le signal revient au vert 5 secondes après l'expiration du WP.
S'il y a plus de WP dans la section de voie où réside le signal, seul le dernier influence le signal. Les points d'attente ne peuvent pas être utilisés en mode Horaire.
Les points d'attente avec un temps d'attente compris entre 30000 et 32359 sont interprétés comme des points d'attente horaires absolus, au format 3HHMM, où HH et MM sont l'heure et la minute du jour en notation décimale standard.
Si le train AI atteindra le WP avant cette heure de la journée, le WP expirera à HH:MM. Si le train AI atteint le WP plus tard, le WP sera déjà expiré. Ce type de WP peut également être utilisé en conjonction avec un signal dans la même section de voie, comme expliqué dans le paragraphe précédent.
Encore une fois, de tels points d'attente n'auront pas d'effet sur un train de joueur s'il n'y a pas de signal dans la même section ; si au contraire il y a un signal, il restera rouge jusqu'à ce que le WP ait expiré.
Les points d'attente absolus sont un moyen confortable de synchroniser et de programmer l'exploitation des trains.
Si l'option Expérimentale Rouge forcé aux arrêts en gare a été sélectionnée, et s'il y a un signal au bout d'un quai, ce signal sera maintenu en danger jusqu'à 2 minutes avant le départ réservé. Si l'arrêt en gare dure moins de 2 minutes, le signal s'effacera lorsque le train s'arrêtera. Cela s'applique à la fois aux trains IA et aux trains de joueurs.
Cependant, si la longueur du quai est inférieure à la moitié de la longueur du train, le signal ne sera pas maintenu mais s'effacera normalement pour permettre au train de se positionner correctement le long du quai. Les signaux qui ne protègent que la voie ordinaire ne seront pas non plus retenus.
Dans certains systèmes de contrôle ferroviaire, les trains ne reçoivent pas de rouge au signal de départ de la gare lorsqu'ils doivent s'arrêter dans cette gare. Dans ces cas, l'option ci-dessus doit être désactivée.
Les limites de vitesse qui augmentent la vitesse autorisée, telles que fixées par les speedposts ou les signaux, ne deviennent valides que lorsque l'arrière du train a dégagé la position du speedpost ou du signal.
Lorsqu'une limite de vitesse définie par un signal est inférieure à la limite de vitesse définie par le dernier speedpost, la limite de vitesse est définie sur la valeur inférieure. Cependant, lorsqu'une limite de vitesse définie par un signal est supérieure à la limite de vitesse actuelle définie par la dernière borne de vitesse, la limite dé nie par la borne de vitesse sera maintenue. Si une limite de vitesse inférieure était en vigueur en raison d'une limite fixée par un autre signal, la limite autorisée est fixée à celle définie par le speedpost.
En mode horaire, si une borne fixe une limite supérieure à celle définie par le dernier signal, la limite définie par le signal est annulée et la limite autorisée est définie sur celle définie par la borne.
En mode activité dans le cas précédent la plus basse des deux limites devient valide.
• Les trains AI circulent toujours en mode de contrôle automatique.
• Les trains AI ignoreront tout réglage manuel des aiguillages et réinitialiseront tous les aiguillages comme défini dans leur chemin.
• Les trains AI s'arrêteront dans les gares et respecteront si possible les heures de départ des gares réservées.
• Les trains AI s'arrêteront à un quai tel que le milieu du train soit au milieu du quai. Si le train est plus long que le quai, l'avant et l'arrière du train s'étendront à l'extérieur du quai. Si le quai a un signal à la fin, et que ce signal est maintenu en danger (voir plus haut), et que le train est trop long pour le quai, il s'arrêtera au signal. Mais si la longueur du train est supérieure au double de la longueur du quai, le signal ne sera pas retenu.
• Les trains AI respecteront les limitations de vitesse.
• Les trains AI s'arrêteront à un signal à environ 30 m. à court d'un signal en cas de danger en mode Horaire, et à une distance plus courte en mode activité.
• Là où les trains AI sont autorisés à suivre d'autres trains dans la même section passant des signaux d'autorisation, le train ajustera sa vitesse à celle du train devant et suivra à une distance d'env. 300 m. Si le train devant s'est arrêté, le train derrière s'arrêtera à une distance d'environ 50 m. Cependant, si le train qui précède est arrêté dans une gare et que le train qui suit est également réservé pour s'arrêter à cette gare, le train s'arrêtera derrière le premier train jusqu'à une distance de quelques mètres.
• Le contrôle des trains AI avant le début d'une activité est similaire au contrôle normal pendant une activité, sauf que la fréquence de mise à jour est réduite du taux de mise à jour normal à une seule fois par seconde. Mais toutes les règles concernant les limites de vitesse, les arrêts en gare, les impasses, l'interaction entre les trains AI (signaux, etc.) sont respectées. La position de tous les trains AI au début d'une activité est donc aussi proche que possible de ce qu'elle aurait été si l'activité avait été démarrée à l'heure de début du premier train AI.
Les chemins de croisement peuvent être utilisés pour permettre aux trains de se croiser sur des itinéraires à voie unique. Les chemins de dépassement requis sont définis par chemin de train dans l'éditeur d'activité MSTS ou dans l'éditeur de chemin ORTS natif inclus dans TrackViewer.
La version actuelle est une étape « intermédiaire » menant à un nouveau traitement complet. La structure et le traitement des données ont déjà été préparés pour la prochaine étape, lorsque des «sillons alternatifs» (pas seulement un seul chemin de passage mais plusieurs chemins à travers une certaine zone) seront définis par emplacement et non plus par train.
La version actuelle, cependant, est toujours basée sur l'activité MSTS et la définition de sillon, et est donc toujours basée sur la définition de sillons alternatifs par train.
La configuration de cette version est détaillée ci-dessous :
• Les chemins de dépassement définis pour le train du joueur sont disponibles pour tous les trains – dans les deux sens. Le chemin « traversant » du train du joueur est considéré comme le chemin « principal » à travers cet emplacement. Cela s'applique uniquement au mode Activité, car il n'y a pas de train de joueur prédéfini lors de l'exécution en mode Horaire.
• Chaque train peut avoir des définitions pour des chemins de dépassement supplémentaires, ceux-ci seront disponibles pour ce train uniquement. Notez que cela implique qu'il peut y avoir plus d'un chemin de passage par emplacement.
• Lorsque des emplacements de dépassement possibles sont déterminés pour chaque paire de trains, les longueurs des trains sont prises en considération. Un emplacement n'est "valide" comme emplacement de passage que si au moins un des trains s'inscrit dans le plus court des chemins de passage disponibles.
• L'ordre dans lequel les chemins de passage sont sélectionnés :
– Si aucun train n'arrive en sens inverse (itinéraire de passage) :
* Chemin du train.
* Chemin "principal".
* Tout chemin alternatif.
– Si un train doit croiser un autre train venant de la direction opposée (itinéraire de dépassement) :
* Chemin du train (s'il n'est pas le même que le chemin "principal").
* Chemin alternatif.
* Chemin "principal".
Cependant, dans le cas où le train ne rentre pas sur tous les sillons, pour que le premier train revendique un sillon traversant la zone, la préférence est donnée aux sillons (s'il y en a) où le train s'adaptera.
Le réglage du piège "impasse" (la logique qui empêche les trains d'emprunter une seule voie dans les deux sens) a également été modifié.
Dans l'« ancienne » version, le piège était « déclenché » alors qu'un train reprenait son chemin à travers une éventuelle zone de passage.
Cependant, cela conduit souvent à un blocage assez précoce des trains en sens inverse.
Dans cette version, le piège est «suspendu» lorsqu'un train revendique réellement son chemin dans la section à voie unique elle-même.
Un léger défaut dans cette logique est que cela peut conduire à ce que le train qui doit attendre soit affecté à la voie « principale », tandis que le train qui peut passer est dirigé sur la « boucle ». Cela peut se produire lorsque deux trains s'approchent d'une section à voie unique presque en même temps, chacun revendiquant son chemin à travers les zones de passage à chaque extrémité avant que le piège de l'impasse ne se déclenche réellement.
Si un lieu de passage contient des plates-formes et qu'il y a des trains de voyageurs qui sont réservés pour s'y arrêter, OU essaiera de localiser une plate-forme alternative sur le chemin de passage, et s'il peut la trouver, cette plate-forme remplacera la plate-forme d'origine comme plate-forme d'arrêt. Ce problème se produit uniquement si l'option de traitement du chemin de passage lié à l'emplacement a été cochée.
La sélection de ce type de chemin de dépassement avec le traitement des options expérimentales associées peut entraîner des changements considérables dans le comportement des trains sur les itinéraires à voie unique - et un comportement qui est certainement très différent de celui du MSTS.
Les trains AI terminent leur parcours là où se trouve le point final de leur chemin, comme dans MSTS. Cependant, ils terminent toujours leur course à vitesse nulle.
Si le train AI ne s'arrête pas en gare, sa vitesse maximale (sans tenir compte du signal, de la borne de vitesse et de la vitesse de l'itinéraire) est donnée par le premier paramètre MaxVelocity du fichier .con, exprimé en mètres par seconde, multiplié par le paramètre "Performance par défaut" ( divisé par 100) que l'on peut retrouver et modifier dans le MSTS AE dans l'« Editeur de services ». Ce paramètre divisé par 100 est écrit par l'AE dans le fichier .srv sous le nom « Efficacité ».
Si le train AI fait des arrêts en gare, sa vitesse maximale dépend du paramètre "Performance" pour chaque section d'itinéraire, comme on peut le voir et défini dans l'horaire du train AI (c'est-à-dire que la vitesse maximale est le produit du premier paramètre MAXVelocity par le paramètre "Performance" paramètre divisé par 100).
Cette liste de paramètres de performance est écrite (divisée par 100) par l'AE dans le bloc « Service_Definition » dans l'éditeur d'activité, à nouveau en tant que « Efficacité » (pour chaque arrêt de station).
Du lieu de départ du train AI jusqu'à la première gare, la « Performance » liée à cette gare est utilisée ; de la première station à la seconde, la « Performance » liée à la seconde station est utilisée et ainsi de suite. De la dernière station jusqu'à la fin du chemin, la "performance par défaut" mentionnée ci-dessus est utilisée. Cela correspond au comportement MSTS.
De plus, le paramètre Efficacité est également utilisé pour calculer les courbes d'accélération et de freinage.
Pour le joueur train : la limite de vitesse est la plus faible parmi :
• limite de vitesse d'itinéraire telle que définie dans le fichier .trk
• limite de vitesse du signal local
• limite de vitesse locale speedpost
• limite de vitesse temporaire locale
• Premier paramètre MaxVelocityA dans le fichier .con, s'il est supérieur à zéro et différent de 40
• limite de vitesse de la locomotive dans le fichier .eng dans les autres cas.
Pour les trains AI : la limite de vitesse est la plus faible parmi :
• limite de vitesse d'itinéraire telle que définie dans le fichier .trk
• limite de vitesse du signal local
• limite de vitesse locale speedpost
• limite de vitesse temporaire locale
• Premier paramètre MaxVelocityA dans le fichier .con, s'il est supérieur à zéro et différent de 40
• limite de vitesse de la locomotive dans le fichier .eng dans les autres cas.
• limite de vitesse d'itinéraire telle que définie dans le fichier .trk
• limite de vitesse du signal local
• limite de vitesse locale speedpost
• limite de vitesse temporaire locale
• premier paramètre MaxVelocityA dans le fichier .con, s'il est supérieur à zéro, multiplié par l'Efficacité comme expliqué :ref:ici <operation-performance>.
Le train AI est créé comme dans MSTS. Il appartient au créateur de l'activité de ne pas générer d'interblocages. La création d'un train dans une section où réside un autre train n'est possible que si le train créé n'est pas face à face avec le train existant.
Le numéro de passager de la plate-forme tel que défini par l'éditeur d'activité MSTS est lu par OU
Chaque passager a besoin de 10 secondes pour embarquer. Ce temps doit être divisé par le nombre de wagons voyageurs à l'intérieur des limites du quai. Les locomotives avec la ligne PassengerCapacity dans leur fichier .eng comptent également comme des wagons de passagers (EMU, DMU). Le critère pour dé nir si un wagon de passagers se trouve dans les limites du quai est di érent pour les trains joueurs et les trains AI. Pour les trains de joueurs, un contrôle individuel est effectué sur chaque wagon de passagers pour vérifier s'il se trouve dans les limites de la plate-forme (on suppose que c'est OK si au moins les deux tiers du wagon se trouvent à l'intérieur). Pour les trains AI, à la place, le nombre de wagons + locomotives à l'intérieur de la plate-forme est calculé, et tous, jusqu'au nombre de wagons de passagers dans le train, sont considérés comme des wagons de passagers. L'heure d'embarquement du joueur ou du train IA est ajoutée à l'heure d'arrivée réelle, donnant une nouvelle heure de départ ; cette nouvelle heure de départ est comparée à l'heure de départ prévue et la valeur la plus élevée est choisie comme heure de départ réelle.
Un train est considéré comme un train de voyageurs si au moins un wagon (ou locomotive) transporte des voyageurs.
Les trains de marchandises réels AI (0 voitures de voyageurs) s'arrêtent 20 secondes aux gares comme dans MSTS si les heures de départ prévues ne sont pas présentes. S'ils sont présents, les trains de marchandises s'arrêteront jusqu'à l'heure de départ prévue ou jusqu'à l'heure d'arrivée réelle plus 20 secondes, selon la valeur la plus élevée.
Un comportement particulier a été introduit pour les trains de plus de 10 voitures et ayant une seule voiture de voyageurs. Ce type de train a été utilisé dans MSTS pour avoir la possibilité de définir également des horaires pour les trains de marchandises. Ces trains sont gérés – comme MSTS – comme des trains de voyageurs avec les règles définies ci-dessus. Cependant une simplification pour le joueur a été introduite pour le train du joueur : si le train s'arrête avec l'unique voiture en dehors du quai, l'arrêt est toujours considéré comme valable.
Tout cela est compatible avec le fonctionnement MSTS ; seul le fait que l'heure de départ prévue est prise en compte pour les trains AI diffère, car elle est considérée comme une amélioration.
OU gère les zones de vitesse limitée définies dans les activités comme MSTS. Le début d'une zone de vitesse limitée peut être reconnu sur la fenêtre Track MonitorWindow car la vitesse maximale est affichée en rouge ; la vitesse maximale à la fin d'une zone de vitesse restreinte est indiquée en vert.
Avoir des trains AI effectuant des opérations de manœuvre garantit des activités plus intéressantes et variées. Notez que cette fonctionnalité n'est pas disponible en mode Horaires, qui propose d'autres moyens d'effectuer des manœuvres de train AI. Les fonctions de shunt supplémentaires suivantes sont disponibles :
1. Le train AI se couple à une unité statique et redémarre avec elle.
2. L'entraînement IA se couple à un joueur ou à un entraînement IA et en fait partie ; le train attelé continue sa route.
3. Le train IA se couple à un joueur ou un train IA et lui laisse ses voitures ; le train attelé et attelé continue sa route.
4. Le train IA se couple à un joueur ou un train IA et vole ses voitures ; le train attelé et attelé continue sa route.
5. Le train AI détache n'importe quel nombre de ses voitures ; la partie non couplée devient un composé statique. Avec la même fonction, il est possible de coupler n'importe quel nombre de voitures à partir d'un ensemble statique.
6. L'entraînement IA se couple à un joueur ou un entraînement IA ; le train combiné résultant parcourt une partie du trajet, puis s'arrête ; le train y est scindé en deux parties qui continuent sur leurs propres trajectoires (fonction join et split).
7. Le train AI peut obtenir la permission de passer un signal en cas de danger.
Ces fonctions sont décrites en détail ci-dessous.
Un exemple d'activité peut être trouvé dans Documentation\SampleFiles\Manual\Show_AI_shunting_enh.zip.
La conception d'activité peut être effectuée avec l'éditeur d'activité MSTS et ne nécessite pas de post-traitement des fichiers créés
.
Fonctions AI étendues 1 à 4 (elles impliquent toutes un couplage)
Il n'est pas toujours souhaité que les trains AI se couplent à d'autres trains ; par exemple. l'activité aurait pu être conçue de manière à ce que les trains circulent séparément, mais ensuite, au moment de l'exécution, ils pourraient être au même endroit au même moment en raison de problèmes de synchronisation. Dans un tel cas, il ne serait pas souhaitable que les trains se couplent. Le couplage n'est donc activé que si certaines conditions sont remplies.
En général, les règles de protection du signal s'appliquent, c'est-à-dire qu'un train AI trouvera un signal rouge si son chemin le mène directement à un autre train. Donc en général ces fonctions ne peuvent être utilisées que s'il n'y a pas de signaux entre le train de couplage et le train couplé. Cependant, cela peut être surmonté en trois modes:
• par le maître d'ouvrage, en insérant un double point d'inversion entre le signal et le train couplé (cela ne fonctionne que si le double point d'inversion n'est pas dans le tronçon de voie occupé par le train couplé).
• par le joueur, forçant le signal à l'état clair en utilisant la fenêtre du répartiteur.
• ou encore mieux, en utilisant la fonction de shunt AI étendue #7, qui est décrite plus loin, qui permet au train AI de passer un signal en cas de danger. Le couplage avec une composition statique n'est pas soumis à d'autres conditions, puisque si le concepteur de l'activité décidait que le chemin conduirait un train IA contre une composition statique, il était également souhaité que le train IA s'y couple.
Le couplage avec un autre train IA ou avec le train joueur est soumis aux conditions suivantes. Soit:
• le couplage se produit dans la dernière section de trajet du train AI de couplage, et le point final du trajet se trouve sous le train couplé ou au-delà de celui-ci dans la même section, ou
• le couplage se produit dans la dernière section avant un point inverse du train AI de couplage, et le point inverse est sous le train couplé ou au-delà de celui-ci dans la même section.
De cette manière, des couplages indésirables sont évités dans le cas où le train AI a son trajet allant dans la même direction au-delà du train couplé.
Juste après le couplage OR effectue une autre vérification pour dé nir ce qui se passe ensuite.
Dans le cas où le train couplé est statique :
• s'il y a au moins un point inverse plus loin sur le chemin ou s'il y a plus de 5 sections de voie plus loin dans le chemin, le train de couplage s'accouple avec le train statique, puis le train formé qui en résulte redémarre en suivant le chemin du train de couplage , ou
• sinon, le train d'attelage s'accouple avec le train statique et fait partie du train statique lui-même (est absorbé par lui), arrêtant le mouvement.
Dans le cas où le train couplé est un train joueur ou un train IA :
• s'il existe au moins un point de retournement sous le train d'attelage ou plus loin dans le même tronçon de voie, le train d'attelage s'accouple avec le train attelé ; à ce moment-là, il y a deux possibilités :
1. La rame attelée à la rame attelée est un wagon : dans ce cas la rame attelée laisse au train attelé toutes les voitures entre sa locomotive et la rame attelée, se découple et avance sur sa propre trajectoire (elle ne peut reculer qu'à cause conditions ci-dessus). Le train couplé suit son propre chemin.
2. La rame attelée au train attelé est une locomotive : dans ce cas le train attelé vole au train attelé tous les wagons entre la locomotive du train attelé et le train attelé, se découple et avance sur sa propre trajectoire (il ne peut que reculer en raison des conditions ci-dessus). Le train couplé suit son propre chemin.
• soit s'il n'y a pas de point inverse plus loin sur la trajectoire du train d'attelage, le train d'attelage s'accouple avec le train attelé et en fait partie (est absorbé par lui). Le train couplé suit son propre chemin.
Maintenant sur la façon de concevoir des chemins :
• Si l'on veut que le train attelé soit absorbé par le train attelé : il suffit de mettre le point final de la trajectoire du train attelé sous le train attelé ou plus loin, mais dans le même tronçon de voie.
• Si l'on veut que le train d'attelage avance plus loin dans sa trajectoire après s'être attelé au train attelé : mettre dans la trajectoire du train d'attelage un point inverse en dessous du train attelé. Si l'on veut aussi que le train d'attelage ne redémarre pas immédiatement, mais qu'il effectue une pause, il faut ajouter un point d'attente sur le trajet du train d'attelage, postérieurement au point de retour. Il est suggéré de placer le point d'attente près du point de marche arrière, et en tout cas dans le même tronçon de voie. OR exécutera le point d'attente même s'il n'est pas exactement en dessous de ce qui reste du train d'attelage après l'attelage/découplage n'est que la locomotive.
• Si le train couplé est un train AI, il doit évidemment être arrêté sur un point d'attente lorsqu'il doit être couplé par le train de couplage.
Fonction AI étendue 5 (le train AI découple n'importe quel nombre de ses voitures)
Pour désaccoupler un nombre prédéfini de voitures d'un train AI, un point d'attente spécial (WP) doit être inséré. Le format de ce point d'attente (en notation décimale) est généralement 4NNSS, où NN est le nombre de voitures devant le train AI qui ne sont PAS dételées, locomotive incluse, et SS est la durée du point d'attente en secondes.
Le format 5NNSS est également accepté. Dans ce cas, le train AI restant est formé de voitures NN (locomotives incluses) en partant de l'arrière du train. Bien sûr, il doit y avoir au moins une locomotive dans cette partie du train.
Il faut noter que « l'avant » du train AI est la partie qui se trouve à l'avant du train dans la direction réelle vers l'avant. Ainsi, si la composition a été créée avec la locomotive à la première place, la locomotive sera à l'avant jusqu'au premier point de marche arrière. À ce moment-là, "avant" deviendra la dernière voiture et ainsi de suite.
Les possibilités suivantes se présentent :
• Le train AI avance et s'arrête avec la locomotive à l'avant, et veut se désaccoupler et avancer dans la même direction : un WP au format 4NNSS est inséré là où le train AI s'arrêtera, en comptant les wagons à partir de la locomotive.
• Le train AI procède avec la locomotive à l'arrière, et veut se désaccoupler et procéder dans le sens inverse : un point inverse doit être mis au point où le train s'arrêtera, et un WP 4NNSS doit être mis séquentiellement après le point inverse, quelque part sous la partie du train qui restera avec le train, formaté comme ci-dessus. Comme le train a changé de direction au point inverse, les wagons sont à nouveau comptés à partir de la locomotive.
• La locomotive AI continue et s'accouple à une liaison lâche, et ne veut en obtenir qu'une partie : un point inverse est inséré sous la liaison libre, et un WP 4NNSS est inséré séquentiellement après le point inverse, quelque part sous la partie de la liaison. train qui restera avec le train, formaté comme ci-dessus.
Ce qui n'est PAS possible actuellement, c'est la possibilité de coupler le train IA au train du joueur ou à un autre train IA, et de lui « voler » un nombre prédéfini de voitures. Avec les fonctions actuellement disponibles, il est seulement possible de voler toutes les voitures ou de dépasser toutes les voitures. Si l'on souhaite que seulement un certain nombre de voitures soient transmises d'un train IA ou joueur à l'autre, le premier train IA doit découpler ces voitures comme décrit ci-dessus, puis avancer un peu, puis faire coupler le deuxième train IA à ces voitures.
Introduction
Rejoindre et diviser signifie que deux trains (IA ou joueur) commencent chacun à circuler sur leur propre chemin ; puis ils se rejoignent et courent couplés ensemble une partie de leur chemin, puis ils se séparent et courent plus loin chacun sur son propre chemin (dans le même sens ou dans des sens opposés).
Cela peut avoir par ex. les exemples d'application suivants :
Candidature 1 :
• une paire de locomotives d'assistance s'accouple à l'arrière ou à l'avant d'un long train ;
• le train résultant monte ;
• lorsqu'elles sont arrivées en montée, les locomotives auxiliaires se désaccouplent du train.
– si les auxiliaires étaient attelés à l'arrière de l'autre train, le train continue sa route vers l'avant, tandis que les locomotives auxiliaires redescendent.
– Si les aides étaient attelés à l'avant, les aides entreront dans une voie de garage et s'arrêteront ; le train continuera à avancer sur son chemin, et quand le train est passé, les assistants peuvent faire marche arrière et revenir en descente.
Cela signifie qu'un cycle d'assistance complet peut être simulé.
Application 2 :
• un train de voyageurs est formé de deux parties qui se rejoignent (par exemple, deux tronçons d'un TGV) ;
• le train atteint une gare intermédiaire et les deux tronçons se découplent ;
• une section emprunte la ligne principale, tandis que l'autre emprunte une ligne secondaire (cela peut arriver dans n'importe quelle direction pour les deux trains).
• Le train qui rejoint (celui qui se déplace et s'accouple à l'autre train – le train rejoint) et le train rejoint peuvent être un train IA ou un train joueur.
Développement de l'activité
1) Les deux trains commencent comme des trains séparés, se couplent et se découplent plus tard dans le jeu. Après cela, bien sûr, ces trains peuvent se coupler à d'autres trains, et ainsi de suite.
2) Le train couplé devient un train "incorporé" après couplage, c'est-à-dire qu'il n'a plus de voitures ou de locomotives (elles font toutes partie du train couplé) et est une sorte de train virtuel. Dans cette phase, il n'est pas affiché dans le HUD d'informations Dispatcher. Il reprendra vie lorsqu'une commande de découplage (automatique ou manuelle) sera émise.
3) Pour devenir un train « Incorporé », le train de couplage, s'il est de type AI, doit passer dans sa trajectoire avant de s'accoupler sur un Point d'Attente de valeur 60001 (le temps d'attente effectif est de 0 seconde) ; un tel WP n'est pas nécessaire si le train de couplage est le train du joueur.
4) Pour que le train d'attelage s'accouple à l'arrière du train attelé, il n'y a pas d'exigences particulières ; si toutefois vous souhaitez avoir des trajets très courts entre le début du train de couplage et le moment de couplage, il peut être nécessaire d'insérer quelques points d'inversion entre les deux, sinon le train pourrait s'arrêter et éviter le couplage. Ne dédaignez pas les doubles inversions : elles sont parfois le seul moyen de limiter la plage d'autorité d'un train.
5) Si le train d'attelage doit s'accoupler à l'avant du train attelé, il faut évidemment un point d'inversion pour le train d'attelage : il doit être posé quelque part sous le train attelé, voire plus bas dans le même tronçon de voie ; dans ce cas également, il peut y avoir un problème d'autorité, qui pourrait nécessiter que le train couplé ait quelques points d'inversion après le point où il attend d'être couplé.
6) Le train incorporé a son propre sillon, mais du point d'attelage au point de découplage, il doit emprunter les mêmes tronçons de voie que le sillon du train incorporant. Le train incorporé ne doit pas avoir de points d'attente ni d'arrêts en gare dans la partie commune du sillon (le train couplé peut en avoir à la place). S'il y a des inversions dans la partie de chemin commun, elles doivent être présentes dans les deux chemins.
7) Au moment du découplage, le nombre de voitures et de locomotives à découpler du train peut être différent du nombre du train d'origine.
8) Toute la partie de train à découpler doit se trouver sur le même tronçon de voie. Après découplage, le train « incorporé » redevient un train IA standard.
9) Le découplage manuel (pour les trains de joueurs) se produit à l'aide de la fenêtre F9 ; le découplage automatique se produit avec les commandes 4NNSS et 5NNSS (voir paragraphe précédent) ; le premier doit être utilisé lorsque la partie à découpler est à l'arrière du train, et le second lorsque la partie est à l'avant du train.
10) Dans le cas standard où la partie principale du train continue dans le même sens, les cas suivants peuvent se présenter :
• Si la partie découplée est à l'avant, cette partie découplée ne peut avancer que plus loin dans le même sens (en avant de la partie principale du train). Pour éviter qu'il ne démarre immédiatement après le découplage, il est judicieux de fixer un WP de quelques dizaines de secondes sur la trajectoire du train découplé. Ce WP peut être défini au début de la section où se produit le découplage ; OU le déplacera sous la partie découplée, vous n'avez donc pas besoin d'être précis pour le positionner.
• Si la partie découplée est à l'arrière, deux cas sont possibles : soit la partie découplée recule, soit la partie découplée continue dans le même sens. Dans le premier cas, un point d'inversion doit être placé n'importe où dans la section où le découplage se produit (mieux vers la fin de la section), et OU le déplacera au bon endroit pour que le train s'inverse au point où le découplage s'est produit ; de plus il est également conseillé de mettre un WP de quelques dizaines de secondes, afin que le train ne redémarre pas tout de suite. Ce WP doit être situé logiquement après le point de retournement, et dans le même tronçon de voie ; OU le déplacera sous le train découplé.
• Si la partie découplée continue dans la même direction, ni WP ni RP ne sont nécessaires. Cette partie du train attendra que la partie devant dégage le chemin avant de commencer.
Conseils d'exécution d'activité
• Lorsque vous courez en tant que joueur, vous devez dételer le train à l'endroit prévu par l'activité (le train dételé doit se trouver dans une section d'itinéraire présente sur son parcours). Si vous ne vous désaccouplez pas sur un tronçon de voie présent sur la trajectoire du train découplé, le train découplé deviendra un train statique, car il n'est pas sur sa trajectoire.
• Vous pouvez faire rouler le train formé par le train d'origine plus le train incorporé depuis n'importe quelle cabine (également dans une cabine du train incorporé). Cependant avant de désaccoupler (séparer) les trains, vous devez retourner dans une cabine du train d'origine.
Fonction 7 (Autorisation de passer le signal en cas de danger pour le train AI)
Pendant le shunt du train AI, il y a des cas où il est nécessaire que le train AI soit conditionnellement capable de passer un signal rouge, de la même manière que le joueur s'entraîne lorsqu'il appuie sur TAB.
Ceci peut être accompli en définissant un WP spécifique avec la valeur 60002 à établir dans le sillon AI avant le signal à franchir (dans la section de voie juste devant le signal).
Pour les développeurs de contenu
OR gère les signaux tels que définis dans les fichiers sigcfg.dat et sigscr.dat d'une manière hautement compatible avec MSTS. Une description de leur contenu et un modificateur de commentaire ces deux fichiers sont contenus dans le document Word How_to_make_Signal_config_and_Script_files.doc qui se trouve dans le dossier TECH DOCS d'une installation MSTS. Notez que ces fichiers doivent être édités avec un éditeur de texte Unicode.
De plus, une interface de script C# est disponible pour compléter le fichier sigscr.dat` pour les systèmes plus complexes.
Des règles spécifiques s'appliquent toutefois au paramètre sigcfg.dat SignalNumClearAhead(), qui n'est pas géré de manière cohérente par MSTS.
Dans ce paragraphe, le cas standard est expliqué, où sigcfg.dat et sigscr.dat sont situés à la racine de la route.
Si, pour un SignalType, un seul SignalNumClearAhead() est défini (comme c'est le cas dans les fichiers MSTS), alors ce paramètre dénit le nombre de têtes de signal NORMAL (pas de signaux !) qui sont effacées sur la route , y compris les têtes de signal du signal où réside le SignalType. Ce n'est pas exactement comme dans MSTS, où des calculs assez complexes et étranges sont effectués, et dans certains cas, cela pourrait conduire à la suppression de trop peu de signaux pour une exploitation satisfaisante du train. De plus, MSTS ne considère pas le SignalNum-
ClearAhead () valeur liée au signal, mais le maximum SignalNumClearAhead () rencontré dans les types de signaux utilisés dans la route. Par conséquent, si l'on souhaite que OU approche l'opération MSTS, la valeur de SignalNumClearAhead() de tous les signaux doit être fixée à la même valeur maximale. Pour éviter d'affecter également le fonctionnement du MSTS, il existe deux approches qui sont décrites ci-dessous.
Si, pour un SignalType, un deuxième paramètre SignalNumClearAhead() est ajouté juste avant celui existant, OU l'interprète comme le nombre de SIGNAUX NORMAUX qui sont effacés sur la route, y compris le signal où réside le SignalType.
MSTS ignorera ce premier SignalNumClearAhead() et ne considérera que le second. Ainsi, cette modification apportée à sigcfg.dat n'affecte pas son utilisation dans MSTS.
Cependant, au lieu de modifier la copie du fichier sigcfg.dat résidant à la racine de la route, l'approche décrite dans le paragraphe suivant est recommandée.
En copiant simplement les sigscr.dat et sigcfg.dat d'origine dans un sous-dossier nommé OpenRails créé dans le dossier principal de la route, OU ne considérera plus la paire de fichiers située dans le dossier racine de la route, et interprétera le (seul) SignalNumClearAhead () comme dé nissant le nombre de signaux effacés. Donc OU interprète sigscr.dat d'une manière différente, selon qu'il existe ou non une copie de ce fichier dans le sous-dossier OpenRails. De cette manière, le problème d'un trop petit nombre de signaux libérés pour une exploitation satisfaisante des trains est généralement résolu.
Si toutefois ce standard simple ligne sigscr.dat ne se comporte pas de manière satisfaisante même en comptant les signaux (une raison a été décrite dans le paragraphe précédent), il faudra l'optimiser pour OR en modifiant le paramètre SignalNumClearAhead() pour les signaux insatisfaisants ; si vous préférez, la ligne peut rester telle quelle, et une ligne optimisée peut être ajoutée avant la ligne existante, et elle comptera à nouveau les signaux. Dans ce cas, le fichier sigscr.dat se comporte comme s'il se trouvait dans le dossier racine de la route.
Sigcfg.dat doit conserver son nom, tandis que les fichiers sigscr peuvent également avoir d'autres noms, à condition que dans sigcfg.dat il y ait une référence à ces autres noms.
OU reconnaît deux valeurs uniques supplémentaires du paramètre SignalNumClearAhead(), lorsque ce paramètre est situé sur une ligne précédant la ligne avec la valeur MSTS, ou si le fichier sigcfg.dat est situé dans le sous-dossier OpenRails :
• 0 : aucun signal ne sera dégagé au-delà de ce signal jusqu'à ce que le train passe ce signal.
• -1 : le signal ne compte pas lors de la détermination du nombre de signaux à effacer.
Pour simuler un comportement particulièrement complexe, Open Rails fournit une interface de script C# pour les signaux. Ces scripts sont écrits dans des fichiers .cs contenant des classes C #, mais ils sont compilés et liés au moment de l'exécution, de sorte qu'ils ne dépendent pas des modifications apportées au programme principal lui-même et peuvent être distribués avec la route.
Les scripts de signal C# sont placés dans le sous-dossier Script/Signal du dossier principal de la route. Tous les fichiers C# présents dans ce dossier seront compilés ensemble lors de l'exécution en un seul assembly.
Pour chaque type de signal défini dans le fichier sigcfg.dat, OR essaie de trouver une classe portant le même nom que le type de signal dans l'assembly compilé. S'il y a des erreurs de compilation ou si aucune classe avec le nom requis n'est trouvée, le script défini dans le fichier sigscr.dat sera utilisé à la place, s'il y a un script adéquat.
Chaque script de signal doit se trouver dans l'espace de noms ORTS.Scripting.Script et doit hériter de la classe CsSignalScript, qui contient toutes les fonctions API disponibles pour le script.
Cet exemple illustre le code minimum requis pour un script de signal :
using System;
using Orts.Simulation.Signalling;
namespace ORTS.Scripting.Script
{
public class MYSIGNALTYPE : CsSignalScript
{
public override void Initialize()
{
// Perform some initializations here, taking into account
// that no route information is available at this point
}
public override void Update()
{
// Set the aspect of your signal here depending on route state
}
public override void HandleSignalMessage(int signalId, string message) {}
}
}
Pour obtenir la liste des appels d'API disponibles pour les scripts de signal, reportez-vous au fichier Orts.Simulation/Simulation/Signalling/CsSignalScript.cs dans le code source OR.
Un environnement de développement peut être mis en place pour accélérer le processus de développement. Voir la section sur les scripts du moteur pour plus d'informations.
Un ensemble de puissantes fonctions de signalisation spécifiques à la salle d'opération sont disponibles. Les fichiers sigcfg et sigscr faisant référence à ces fonctions doivent être localisés comme décrit dans le paragraphe précédent.
Le type de fonction signal SPEED permet d'utiliser un repère d'objet signal comme panneau de vitesse.
Les avantages d'une telle utilisation sont :
• Le marqueur d'objet signal ne s'applique qu'à la piste sur laquelle il est placé. Les panneaux de vitesse d'origine affectent toujours également toutes les lignes à proximité, ce qui rend difficile et parfois impossible de fixer une limite de vitesse spécifique sur une seule voie dans des zones complexes.
• En tant qu'objet signal, le signal SPEED peut avoir plusieurs états définis et une fonction de script pour sélectionner l'état requis, par ex. en fonction du choix de l'itinéraire. Cela permet de définir différentes limites de vitesse pour différents itinéraires à travers la zone, par ex. pas de limite pour la ligne principale mais des limites spécifiques pour un certain nombre d'itinéraires divergents.
Le signal SPEED est entièrement traité comme une limite de vitesse et non comme un signal, et il n'a aucun effet sur les autres signaux.
Limitation : il n'est pas possible de définir des vitesses différentes selon le type de train (voyageur ou fret).
Définition et utilisation
La définition est similaire à celle de tout autre signal, avec SignalFnType défini sur SPEED.
Il permet la définition d'états de tirage et d'aspects comme n'importe quel autre signal. Différentes valeurs de vitesse peuvent être définies par aspect comme d'habitude.
Un aspect peut être défini pour ne pas avoir de limite de vitesse active. Si cet aspect est actif, la limite de vitesse ne sera pas modifiée. Cela peut, par exemple, être utilisé si une limite de vitesse liée à l'itinéraire est requise. Cet aspect peut alors être défini pour un itinéraire pour lequel aucune limite de vitesse n'est requise.
Un aspect peut également être défini pour ne pas avoir de limite de vitesse active mais avec un indicateur de signal spécial : OR_SPEEDRESET.
Si cet ag est défini, la limite de vitesse sera réinitialisée à la limite définie par le dernier panneau de limitation de vitesse. Cela peut être utilisé pour réinitialiser toute limite imposée par un aspect de signal spécifique. Notez que cela n'annule pas les limites de vitesse définies par un autre signal SPEED car ces limites sont traitées comme si elles étaient définies par un panneau de limitation de vitesse.
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 )
)
Remarques:
• La valeur SignalNumClearAhead doit être incluse pour satisfaire la syntaxe mais n'a aucune fonction.
• La vitesse réelle peut être définie soit à l'aide d'une sélection d'aspect fixe via les fonctions utilisateur, soit être liée à l'itinéraire.
L'utilisation réelle est définie dans le script associé et la définition de forme associée.
Exemple 2 :
SignalType ( "SpeedReset"
SignalFnType ( SPEED )
SignalLightTex ( "ltex" )
SignalDrawStates ( 1
SignalDrawState ( 0
"Red"
)
)
SignalAspects ( 1
SignalAspect ( STOP "Red" signalflags (OR_SPEEDRESET) )
)
SignalNumClearAhead ( 2 )
)
Cet exemple réinitialise la vitesse à la limite définie par le dernier panneau de vitesse, annulant toutes les limites de vitesse définies par les aspects du signal.
Les signaux de contrôle d'approche sont utilisés, en particulier au Royaume-Uni, pour maintenir un signal en « danger » jusqu'à ce que le train se trouve à une distance spécifique devant le signal ou ait réduit sa vitesse à une valeur spécifique. Un tel contrôle est utilisé pour les itinéraires divergents, pour s'assurer que la vitesse du train est suffisamment réduite pour négocier en toute sécurité les aiguillages sur l'itinéraire divergent.
Trois fonctions de script à utiliser dans OR ont été définies et peuvent être utilisées pour contrôler le signal jusqu'à ce que le train ait atteint une position spécifique ou ait réduit sa vitesse.
Ces fonctions sont :
APPROACH_CONTROL_POSITION(position)
APPROACH_CONTROL_POSITION_FORCED(position)
APPROACH_CONTROL_SPEED(position, vitesse)
Ces fonctions sont des fonctions booléennes : la valeur renvoyée est "vrai" si un train s'approche du signal et se trouve à la distance requise du signal et, pour APPROACH_CONTROL_SPEED, a réduit sa vitesse en dessous des valeurs requises.
La fonction APPROACH_CONTROL_POSITION_FORCED est similaire à APPROACH_CONTROL_POSITION, mais elle peut être utilisée avec n'importe quel type de signal. Pendant ce temps, APPROACH_CONTROL_POSITION nécessite des signaux NORMAL et n'effacera le signal que s'il s'agit du signal suivant du train.
Paramètres :
• position : distance requise du train s'approchant du signal, en mètres
• vitesse : vitesse souhaitée, en m/s
Notez que la vitesse n'est vérifiée que lorsque le train se trouve dans la distance dé nie.
Remarque importante : bien que le script utilise ‘float’ pour définir les variables locales, ce sont en fait tous des entiers. Ceci est également vrai pour les valeurs utilisées dans ces fonctions : si des valeurs directes sont utilisées, celles-ci doivent être des valeurs entières.
Les valeurs peuvent être définies directement dans le script du signal, soit sous forme de variables, soit sous forme de nombres dans l'appel de fonction.
Cependant, il est également possible de définir les limites requises dans le fichier sigcfg.dat dans le cadre de la définition du signal.
La définition de la syntaxe pour cela est :
ApproachControlLimits ( <définitions> )
Définitions autorisées :
• Position :
– Positionm : position en mètres.
– Positionkm : position en kilomètres.
– Positionmiles : position en miles.
– Positionyd : position en yards.
• Vitesse :
– Speedkph : vitesse en km/heure.
– Speedmph : vitesse en miles/heure.
Ces valeurs sont référencées dans le fichier de script à l'aide des noms de variables suivants :
• Approach_Control_Req_Position
• Approach_Control_Req_Speed
Ces variables ne doivent pas être définies comme des flottants, etc., mais peuvent être utilisées directement sans définition préalable.
Notez que les valeurs telles que définies dans le fichier sigcfg.dat seront converties en mètres et mètres/sec et arrondies à la valeur entière la plus proche.
L'exemple suivant concerne un signal lumineux de recherche à trois têtes, qui utilise le contrôle d'approche si l'itinéraire est défini sur la tête « inférieure ».
La sélection d'itinéraire se fait par des signaux de sélection d'itinéraire de type DISTANCE "fictifs".
Définition du signal :
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 )
)
Fonction de signal (réduite pour montrer l'utilisation du contrôle d'approche uniquement). Cette fonction utilise le contrôle d'approche pour la route « inférieure ». :
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);
Cette fonction est spécifiquement destinée à permettre aux trains de "faire appel" en mode horaire lorsqu'ils sont autorisés à le faire, comme défini dans l'horaire. L'utilisation de cette fonction permet à un train de "faire appel" à un quai en mode Horaire sans compromettre la fonctionnalité en mode Activité normal.
La Fonction TrainHasCallOn n'ouvrira le Signal que si le train est arrivé sur le canton avant le Signal. Si le Signal doit s'ouvrir plus tôt, utilisez plutôt la fonction TrainHasCallOn_Advanced, l'ouverture du Signal suivra alors les règles du Sigcfg.dat-Parameter SignalNumClearAhead().
C'est une fonction booléenne et renvoie l'état comme suit :
• Mode Activité :
– Renvoie vrai si :
* L'itinéraire à partir du signal ne mène pas à une plate-forme.
• Mode horaire :
– Renvoie vrai si :
* L'itinéraire à partir du signal ne mène pas à une plate-forme.
* L'itinéraire à partir du signal mène à un quai et le train a un arrêt réservé sur ce quai, et l'un des états suivants est vrai :
· Le train a une commande $CallOn définie pour cette gare.
· Le train a la commande $Attach définie pour cette gare et le train sur le quai est le train auquel il doit s'attacher.
· Train fait partie de la commande RunRound et doit être attaché au train actuellement sur la plate-forme.
De plus, à la fois en mode Horaire et Activité, cette fonction retournera vrai si l'option CallOn est sélectionnée dans le menu contextuel du signal dans la fenêtre Dispatcher.
L'utilisation de cette fonction doit être associée à une vérification de :
état du bloc ==# BLOC_OCCUPIÉ
Remarque : cette fonction ne doit PAS être utilisée en combinaison avec :
état du bloc ==# JN_OBSTRUCTED
L'état JN_OBSTRUCTED est utilisé pour indiquer que l'itinéraire n'est pas accessible au train (ex. aiguillage contre le train, mouvement inverse en cours, etc.).
Certains scripts de signal permettent aux signaux de s'effacer sur blockstate ==# JN_OBSTRUCTED. Cela peut conduire à toutes sortes de situations incorrectes. Ces problèmes ne sont pas dus à des erreurs de programmation mais à des erreurs de script de signal de routage.
Exemple (partie du script uniquement) :
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;
}
}
Cette fonction a été introduite parce que les signaux avec des aspects d'appel peuvent être utilisés non seulement comme signaux d'entrée pour les gares, mais aussi sur les sections de « ligne libre », c'est-à-dire éloignées des gares.
La fonction TrainHasCallOn_Restricted n'ouvrira le signal que si le train est arrivé sur le canton avant le signal. Si le signal doit s'ouvrir plus tôt, utilisez plutôt la fonction TrainHasCallOn_Restricted_Advanced. l'ouverture du Signal suivra alors les règles du Paramètre Sigcfg.dat SignalNumClearAhead().
Dans les lignes suivantes, où TrainHasCallOn apparaît, TrainHasCallOn et TrainHasCallOn_Advanced sont signifiés ; de manière analogue, lorsque TrainHasCallOn_Restricted apparaît, il s'agit de TrainHasCallOn_Restricted et TrainHasCallOn_Restricted_Advanced.
TrainHasCallOn autorise toujours l'appel si le signal se trouve sur une section "ligne libre". Ceci permet un bon fonctionnement des signaux permissifs de type USA.
Certains systèmes de signalisation utilisent cependant ces signaux sur des tronçons où l'appel n'est pas autorisé. Pour ce cas, la fonction TrainHasCallOn_Restricted a été introduite.
À l'approche d'une gare, les deux fonctions se comportent de la même manière, mais sur les sections "ligne libre", TrainHasCallOn_Restricted() n'autorisera jamais l'appel.
Donc, en quelques mots :
• Utilisation à l'approche des gares :
– TrainHasCallOn() et TrainHasCallOn_Restricted() :
* Activité : appel non autorisé
* Horaires : appel autorisé dans des situations spécifiques (avec les commandes $callon, $stable ou $attach)
• Utilisation en "ligne libre" :
– TrainHasCallOn() :
* Activité ou Horaire : appel toujours autorisé
– TrainsHasCallOn_Restricted() :
* Activité ou Horaire : appel jamais autorisé
Toutes ces fonctions peuvent être définies manuellement à partir de la fenêtre Dispatcher.
Ces signaux peuvent être établis avec le MSTS RE. Dans le fichier .tdb, seule une référence au nom SignalType est écrite, et dans le fichier world, seule une référence à la tête de signal est écrite. Comme ceux-ci sont conformes aux normes MSTS, il n'est pas nécessaire de modifier manuellement les fichiers de route.
Cette fonction est similaire à NEXT_SIG_LR, sauf qu'elle renvoie l'état du nième signal devant.
Appel de fonction :
état = NEXT_NSIG_LR(MstsSignalFunction fn_type, int n).
Valeur renvoyée :
• état du nième signal en avant, sauf,
– Lorsqu'il y a moins de n signaux devant le train.
– lorsque l'un des signaux intermédiaires est en danger.
Dans ces situations, la fonction renverra SIGASP_STOP.
Utilisation : prenez, par exemple, la séquence de signaux comme indiqué ci-dessous.
La distance entre les signaux B et C, ainsi qu'entre C et D, est plus courte que la distance de freinage requise. Par conséquent, si D est en danger, C et B doivent montrer du jaune ; similaire, si C est en danger, B et A doivent être jaunes.
Le problème maintenant est de savoir quel aspect doit être montré en A : si B est jaune, est-ce parce que C est en rouge, donc A doit aussi être jaune, ou est-ce parce que C est en jaune alors que D est en rouge – auquel cas A peut montrer vert. On pourrait, bien sûr, utiliser deux états différents pour le jaune en C, mais cela devient vite assez compliqué, et aussi on pourrait bientôt manquer d'aspects disponibles.
Avec la nouvelle fonction, cela devient plus simple : si B est au jaune, A peut directement vérifier l'état de C, et ainsi décider s'il peut passer au vert ou doit montrer du jaune.
Supposons que l'état SIGASP_STOP s'affiche en rouge, SIGASP_APPROACH_1 s'affiche en jaune et SIGASP_CLEAR_1 s'affiche en vert pour tous les signaux, la partie associée du script pourrait être la suivante :
if (next_sig_lr(SIGFN_NORMAL) == SIGASP_APPROACH_1)
{
if (next_nsig_lr(SIGFN_NORMAL, 2) == SIGASP_STOP)
{
state = SIGASP_APPROACH_1;
}
else
{
state = SIGASP_CLEAR_1;
}
}
La fonction est également très utile lorsqu'un signal distant doit refléter l'état de plusieurs signaux domestiques, mais dist_multi_sig_mr ne peut pas être utilisé car il n'y a pas de signal distant plus loin.
Cette fonction peut être utilisée pour tout SIGNAL_HEAD facultatif tel que défini pour la forme de signal pertinente dans sigcfg.dat, pour vérifier si cela a été sélectionné pour ce signal ou non.
L'utilisation de têtes factices 'DECOR' permet d'utiliser ces têtes comme paramètres utilisateur supplémentaires et, en tant que telles, constitue une sorte d'extension des quatre drapeaux SIGFEAT_USER disponibles.
Veuillez noter que cette fonction est encore expérimentale.
Appel de fonction :
state = HASHEAD( n );
où n est le SignalSubObj-Number en question. La fonction renvoie 1 si head SignalSubObj est défini, sinon 0.
Contrairement à MSTS, les trains AI par défaut transmettent des signaux avec un aspect RESTRICTED ou STOP_AND_PROCEED à vitesse réduite. Pour fournir également un fonctionnement compatible MSTS et pour prendre en compte les systèmes de signalisation où aucune réduction de vitesse n'est requise lors du passage de tels signaux, le drapeau OR_NOSPEEDREDUCTION a été introduit. Voici un exemple d'utilisation d'un tel indicateur :
SignalAspects ( 7
SignalAspect ( STOP "Red" )
SignalAspect ( STOP_AND_PROCEED "LowYellowFlash" SpeedMPH(25) signalflags (OR_
˓→NOSPEEDREDUCTION) )
SignalAspect ( RESTRICTING "LowYellow" SpeedMPH(25) signalflags (OR_
˓→NOSPEEDREDUCTION) )
SignalAspect ( APPROACH_2 "TopYellowMidGreen" )
SignalAspect ( APPROACH_3 "TopYellow" )
SignalAspect ( CLEAR_1 "MidGreen" )
SignalAspect ( CLEAR_2 "TopGreen" )
)
Avec cet indicateur activé, aucune réduction de vitesse n'est appliquée lors du passage du signal.
Les ajouts décrits ci-dessous seront ignorés par MSTS. Étant donné que les fichiers d'activité ne sont pas utilisés en mode Horaires, aucune des fonctionnalités suivantes ne fonctionnera dans ce mode. Vous pouvez effectuer ces ajouts de trois manières différentes, qui sont décrites dans les sous-paragraphes suivants.
Effectuez ces ajouts en modifiant le fichier .act avec un éditeur compatible Unicode. Notez que ces ajouts seront supprimés par l'éditeur d'activité MSTS si le fichier d'activité .act est ouvert et enregistré en tant que fichier .act par l'AE. Cependant, si l'activité est ouverte dans l'AE et enregistrée dans un package d'activités .apk, les ajouts seront inclus à la place.
L'éditeur d'itinéraire TSRE5 inclut des fonctionnalités d'édition d'activité. Ces capacités incluent l'ajout de certains ajouts spécifiques à la RO dans les fichiers d'activité décrits dans les paragraphes suivants. Une note est présente là où cela ne s'applique pas.
Si l'éditeur TSRE5 n'est pas utilisé, et si l'on souhaite éviter le problème de perte des ajouts spécifiques à l'OR en modifiant ultérieurement l'activité avec l'éditeur d'activité MSTS, il est recommandé d'utiliser cette troisième possibilité : un sous-dossier OpenRails doit être créé dans le dossier ACTIVITIES de la route, et un fichier .act contenant uniquement les extensions spécifiques à OR utilisées peut être créé avec un éditeur compatible Unicode, puis situé à cet endroit. Un exemple de fichier .act non modifié et d'extension de fichier .act dans le sous-dossier OpenRails de la route est inclus dans le fichier ORActivityExtensionFileSample.zip, qui se trouve dans le sous-dossier Documentation\SampleFiles\Manual du dossier OpenRails. Comme on peut le voir, le nom d'un tel fichier d'extension .act doit être le même que celui du fichier de base .act. Concernant les événements, pour assurer une correspondance croisée correcte entre les définitions d'événements dans le fichier de base et dans le fichier d'extension, dans le fichier d'extension du bloc EventCategory de chaque événement modifié, la première ligne doit être l'ID (), et l'ID doit correspondre à celui présent dans le fichier de base .act. Seules les lignes ajoutées dans ce bloc EventCategory doivent être présentes dans le fichier d'extension .act.
Les activités MSTS peuvent contenir des instructions pour afficher une boîte de message lorsque le train du joueur atteint un emplacement spécifique de l'activité ou à une heure spécifique. Normalement, la simulation est interrompue lorsque la boîte de message s'affiche jusqu'à ce que le joueur ferme manuellement la boîte. Ce comportement peut être modifié si la ligne :
ORTSContinuer ( nn )
Où nn = nombre de secondes pour afficher la boîte, est ajouté à la déclaration d'événement (EventTypeLocation ou EventTypeTime) dans le fichier .act.
Par exemple:
EventCategoryLocation (
EventTypeLocation ( )
ID ( 1 )
Activation_Level ( 1 )
Outcomes (
DisplayMessage ( "Test nopause." )
)
Name ( Location1 )
Location ( -146 14082 -1016.56 762.16 10 )
TriggerOnStop ( 0 )
ORTSContinue ( 10 )
)
Maintenant, l'activité continuera à s'exécuter pendant que la fenêtre de message est affichée. Si le joueur ne fait rien, la fenêtre disparaît automatiquement après nn secondes. Le joueur peut fermer la fenêtre manuellement ou interrompre l'activité en cliquant sur le bouton approprié dans la fenêtre. Notez que cette modification ne fonctionne pas pour l'événement de fin de l'activité.
Les points d'attente peuvent être utilisés pour demander aux trains IA de klaxonner à des endroits spécifiques.
Si la valeur du temps d'attente est comprise entre 60011 (coup de klaxon de 1 seconde) et 60020 (coup de klaxon de 10 secondes), un seul coup de klaxon est généré.
Si la valeur du temps d'attente est 60021, une séquence de coup de klaxon est générée, avec le modèle coup long - coup long - coup court - coup long (modèle de klaxon nord-américain aux passages à niveau).
Le train AI ne s'arrêtera pas à ces points d'attente, mais continuera à sa vitesse habituelle.
Si la locomotive de tête du train AI a le paramètre DoesHornTriggerBell défini sur 1 dans le fichier .eng, la cloche est jouée pendant 30 secondes supplémentaires après la fin du coup de klaxon.
Pour mettre en œuvre cette fonctionnalité, il n'est pas nécessaire de procéder comme décrit dans les trois premiers paragraphes de ce chapitre. Il suffit d'insérer les points d'attente dans les chemins avec MSTS AE ou via TrackViewer.
Open Rails peut également être chargé de faire en sorte que les trains IA klaxonnent automatiquement aux passages à niveau. Cette fonctionnalité est activée à l'aide de propriétés spéciales dans le bloc Tr_Activity_File :
Propriété | Signification |
---|---|
ORTSAIHornAtCrossings | Demandez aux trains AI de klaxonner aux passages à niveau — (1) pour oui, (0) ou omis pour non. |
ORTSAICrossingHornPattern | Spécifie le modèle de klaxon soufflé aux passages à niveau - ( US ) pour un modèle nord-américain long-long-court-long, ( Single ) ou omis pour un seul son entre 2 et 5 secondes. |
Ces lignes doivent être placées après la ligne NextActivityObjectUID ( 32768 ), sinon le fichier d'activité ne pourra plus être chargé dans l'éditeur d'activité MSTS.
De simples franchissements routiers, non définis comme des passages à niveau, peuvent également être présents sur le parcours. Le train AI ne klaxonnera pas à ces passages à niveau. L'examen de l'itinéraire avec TrackViewer permet d'identifier les véritables passages à niveau. Si un coup de klaxon est également souhaité pour une simple traversée de route, la fonction AI Train Horn Blow décrite ci-dessus doit être utilisée.
Si la locomotive de tête du train AI a le paramètre DoesHornTriggerBell défini sur 1 dans le fichier .eng, la cloche est jouée pendant 30 secondes supplémentaires après la fin du coup de klaxon.
Sous MSTS, les événements de localisation ne peuvent être déclenchés que lorsque le train du joueur les atteint. OR fournit également des événements de localisation déclenchés par des trains AI. Dans ce cas, une ligne comme la suivante doit être ajoutée dans le bloc EventCategoryLocation :
ORTSTriggeringTrain ("TestEventAI" 43230)
où "TestEventAI" est le nom du service du train AI, et 43230 est l'heure de début de la journée (en secondes) du train AI. Le deuxième paramètre peut être omis s'il n'y a qu'un seul train AI avec le nom de service présent dans la ligne ci-dessus.
Cette fonctionnalité en lien avec la modi cation AI trainWaiting Point par événement permet la synchronisation entre les trains AI ou également entre un train AI et le train du joueur.
Cette fonctionnalité n'est pas encore gérée par TSRE5.
Un fichier d'activité peut être modifié pour qu'un fichier son soit joué lorsque le train atteint un emplacement spécifié dans un événement EventTypeLocation dans le fichier .act, ou lorsqu'un certain intervalle de temps spécifié dans un événement EventType-Time s'est écoulé depuis le départ de l'activité. Dans le sous-bloc Outcomes() de l'événement, ajoutez le sous-bloc suivant :
ORTSActivitéSon (
ORTSActSoundFile ( Nom de fichier SoundType )
ORTSSoundLocation ( TileX TileZ X Y Z )
)
à l'événement EventCategoryLocation ou EventCategoryTime, où :
• Filename = nom, entre guillemets, d'un fichier .wav situé dans le dossier SOUND de la route. (Si le fichier .wav se trouve ailleurs sur l'ordinateur, la chaîne doit également contenir le chemin du dossier SOUND à l'emplacement où se trouve le son.)
• Soundtype = n'importe laquelle des chaînes :
– Partout – le son est joué dans toutes les vues au même volume sans effets de fondu
– Cabine – le son n'est joué que dans la cabine
– Pass – le son est joué uniquement dans la vue passager active
– Sol – le son est joué de manière externe à partir d'une position fixe, celle que la locomotive a atteinte lorsque l'événement est déclenché. Le son est également entendu dans les vues internes
de manière atténuée, et s'atténue en s'éloignant de la position.
– Emplacement – le son est lu en externe à partir d'une position fixe dé nie dans le paramètre ORTSSound-Location.
Remarque : Le paramètre ORTSSoundLocation est nécessaire uniquement lorsque Soundtype est Location.
Par exemple:
EmplacementCatégorieÉvénement (
Type d'événementEmplacement ( )
ID ( 7 )
Niveau_activation ( 1 )
Résultats (
DisplayMessage ("Ne sera pas affiché car ORTSContinue = 0")
ORTSActivitéSon (
ORTSActSoundFile ( "milanogrecopirelli.wav" "Ground")
)
)
Nom ( Emplacement6 )
Emplacement ( -146 14082 -1016.56 762.16 10 )
TriggerOnStop ( 0 )
ORTSContinuer ( 0 )
)
L'inclusion de la ligne ORTSContinue (expliquée ci-dessus) inhibe l'arrêt normal de l'activité par l'événement. De plus, si la valeur 0 est insérée dans la ligne comme dans l'exemple ci-dessus, l'affichage du message d'événement est complètement supprimé. Un seul fichier son par événement est autorisé.
Cette fonctionnalité n'est pas encore gérée par TSRE5 dans ce format.
Une activité peut être modi ée pour que le temps change lors de l'exécution de l'activité dans ORTS. Le fonctionnement de MSTS n'est pas affecté par ces événements WeatherChange. Le bloc suivant peut être ajouté dans le bloc Outcomes () d'un bloc d'événement (soit un événement de lieu ou de temps) du fichier .act :
ORTSChangementMétéo (
ORTSCouvert (
final_overcastFactor(float)
overcast_transitionTime(entier)
)
ORTSFog ( final_fogDistance(float) fog_transitionTime(int) )
ORTSPrécipitationIntensité (
final_precipitationIntensity (flotteur)
précipitationIntensity_transitionTime(entier)
)
ORTSPrécipitationLiquidité (
final_precipitationLiquidity(float)
précipitationLiquidity_transitionTime(entier)
)
)
Le temps changera en conséquence pendant l'activité. Les fourchettes des facteurs sont les suivantes :
• final_overcastFactor : valeur de 0 à 1.
• final_fogDistance : valeur de 10 (mètres) à 100 000.
• final_precipitationIntensity : valeur de 0 à 0.020 (fixée à 0.010 si une carte graphique 16 bits est utilisée).
• final_precipitationLiquidity : valeur de 0 à 1.
Le type de temps changera en conséquence selon les règles suivantes :
• lorsque l'intensité des précipitations tombe à 0, le type de temps est défini sur Clair.
• lorsque précipitationIntensity dépasse 0, le type de temps est sélectionné en fonction de final_precipitationLiquidity.
• lorsque la précipitationLiquidité est supérieure à 0,3, le type de temps est défini sur Pluie.
• lorsque la précipitationLiquidité est inférieure ou égale à 0,3, le type de temps est défini sur Neige.
Le paramètre ORTSPrecipitationLiquidity permet une transition en douceur de la pluie (ORTSPrecipitationLiquidity = 1) à la neige (ORTSPrecipitationLiquidity = 0) et vice-versa.
Le xx_transitionTime est exprimé en secondes et indique le temps nécessaire pour passer de la valeur initiale de la caractéristique météo (overcastFactor, fogDistance, etc.) à la valeur finale de la caractéristique météo. Si un tel xx_transitionTime est défini sur 0, la fonction météo prend immédiatement la valeur finale. Ceci est utile pour démarrer des activités avec des caractéristiques météorologiques dans des états intermédiaires.
L'événement peut également inclure une ligne ORTSContinue ( 0 ), n'affichant donc pas de messages et ne suspendant pas l'exécution de l'activité.
Les commandes manuelles liées à la météo interrompent le changement de temps déclenché par les événements ci-dessus.
Chaque bloc d'événement dans le fichier d'activité peut inclure un seul bloc WeatherChange, et chaque bloc Weather-Change peut inclure une à toutes les lignes spécifiées ci-dessus.
Les blocs d'événements, y compris les blocs WeatherChange, peuvent être partiellement entrelacés (l'exécution d'un bloc peut être encore active au moment où un nouveau bloc WeatherChange est déclenché). L'exécution des différents changements de paramètres météorologiques reste indépendante. Si un paramètre météo est présent dans les deux événements, l'exécution du changement de paramètre commandé par le premier bloc est arrêtée et celle commandée par le second bloc est démarrée.
Remarque : la modification du fichier .act avec l'éditeur d'activité MSTS après l'inclusion des événements WeatherChange les supprimera, ils doivent donc être sauvegardés séparément. L'ouverture d'un fichier .act qui contient des événements WeatherChange avec l'éditeur d'activité MSTS et son conditionnement sans le modifier génère un fichier .apk qui contient les événements WeatherChange.
Cette fonctionnalité n'est pas gérée par TSRE5 dans ce format.
Objectif de la fonctionnalité
Un résultat d'événement est disponible qui modifie le délai d'expiration du point d'attente lorsque l'événement est atteint (par exemple, lorsque le train du joueur l'atteint, dans le cas d'un événement de localisation).
Cela résout les problèmes de synchronisation des trains AI. Si par ex. un train AI doit accoupler ou désaccoupler des voitures vers/du train du joueur, il faut s'assurer que les deux trains sont au bon endroit au bon moment. Si toutefois cela se produisait après un long parcours du train du joueur, celui-ci pourrait être retardé, et il est donc difficile de garantir que le rendez-vous se déroule correctement. Dans ce cas, un point d'attente de longue durée peut être placé sur le sillon AI. Le train de l'IA y attendra le train du joueur. À l'emplacement de synchronisation (généralement peu avant le point où le train du joueur doit être touché par le train AI), un événement de localisation est positionné, qui indique la valeur du point d'attente mise à jour pour le train AI (généralement un point d'attente court). Lorsque le train du joueur atteindra un tel événement de localisation, le point d'attente du train AI sera mis à jour et ce train redémarrera après l'expiration du point d'attente mis à jour, et il se couplera au train du joueur.
La fonctionnalité peut également être utilisée pour d'autres fonctionnalités, comme avoir un train AI couplé au train du joueur en tant qu'assistant, ou comme garantir une connexion de train de voyageurs dans une gare, ou comme avoir un train AI couplé à un autre train AI (selon l'événement peut également être déclenché par un train IA, voir Événement de localisation déclenché par un train IA.
Syntaxe de la fonctionnalité
Pour utiliser cette fonctionnalité, il est suggéré de générer un fichier d'activité d'extension.
Voici un exemple de fichier d'activité d'extension utilisant une telle fonctionnalité :
SIMISA@@@@@@@@@@JINX0a0t______
Tr_Activity (
Tr_Activity_File (
Events (
EventCategoryLocation (
ID ( 1 )
ORTSContinue ( 3 )
Outcomes (
ORTSRestartWaitingTrain (
ORTSWaitingTrainToRestart ( "TesteventWP_ai_
˓→longerpath" 23240 )
ORTSDelayToRestart ( 60 )
ORTSMatchingWPDelay ( 31500 )
)
)
)
)
)
)
Description des paramètres :
1) ORTSWaitingTrainToRestart a comme premier paramètre le nom du service du train AI dont le point d'attente doit être modi é, et comme deuxième paramètre (optionnel) l'heure de départ du train AI.
2) ORTSDelayToRestart est le nouveau délai pour le point d'attente. Il est exprimé en secondes.
3) ORTSMatchingWPDelay indique la valeur d'origine du point d'attente du train AI ; ceci est utilisé pour s'assurer que le point d'attente correct est modifié.
Le fichier ci-dessus est également disponible en tant que fichier TesteventWP_longerpath_extension.zip, qui se trouve dans le sous-dossier Documentation\SampleFiles\Manual du dossier OpenRails. Un exemple d'activité utilisant un tel fichier est disponible sous le nom de fichier testeventwp_longerpath.zip dans le même sous-dossier. C'est un fichier .apk.
L'activité utilise l'ancien itinéraire MSTS USA1 et les anciennes rames.
Le train du joueur sort du tunnel et s'arrête à la gare de Baltimore. Juste avant cela, il frappe l'événement de localisation définissant le train AI WP. Plus tard, un train AI entrera dans la gare et s'arrêtera. Ce train atteint un WP absolu juste après avoir terminé le déchargement des passagers. Comme le train du joueur est arrivé avant, ce WP absolu est mis à zéro et le train AI redémarrera sans plus attendre.
Si, au contraire, le train du joueur est arrêté avant d'entrer dans la gare et y reste jusqu'à ce que le train IA soit entré dans la gare et ait déchargé les passagers, le train IA y restera jusqu'à ce que le train du joueur redémarre, atteigne l'événement de localisation et que le temps WP modifié ait expiré.
Cette fonctionnalité n'est pas encore gérée par TSRE5.
Les formats alternatifs suivants sont acceptés par OR pour les fichiers audio d'événements et les changements de temps. Ces formats ne sont pas recommandés pour les nouvelles activités.
Fichiers sons d'événement : Le fichier son peut être défini par une seule ligne :
ORTSActSoundFile ( Nom de fichier SoundType )
à insérer directement dans le bloc EventCategoryLocation() ou EventCategoryTime(), au lieu d'être inséré dans le sous-bloc Outcomes(). Dans ce format alternatif, Location SoundType n'est pas pris en charge.
TSRE5 gère ce format.
Événements Weather Change : le bloc ORTSWeatherChange() peut être inséré directement dans le bloc EventCategoryLocation() ou EventCategoryTime(), au lieu d'être inséré dans le sous-bloc Outcomes().
TSRE5 gère ce format.