Remarques sur le script de la rampe AWS

[henrion 101]

Bonjour.

 

Le script de la rampe AWS est, me semble t-il, utilisé par le crocodile de Nicolas. La longueur de son script par rapport à celui de la grille TPWS m'a intrigué car normalement le système AWS est plus simple que celui du TPWS qui contrôle en plus la vitesse.

 

Après avoir regardé le script, j'ai plusieurs remarques à faire que je soumets à votre appréciation:

 

1°) Le script utilise une variable gOccupation. Cela est dû au fait que la rampe AWS est située largement en amont du signal (100 à 200 mètres). Cette variable permet de réinitialiser la rampe si un train la franchit puis fait rebroussement sans avoir passé le lien 0 du signal suivant. Cela n'est pas utile pour nos crocodiles qui sont positionnés à proximité immédiate du signal.

 

2°) Il y a plusieurs fonctions qui n'ont aucune utilité. Je m'explique. La fonction OnConsistPass ne fait pas appel à la fonction BaseOnConsistPass, pourtant on retrouve cette dernière dans le script. Il en va de même pour la fonction OnSignalMessage vis-à-vis de la fonction BaseOnSignalMessage. En fait ce qui s'est passé c'est qu'en faisant un copier-coller des variables globales issues des Common Scripts, les autres fonctions de ces common scripts ont été également rajoutées. Bien sûr, la présence de ces fonctions inutiles n'empêchent pas le script de fonctionner correctement mais cela l'alourdit inutilement.

 

3°) Plus de 95% des variables globales définies n'ont aucune utilité dans ce script. Il suffit de regarder le script TPWS pour voir la différence. Mais là aussi cela n'empêche pas le script de fonctionner. C'est un peu le revers de la médaille d'avoir fait un système de fichiers communs.

 

En fait pour avoir un bon script pour le crocodile, il faudrait reprendre le script TPWS en lui retirant le contrôle de la vitesse.

 

Ce qui m'amène à une dernière remarque qui me semble la plus importante. Les scripts AWS et TPWS fonctionnent bien mais en n'utilisant que les états de base des signaux (Blocked, Clear, Warning). Or le script des crocodiles doit reprendre les mêmes états que ceux des signaux. Si l'on se réfère à l'IN 1493, les crocodiles doivent prendre en compte d'autres états comme par exemple les ralentissements 30 et 60. Ce qui veut dire que tous les créateurs de signaux devront adopter la même dénomination des états sinon les crocodiles ne fonctionneront pas correctement ou il faudra un crocodile adapté à chaque créateur ce qui compliquera considérablement la tâche des créateurs de lignes. Il faut donc une uniformisation de la dénomination des états.

 

Pendant la période de fin d'année, j'en avais préparé une mais comme j'ai vu sur le site de Jean-Yves MATHIEU que la sortie de la V2 de ses signaux est imminente, on pourrait adopter la sienne. Ce qui permettrait de créer un script pour le crocodile beaucoup plus complet.

 

Bon dimanche

Edited January 11, 2010 by henrion

[Jules31 44]

Yo.

 

1) Je ne suis pas sûr que ca soit une bonne chose de supprimer l'utilisation de cette variable globale. Certe, on n'a pas 200m entre le croco et le signal mais on peut avoir plusieurs dizaines de mètres dans certains cas.

 

Je m'explique. Par exemple, sur la ligne de Dédé34 qui est équipée du BAL, avec des circuits de voie UM71, la fin du canton se situe bien après le signal de cantonnement. Tu peux avoir quelques dizaines de mètres de distance.

 

De plus, on ne peut pas situer exactement le point où le relai de voie chutera (le relai de voie, c'est le relai relié au récepteur du circuit de voie et qui donne l'occupation du canton). La seule certitude que l'on a c'est qu'il chutera quelque part entre l'émetteur et le récepteur intégrant le joint électrique. Le joint électrique est composé de 3 éléments, que l'on peut voir après un signal le long de la voie. Il y a en effet 3 boites blanchâtres, à équidistance entre boîte successive, et toutes reliées aux rails. La première comporte l'émetteur pour le canton aval et la dernière comporte le récepteur pour le canton amont. La boîte centrale est une self, qui avec les équipements des deux autres boîtes assure le joint électrique entre les deux cantons.

 

Pour simuler cette situation, je place donc le lien 0 des signaux quelques dizaines de mètres après le signal.

 

Ceci dit, on peut donc voir qu'on peut avoir une distance entre le crocodile et le lien 0 du signal supérieure à l'empattement minimal entre essieux d'un véhicule (par exemple un yoyo qui je pense peut se retrouver à rebrousser entre un crocodile et le joint électrique sans empiéter sur l'un ou l'autre.

 

Ce n'est pas un cas banal, mais possible. Voila pourquoi je ferais attention sur ce point.

 

Mais quel est le risque si on supprime cette variable globale ? En quoi consiste cette réinitialisation ?

 

Petite remarque : Est-il possible dans le simu de rendre le crocodile multidirectionnel ? Actuellement, ils ne fonctionnent que pour un sens de circulation mais j'aimerai en faire un nouveau pour qu'il déclenche dans les deux sens. J'installerai alors l'ancien crocodile sur les voies banalisées ou équipées d'IPCS et j'installerai le nouveau dans tous les autres cas pour coller à la réalité du terrain.

 

2) Je pense qu'il faut privilégier la clarté. J'opterais pour ma part au commentaire du code inutile, sans supprimer le code existant. Concernant la lourdeur à l'exécution si on garde les scripts tel quel, avec les interpréteurs de nos jours, je ne pense pas que tu y vois le moindre effet. D'ailleurs, ces scripts sont interprétés ou compilés ?

 

3) Tout à fait d'accord avec toi. Tu rejoins ce que j'ai toujours dit depuis mon arrivé sur le forum et l'apparition des premiers éléments de signalisation dynamique.

[henrion 101]

1°) en fait, et c'est un cas spécifique à la signalisation britannique, lorsqu'un train passe sur le croco, il envoie un message pour dire au signal qu'un train arrive vers lui. Après il faudrait regarder dans le script des signaux à quoi sert exactement de préparer un signal à l'arrivée d'un train mais je ne l'ai pas encore fait. Lorsqu'il y a rebroussement le croco envoie un nouveau message qui annule celui qui a été envoyé précédemment pour remettre le signal à son état antérieur; c'est dans ce sens qu'il y a réinitialisation. Je vais me pencher sur les scripts des signaux britanniques pour voir si cela a une utilité pour nous mais il me semble bien que non.

 

En ce qui concerne la bidirectionnalité du croco cela me semble possible car si l'on regarde les scripts, ils n'envisagent seulement que le cas que du train allant vers l'avant. Il n'y a aucune raison de ne pas pouvoir le programmer dans l'autre sens. C'est à essayer.

 

2°) En ce qui concerne le code inutile, il n'y a aucun souci pour le conserver. Il n'y a aucun effet sur la durée d'exécution du script.

 

A propos de la lecture des scripts, je ne pense pas qu'ils soient compilés puisque l'on peut les ouvrir et les modifier comme l'on veut. Mais ce n'est pas clair dans la documentation officielle. En fait à partir du blueprint je crois que l'on transforme le fichier xml en fichier bin. On indique dans le blueprint l'adresse du fichier lua et on compile mais il me semble que si l'on fait des changements dans le fichier texte lua sans changer son adresse, il n'y a pas besoin de repasser par le blueprint.

Edited January 10, 2010 by henrion

[Jules31 44]

Ok.

 

j'avais entendu parlé à l'époque de l'ajout d'une préparation du signal, mais je ne savais pas que ca marchait dans le simu via les balises AWS. Mais moi non plus je ne sais pas à quoi ca sert vraiment.

 

Concernant la compilation ou l'interprétation des scripts LUA, ca ne veut pas dire qu'il n'y a pas de compilation si le script est directement modifiable sans action supplémentaire pour prise en compte dans le simu. Il se pourrait que le simu lui-même compile le script dans son langage interne lors de son lancement.

 

Quand tu dis "on compile" après avoir renseigné le chemin vers le script dans le blueprint :

- on lui fournit le fichier blueprint en entrée ?

- on obtient quoi en sortie ?

 

Et enfin, j'aurai une petite question de "culture générale" :

- les fichiers blueprint que l'on édite via l'éditeur fournit dans le simu, c'est tout simplement du XML non ?

[henrion 101]

j'ai regardé les fichiers sources fournis par Kuju autant en entrée qu'en sortie. Je pense que cela se passe comme cela. Lors de la création d'un objet on obtient les fichiers IGS et XML. Ensuite on les place dans le répertoire source de railworks. Si ce répertoire n'existe pas, on le crée manuellement.

 

Le fichier IGS est la forme 3D et le fichier XML n'est autre qu'un fichier texte formaté comportant tous les aspects techniques liés à la forme 3D: le nombre de têtes que possède le signal, les nodes (en fait la position des feux).........

 

Lorsque l'on lance le fichier blueprint, celui-ci va ouvrir et lire le fichier XML. On va y placer les adresses du fichier IGS, du fichier LUA et s'il y a des modifications à apporter, on peut le faire car l'interface est assez conviviale.

 

Ensuite, lorsque l'on compile, cela abouti me semble t-il à deux fichiers:

- le fichier GeoPcDx qui est la transformation du fichier IGS donc du modèle 3D en format lisible par le programme.

- le fichier Bin qui est la transformation du fichier XML là aussi en fichier lisible par le programme.

 

Dès que l'on veut faire une modification, il faut impérativement repasser par le blueprint et réexporter ensuite.

 

Cela est-il nécessaire pour les scripts? D'après la documentation de Kuju, il semblerait que oui. Mais comme je le disais plus haut, ce n'est pas clair.

 

Je pense que les créateurs d'objets seront plus compétents que moi pour répondre correctement.

Edited January 10, 2010 by henrion

[henrion 101]

Bonjour,

 

Avec jules31 nous avons parlé de la préparation des signaux qui nous laissait un peu perplexe.

 

J'ai rapidement regardé aujourd'hui un script anglais et je crois avoir saisi le fonctionnement général. Je pensais que cela ne concernait que la signalisation anglaise. En fait, dans Railworks/Rail Simulator, cela concerne apparemment à la fois la signalisation britannique et allemande.

 

Pour schématiser, par défaut, certains signaux sont systématiquement au rouge même si le canton est libre. Lorsqu'un train approche, un message est retransmis par une rampe AWS et/ou un autre signal de block (et cela plusieurs signaux à l'avance) pour dire qu'un train arrive vers lui et qu'il doit prendre l'état adéquat. Une fois le signal franchi, le signal est réinitialisé au rouge et reste au rouge tant qu'un autre train n'arrive pas.

 

Maintenant pour mieux comprendre l'enchaînement des actions, il vaut mieux prendre le script d'un signal allemand que celui d'un sémaphore à plusieurs têtes anglais surtout que la programmation n'a pas l'air simple.

Edited January 11, 2010 by henrion