Hello

Dans le cadre du l'ajout du KVB à mon plugin, j'essaie de comprendre comment marche concrètement la gestion des signaux et section dans OpenBVE.

Je sais qu'il faut jouer avec signal et section, mais j'au du mal a comprendre comment son jumelé les deux.
Comment sont géré les ralent 30/60 et les rappels de ralent 30/60 ?

Si une ame charitable pouvait faire part de son experience dans ce domain :p

Merci.

Je fais un lien vers mon sujet correspondant sur le forum anglophone : http://openbve.freeforums.org/signal-an ... t2579.html

Le plus important dans le sujet est cette partie :



Il faut utiliser le cas "Beacon is attached to section B".
Ce qui fait que dans le code du plugin, la fonction SetBeacon sera appelée à chaque fois que l'on va passer sur le signal pour lequel on a mis un beacon à proximité, on va donc pouvoir récupérer l'état de la section dans laquelle ont vient d'entrer.

A partir de cette état (signal ouvert ou fermé), on peut en déduire le comportement du KVB. Par exemple, on passe sur le couple signal/beacon :

• signal de VL : aucun probleme
• signal A : bip sonor d'attention, LSSF qui clignote, on calcule les deux courbes dans le KVB pour savoir si le train freine bien comme il faut
• sémaphore ou carré : FU

Dans la doc il me semble avoir vu que l'on pouvait passer des argument au .beacon dans le fichier route.csv. Ceci permettrai peut être d'indiquer que c'est un R30/R60 ou RR30/RR60, voir même pourquoi pas un signal de preannonce (vert cli).
Cet système sera aussi utiliser pour tout ce qui est TIV/TIVd et LTV.

Une autre fonction nommée SetSignal est elle appelée à chaque modification d'une section. On pourrait donc imaginer se servir de cette fonction pour améliorer le KVB en système KVBP (mais dans loooongtemps ça )

Je commence donc à voir le bout du tunnel sur comment tout ça fonctionne. J’espère avoir un KVB fonctionnel d'ici la fin janvier (juste gestion des signaux ouvert/fermé)

En faite, c'est pas tout à fait ce que j'avais compris.
Voici un petit schéma fait par Michele qui explique très bien le principe :

Lancement d'un petit debat sur les signaux et les aspects :

Actuellement, j'utilise les aspect 0 (rouge), 2 (jaune) et 4 (vert). J'ai copie l'association couleur / aspect de la doc officiel et pareil que chars-gisors)
swade quant å lui, utilise toute la plage des aspects pour sa route.

Seulement, voila, ses aspects 2 et 4 ne correspondent pas au mien.

A ma connaissance, il n'y a pas de "norme" pour les routes française.

Donc, selon vous, comment devrait-on utiliser les aspects des routes ?

En fait si tes aspects 2&4 correspondent mais j'utilise en plus section 1&3

ton 2 correspond a un signal jaune fixe et ton 4 a un signal vert fixe ?

Ce que J'ai fait :

- 1 Signal NF type H avec rappel 60 qui présente successivement le carré/jaune fixe/rappel 60/vert/vert soit section 0;1;2;3;4

- 1 Signal NF type C avec carré/jaune fixe/jaune clignotant/vert/vert soit encore section 0;1;2;3;4 ou 0;1;2;4

Je pense aussi créer 1 Signal F type A avec sémaphore/jaune fixe/jaune clignotant/vert soit section 0;1;2;3 ou 0;1;2;4 peu importe.

Moi perso, je n'utilise pas les aspects pour les R/RR 30/60 (un peu comme en vrai au final).

Mais la comme tu dis, on re-tombe sur les memes points (0, 2, 4).

Lors de construction la bibliothèque de signaux RFFSigs , j'ai un peu réfléchi à ce type de problème. Si l'on veut que tout les signaux puissent être représentés en utilisant le même code quelque soit le type de cible (A,C,H..), il faut sortir de la vision japonaise (Chars-Gisors se mapperait sur le standard built-in car l'auteur demandait de remplacer les cibles japonaises incluses dans le produit par les cibles française qu'il livrait).

Que pensez-vous d'utiliser tous le même codage, par exemple celui proposé dans RFFSigs:



PS: RFFSigs étant en bêta, on peut modifier ceci si cela une convient pas. Mais, il serait dommage que l'on ne parte pas tous sur les mêmes codes.

Bientôt le premier "standard" français, à l'image de BVETSS ?