Je fais un lien vers mon sujet correspondant sur le forum anglophone :
http://openbve.freeforums.org/signal-an ... t2579.htmlLe plus important dans le sujet est cette partie :
Citer:
Beacon is attached to section A:
With Track
100, .Section 0; 2; 4 ,; Section A starts here
200, .Beacon 44000; 1; 0; 0
200, .Section 0; 2; 4 ,; Section B starts here
300, .Section 0; 2; 4 ,; Section C starts here
Beacon is attached to section B:
With Track
100, .Section 0; 2; 4 ,; Section A starts here
200, .Beacon 44000; 1; 1; 0
200, .Section 0; 2; 4 ,; Section B starts here
300, .Section 0; 2; 4 ,; Section C starts here
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é)