La VACMA, c'est possible avec RW ?

[pml3 303]

Tout à fait d'accord, Jules31,

 

et c'est mon probleme !

 

Dans un script LUA, j'arrive à pas mal de choses (vacma avec fonction test, repet signaux, controle animation des manettes de frein, je prepare même un lien entre regulateur et couplage).

 

Mais je n'arrive pas à détecter le mode de conduite

 

Si Erakis passe par là et qu'il a une idée

 

Quel controleur du jeu faut-il utiliser ?????? au hasard "DriverMode" ne semble pas exister............

 

Patrick

[Jules31 44]

Arf dommage. Je fouille dans mes scripts pour voir si le mode de conduite est accessible depuis ceux-ci.

 

Je te tiendrai au courant.

 

Concernant le lien régulateur-couplage, tu parles du volant de passage des crans et du visualisateur des crans et types de couplage des moteurs de traction ?

 

Bonne aprem.

Edited November 10, 2009 by Jules31

[pml3 303]

Tout a fait, Jules31,

 

Je prevois la rêgle suivante en espérant approcher la réalité, que je ne connais pas !

 

crans 1 à 6 = série

crans 7 à 11 = série/parallèle

crans 12 à 25 = parallèle

avec les contrôles suivants :

-action de série vers s/p, ok si cran 6 sinon avertisseur sonore

-action de s/p vers parallèle, ok si crans 11 sinon pouet !

-action parallèle vers s/p, ok si cran 12 sinon pouet !

-action s/p vers série, ok si cran 7 sinon pouet !

en mode expert bien sûr, ça serait déjà pas mal ?

 

Mais comment détecter le mode expert ?

 

A plus et merci de tes recherches.

Patrick

[Jules31 44]

N'as-tu pas déjà implémenté plusieurs modes de conduite sur ta machine ?

 

En tout cas, j'ai fait une petite recherche chez les britishs et je n'ai rien trouvé qui réponde à notre question. Au passage, je viens à peine de remarquer que tu étais inscrits chez eux

 

Je fouille dans les scripts que j'ai sur ma bécane mais à priori, ca ne donne rien. N'y aurait-il pas besoin d'écrire un script par mode de conduite, le moteur de simu changeant le bon au lancement d'une partie ? Par contre, n'ayant pas vraiment trempé dans le monde de la création d'engins moteurs réellement (j'ai juste eu quelques cours de Dede34 que je n'ai pas encore mis en application), n'y aurait-il pas un lien avec les InputMappers ? Il me semble qu'il y en a un de défini dans le core par mode de conduite.

Edited November 10, 2009 by Jules31

[pierreg 3,466]

Bonjour à tous,

 

Pour pml3, le contrôleur de type de conduite c'est :

ControlType : 0=simple, 1=intermediate, 2= expert

A+

 

Pierreg

 

[pml3 303]

Bonjour à tous,

 

Pour pml3, le contrôleur de type de conduite c'est :

ControlType : 0=simple, 1=intermediate, 2= expert

A+

 

Pierreg

 

Super intéressant.

mais un 1er essai ne donne pas grand chose avec un test :

if Call( "*:GetControlValue" , "ControlType" , 0 ) == 0 then ....

 

Tu as un exemple fonctionnel ?

 

[Erakis 147]

Bonjour à tous,

 

Désolé pour cette longue absence, je n'avais jusque-là pas trop le temps de participer plus activement.

 

Je suis très heureux que le script a pu être facilement transposé sur une loco fonctionnelle ! D'ailleurs pml3 je suis intéressé par les modifications apportées au script pour l'adaptation à ta 2D2, comme cela on pourra faire un échange de bons procédés.

 

J'ai pu quand mâme avancer un peu dans l'amélioration de mon script, et je l'ai fait passer à la v0.2 en y apportant pas mal de corrections. Celles-ci figurent en commentaires dans l'en-tête du script, mais je les rappellerai ici :

 

1) Prise en compte de la vitesse seuil d'activation de la VACMA (à régler dans la partie "constantes")

2) Prise en compte des commandes permettant de réinitialiser la VACMA ("commandes secondaires" ; à régler dans la partie "constantes")

3) Suppression de la phase d'initialisation (manque d'informations sur la procédure réelle)

 

Voici la chose : [attachmentid=1743]

 

Forcément, le script a pris de l'embonpoint ; j'espère que les itérations de la routine Update() ne vont pas trop s'allonger à cause de ça. Il y a sûrement moyen d'optimiser le code, mais ce n'est pas ma priorité ni ma spécialité. Bah, avec nos bécanes de course, aujourd'hui...

 

-------

 

Pour la gestion des mode de difficulté pour la conduite (StopGo, Intermediate et Expert), il suffit simplement, dans l'InputMapper concerné, d'attribuer un controle (ou pas) à la fonction qu'on veut utiliser (ou pas) dans ce mode.

 

Plus en détail :

 

Un InputMapper est un blueprint qui permet d'attribuer une touche du clavier ou de la souris à une commande ("control" en anglais) de la machine. Il y a un certain nombre de commandes prédéfinies, notamment la commande "Horn" est déjà attribuée au klaxon, la commande "EmergencyBrake" au freinage d'urgence, etc. La liste des contrôles préexistants est dispo ici : http://www.railsimdownloads.com/wiki/tiki-...+Reference+List

 

Cette liste de contrôles peut être rallongée à loisir grâce à l'Engine Script. Typiquement, dans mon script de VACMA, j'ai créé le contrôle "CommandeVACMA".

 

Il y a par défaut dans le jeu 3 "InputMapper" dédiés à la conduite, soit 1 par niveau de difficulté. Ce sont ces InputMapper par défaut que je vous ai proposé de remplacer avec mon "AZERTY remapper". Il est cependant possible de créer et d'utiliser des InputMappers complètement personnalisés pour une machine donnée, plutôt que ces InputMappers par défaut. C'est dans l'un des blueprints de la machine qu'on définit quel InputMapper on utilise pour chacun des 3 niveaux de difficulté (il est possible de mettre 3 fois le même si on n'a pas envie de créer plusieurs modes de conduite).

 

Imaginons que je finisse un jour mes Vespas. Je veux implémenter une VACMA dessus, mais ne veux la rendre dispo qu'en mode Expert (tout comme vous). Je crée alors une copie du blueprint correspondant à l'InputMapper par défaut pour le mode Expert ("Default_Expert.xml"), la renomme mettons "9400_Expert.xml" et place le fichier dans le répertoire Source\Erakis\Pack_Vespa\InputMappers\. Je l'ouvre dans le Blueprint Editor et je rajoute les volets qu'il faut pour piloter le "control" appelé "CommandeVACMA" (si mes souvenirs sont bons, il faut 1 volet pour l'appui de la touche et 1 volet pour le retour de la touche à son état non enfoncé). Bien sûr, ces volets doivent être assignés à la touche qui correspondra au cerclo, disons la touche "Entrée".

 

Dans l'Engine Blueprint de ma Vespa, je préciserai les contrôles suivants :

StopGo : Kuju/RailSimulatorCore/InputMappers/Default_StopGo.xml

Intermediate : Kuju/RailSimulatorCore/InputMappers/Default_Intermediate.xml

Expert : Erakis/Pack_Vespa/InputMappers/9400_Expert.xml

 

Le fait de bien avoir encadré toute la fonction de VACMA dans la condition

if Call( "*:ControlExists" , "CommandeVACMA" , 0 )
...
end

soit en pseudocode

si la commande "CommandeVACMA" existe
...
fin si

va mécaniquement désactiver cette fonction si l'InputMapper courant (càd associé au niveau de difficulté choisi) n'attribue aucune touche du clavier ou de la souris à la commande "CommandeVACMA". Comme les contrôles par défaut ont été utilisés pour ma Vespa dans les modes StopGo et Intermediate, et que la commande "CommandeVACMA" n'y est associée à aucune touche, eh bien il n'y aura pas de VACMA dans ces modes de difficulté.

VACMA.lua.txt

Edited November 27, 2009 by Erakis

[Jules31 44]

La prise en compte de la VACMA progresse bien et on n'est plus loin d'avoir un script permettant une gestion de celle-ci sur n'importe quelle machine française, et pour les InputMapper, je n'étais vraiment pas loin.

 

Si je puis me permettre de proposer l'évolution ultime qui permettrait d'implémenter l'ensemble des actions liées à la VACMA, voila ce à quoi je pense :

 

- implémenter dans le script la fonction de test de la VACMA avec prise en compte du bouton à bascule "Test VACMA" que l'on retrouve sur les boîtes à leviers des engins français. Il s'agirait donc de coller à la réalité d'une prise de service d'un conducteur sur un engin quand il doit effectuer un "test VACMA" à l'arrêt. Ce bouton agit très simplement, il active la VACMA alors même que l'engin moteur n'a pas atteint la vitesse limite de déclenchement. Cela permet au conducteur de vérifier à l'arrêt que la VACMA déclenche bien en cas d'absence d'appui ou d'un maintien d'appui prolongé comme cela se passerait en conduite en ligne.

 

Qu'en pensez-vous ?

 

Benoît

Edited November 27, 2009 by Jules31

[Spud 144]

Salut,

 

Je n'ai pas eu le loisir de féliciter Erakis pour la modification des touches avec l'azerty remapper, car c'est vraiment bien,

 

Et pour tes propositions Jules31 je suis du même avis ce serait vraiment bien.

 

Bye

 

[pml3 303]

Vite fait avant dodo ce dimanche soir ;o)

 

Bravo pour tes explications, Erakis, ca va en aider plus d'un !

 

Pour la vacma, juste un détail : pour tester le seuil de vitesse d'activation, je vais chercher la vitesse de la loco directement sur le contrôleur "SpeedometerKPH" .

 

Quant à la taille du script, je crois qu'il y a de la marge pour nos bécanes,

en tout cas j'en suis à environ 600 lignes, mais avec les lignes blanches et les commentaires !

 

Ma difficulté pour tester le mode expert, c'est que tant que l'on a pas éxécuté une commande spécifiquement définie que dans l'input mapper Expert, le script ne sait pas dans quel mode on a démarré....

Et ça complique les choses....

 

C'est pourquoi j'espérais beaucoup du contrôleur "ControlType" indiqué par Pierreg,

mais je n'en obtient rien

 

Allez salut à tous

[Spud 144]

Salut,

 

Ayant regardé une vidéo hier sur la CC40100...

 

Je vais poser une question un peu c.....

 

Serait-il possible de faire interagir la vacma avec les signaux ? avec LSSF pour la répétition des signaux en cabine ? Ce n'est qu'une supposition après c'est à voir si les signaux peuvent transmettre leur état au script de la vacma.

 

Mais en ayant lu un peu le document sur la signalisation et les possibilités offertes par le language de signalisation je me suis dis que ce serait peut être possible ?

 

Bye

Edited November 30, 2009 by Spud

[Jules31 44]

Je ne vois pas où tu veux en venir car la VACMA est totalement indépendante de la répétition des signaux.

[Spud 144]

Autant pour moi c'est sur le KVB... j'ai confondu c'est parce que si on acquitte pas le LSSF ça enclanche le frein d'urgnece... et j'ai fais l'association des deux

 

Donc serait-il il possible de faire la même chose. mais cette fois ci avec le KVB ?

 

Bye

Edited November 30, 2009 by Spud

[henrion 101]

Autant pour moi c'est sur le KVB... j'ai confondu c'est parce que si on acquitte pas le LSSF ça enclanche le frein d'urgnece... et j'ai fais l'association des deux

 

Donc serait-il il possible de faire la même chose. mais cette fois ci avec le KVB ?

 

Bye

Bonjour,

 

avec le KVB ce sera possible en grande partie mais pas dans son intégralité je pense.

on peut interagir lors du franchissement des signaux et lorsqu'on est en excès de vitesse à leur passage.

Par contre la gestion du ralentissement, je ne sais pas si cela sera possible.

Edited November 30, 2009 by henrion

[Jules31 44]

Ok.

 

Donc pour le lien avec le KVB et LS-SF :

 

Au préalable, ne te laisse pas berner par le fait que sur les engins équipés du KVB, LS-SF se situe sur le module KVB en cabine de conduite, car en fait LS-SF pour le coup n'a aucun lien fonctionnel avec le KVB. LS-SF a été déplacée sur le module KVB lors de l'équipement des engins en KVB pour concentrer en un même endroit tous les systèmes de répétitions de signaux et leurs contrôles KVB associés.

 

Donc pour le KVB et pour la répétition des signaux, oui en effet il serait intéressant le jour où ces éléments seront modélisés en cabine de les coupler avec l'état des signaux comme cela est déjà le cas avec la répétition sonore des signaux en cabine de conduite. D'ailleurs, il me semble que pml a déjà modélisé LS-SF tout comme Dede34).

 

Je crois même que pml avait tenté de contrôler LS-SF à partir du script qui traite la répétition sonore des signaux. On en avait parlé sur ce topic même il y a quelques temps je crois, mais je ne sais pas ce qu'il en est.

 

Concernant le contrôle de vitesse via des courbes de ralentissement comme le fait le vrai système KVB, cela me paraît très compliqué car comme pour le vrai système, il faudrait que le script de gestion connaisse le coefficient de décélération de la rame, la longueur de la rame, puis la distance but et la déclivité moyenne jusqu'au point à protéger. A cela, on pourrait ajouter la vitesse cible, qui peut varier suivant que l'on a affaire à une limitation de vitesse, à un 00 au visualisateur du KVB ou un 000. Toutes ces informations (hormis le coefficient de décélération et la longueur de la rame) devraient être transmises par des objets avec des liens posés sur la voie (idéalement les balises KVB déjà modélisés mais avec des liens pour transmission des informations qui leur sont propres aux engins moteurs, et il en faudrait tout un tas de balises KVB différentes pour pouvoir traiter tous les cas ...).

Cependant, on pourrait faire des hypothèses simplificatrices, mais je pense que l'on dénaturerait très vite le système KVB que l'on tenterait de développer. Tout au plus pour ne pas dégrader trop le système pourrait-on facilement ignorer la longueur de la rame, cela aurait pour impact de ne plus pouvoir contrôler le franchissement complet de la rame du point de reprise pour lever les courbes de vitesses.

Edited November 30, 2009 by Jules31