Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Erakis

Modérateur
 View Profile  See their activity

  • Content count

    768

  • Donations

    0.00 EUR 

  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Erakis

  1. Posted · Edited by Erakis

    Bonsoir à tous,

     

    Comme j'ai vu pas mal de personnes à droite à gauche avoir des problèmes de disque dur, je me dis qu'il y a peut-être des personnes qui sont dans le même cas que moi il y a 2 semaines.

     

    J'ai donc connu très récemment un gros problème de disque dur qui est devenu du jour au lendemain invisible par le BIOS de la carte mère du PC. J'ai cru qu'il était définitivement foutu et que j'avais perdu des centaines d'heures de travail...

     

    Mais non.

     

    Ce problème, dit "busy mode", apparaît (d'après ce que j'ai compris) tous les 300 allumages sur les disques durs de marque Seagate, modèle Barracuda 7200.11 et Barracuda ES.2, ainsi que leurs dérivés de marque Maxtor, type DiamondMax 22.

     

    C'est en fait un problème de firmware foireux et peut être réparé avec un peu de dextérité, un fer à souder et quelques euros de matériel.

     

    J'ai suivi le guide ici : http://forum.hardware.fr/hfr/Hardware/HDD/...et_836284_1.htm et ça a bien marché (malgré les sueurs froides).

     

    Une fois que vous aurez fait ça, votre disque redeviendra comme avant, mais il sera susceptible de connaître une rechute. Pour éviter ça, il faudra faire une mise à jour du firmware vers la version SD1A. (Tout est sur le site officiel de Seagate.)

    MAIS ATTENTION ! Si c'est sur votre disque système que vous avez le problème, alors il faudra sauvegarder tout ce qu'il y a d'important avant cette mise à jour. En effet : Windows ne va plus reconnaître la partition de boot et il va falloir le réinstaller après formatage du disque.

    En revanche, si le problème est rencontré sur un disque de stockage de fichiers, alors vous pourrez mettre à jour le firmware sans souci (heureusement, j'étais dans ce cas-là).

     

    Bien sûr, si vous avez l'un de ces disques dans votre PC, n'attendez pas qu'il tombe en rade avant de mettre à jour le firmware !!

     

    C'est assez inadmissible de la part de Seagate, l'inventeur du disque dur, qui avait pourtant bonne réputation... Il paraît que ça leur coûte une fortune en SAV, je pense que ça leur fera une bonne leçon.

     

    Bonne chance, en espérant avoir été utile. ;)

  3. Posted

    Bonsoir à tous,

     

    Je viens de lire sur le forum UKTrainSim une intervention de Derek Siddle sur un topic assez intéressant (à propos du dynamisme relativement faible des créations hors Royaume-Uni) :

     

    The key issue is access to reference material. If I could find someone to take photos of that dutch/french/NA train and get inside cab and help gather the correct sounds I would, same goes for Russia/China/India or anywhere else.

    And if you are that person... PM!

     

    En d'autres termes, l'auteur d'une partie du matériel roulant pour RS et RW serait prêt à modéliser du matos étranger pourvu qu'on lui fournisse de la doc, des photos et des enregistrements audio. Si vous avez tout ça à votre disposition mais n'avez aucune prétention créatrice, ça peut être une idée à creuser... :)

  5. Posted · Edited by Erakis

    Merci à tous les deux pour votre patience !

     

    En fait en schématisant, lorsqu'un train va entrer dans un pas d'IPCS, il faut que celui-ci soit libre et que le signal opposé soit au carré pour éviter d'avoir deux trains face à face. Or on ne peut vérifier ou donner un ordre à un signal sur une autre voie que si l'aiguillage est positionné vers cette voie. Dans ces conditions on ne sera jamais sûr qu'un train n'est pas déjà dans le pas d'IPCS dans le sens normal quand l'aiguillage fera mouvement vers l'IPCS. Je ne sais pas si je me fais bien comprendre. :D

    Erakis, pas de problème pour les explications !

    La prise de sens, c'est le fait pour une voie ou portion de voie pouvant être empruntée couramment dans les deux sens de définir le sens pour lequel les équipements sont positionnés pour assurer en toute sécurité les circulations dans ce sens. Il s'agit par exemple pour un passage à niveau d'activer les équipements permettant d'annoncer un train pour le sens qui nous intéresse et de désactiver ceux du sens contraire (je donne une liste d'équipements à activer ou désactiver dans le message 2). Une des conditions pour prendre ce sens est que personne n'ait pris le sens contraire pour éviter tout nez à nez. C'est le rôle de ce qu'on appelle l'enclenchement de sens. Que ce soit en bloc automatique ou manuel, il y a une "demande de sens", puis un "accord de sens". Une fois le train passé sur la portion de voie qui nous intéresse, l'enclenchement ne fait en général plus effet (sauf si l'agent-circulation le maintien par un dispositif adéquat, pour un autre train de même sens par exemple) et autorise toute nouvelle prise de sens. En bloc manuel, la libération de cet enclenchement s'appelle la reddition et est effectuée par l'agent-circulation (elle est soumise à contrôle visant à s'assurer que le train à bien libéré la portion de voie). En bloc automatique, la libération de l'enclenchement est automatique et est effectuée soit par circuit de voie, soit à l'aide de compteur d'essieux comptant le nombre d'essieux rentrant sur la portion de voie et en sortant.

     

    On retrouve cela aussi bien entre les gares en voie unique que sur IPCS ou voie banalisée, et la problématique est strictement la même ! Prévoir les équipements pour circuler sur une même voie dans les deux sens et éviter le nez à nez. Dans le simulateur, il me semble que c'est exactement la même chose. La problématique et les solutions pour les VU, IPCS et voies banalisées seront certainement les mêmes !

     

    Cela répond-il à ta question Erakis ? J'ai été assez clair j'espère.

    Finalement, si j'ai bien compris, la problématique est d'arbitrer quant à l'enclenchement ou non de l'IPCS en fonction du trafic au voisinage de la portion de voie susceptible d'être prise à contresens ? J'imagine que le critère pour le tracé de l'itinéraire c'est de favoriser le convoi le plus proche de la portion soumise à l'IPCS, ce qui suppose un test sur l'occupation des 1 ou 2 cantons situés de part et d'autre de cette portion ?

     

    Histoire de comprendre la difficulté à implémenter la chose dans RailWorks : on ne peut pas connaître l'état d'occupation des cantons qui ne sont pas situés sur l'itinéraire qui est tracé, c'est bien ça ?

     

    Si c'est ça, effectivement je comprends votre désarroi.

     

    C'est justement ce que je veux vérifier parce que normalement c'est mathématique à chaque franchissement de signal on incrémente ou on décrémente de 1. Si cela ne se fait pas je veux comprendre pourquoi. j'utiliserai le déboggage du signal.

     

    Si cela ne semble pas poser de problème pour un changement de loco par contre pour deux automoteurs qui s'assemblent je pense que c'est plus problématique.

     

    Bonne soirée.

    Pour la gare, je comprends le besoin, mais comme Erakis, je pense que la table d'occupation est bien mise à jour aussi bien dans le cas d'un attelage qu'un dételage.

    J'ai flâné un peu du côté du forum UKTrainSim, et apparemment Henrion tu as raison : par défaut, il semblerait que la table d'occupation du canton n'évolue pas en fonction des différents attelages et dételages qui peuvent s'y produire. Ceci dit ce que j'ai lu s'applique à Rail Simulator et a été écrit en 2007 ; je ne sais pas si le problème a été traité depuis.

     

    Ceci dit je pense qu'il y a moyen de ruser, peut-être en remplaçant la table d'occupation par une variable booléenne gEstOccupe qui ne pourrait prendre que les valeurs true et false, et qui ne pourrait retourner à false que lorsque la longueur cumulée des convois sortant du canton est au moins égale à la longueur cumulée des convois qui y sont entrés. (Je crois que la longueur des convois qui passent un signal est accessible avec la fonction OnConsistPass().)

     

    Bon, en pratique ce n'est probablement pas aussi simple ! :)

     

    Bonne soirée à vous également.

  6. Posted · Edited by Erakis

    En fait il faut vérifier le fonctionnement des gOccupationtable[] Exemple: si un automoteur arrive sur un quai il met la gOccupationTable à 1. Si un deuxième automoteur arrive sur le même quai il va incrémenter la gOccupationTable et la mettre sur 2. Si les deux automoteurs font la jonction, en sortant de la gare il n'y aura qu'une décrémentation de 1 de la gOccupationTable qui va rester à 1 et donc le signal va rester au rouge alors que le quai est vide. Il en va de même en cas de changement de motrice. Mais comme je ne suis pas sûr de ce fonctionnement qui serait logique, il faut vérifier avec des scripts parfaitement au point.

    Je pense quand même que les concepteurs du jeu ont prévu ce cas de figure, qui apparaît finalement à chaque attelage ou dételage : à ma connaissance le sémaphore de protection du canton où a eu lieu un dételage de wagons ne s'ouvre pas lorsque la loco en HLP quitte ce même canton. Probablement que le jeu compte le nombre de convois différents sur chaque canton (ou sur les cantons adjacents) à chaque fois qu'un signal de protection de canton est franchi. Non ?

  7. Posted · Edited by Erakis

    PS : A ceux qui nous lisent, qui on les bases et qui s'intéressent au sujet, n'hésitez pas à intervenir ! Ce n'est pas juste un dialogue entre moi et Henrion !

    J'ai bien fait d'appuyer sur la touche F5 ! Enfin, vous allez peut-être le regretter... :)

     

    ...parce que je ne vais probablement pas faire avancer le schmilblick : quelle est la problématique de la "prise de sens courant" ? (Si ça ne vous dérange pas de m'expliquer, bien sûr.)

  8. Posted · Edited by Erakis

    Bonjour à tous,

     

    Comme Richard, je pense qu'il y a une tendance générale et malheureuse, dans notre communauté, à être trop exigeant trop tôt.

     

    Je pense que la plupart de ceux qui ont abandonné MSTS pour RS/RW sont ceux qui trouvaient trop rédhibitoires les limitations de MSTS, notamment pour ce qui concerne le moteur graphique. Il n'y a qu'à voir la proportion d'esthètes parmi ceux qui se sont investis dans la création de matériel pour RS/RW ; du matériel souvent très propre, ultra-réaliste (sur le plan graphique du moins), etc. En pensant bien faire, ceux-ci défendent leur point de vue qui consiste à ne donner que le meilleur de soi-même, ce qui n'est probablement pas sans décourager un certain nombre d'apprentis créateurs de sortir autre chose que du matériel de compétition pour RS/RW, de peur de ne pas se sentir à la hauteur. Ce n'est pas, je pense, une attitude très bénéfique au développement de ce simulateur, surtout quand celui-ci n'en est qu'à ses débuts : comme pour tous les autres simulateurs, la création pour RailWorks ce n'est pas seulement des polygones bien agencés et de belles textures, mais aussi du son, des animations, de la programmation et plus généralement tout le savoir-faire correspondant à la prise en main d'une interface riche mais complexe (je parle du système par "blueprints").

     

    Il faut à mon avis garder à l'esprit que la création de contenu médiocre sur le plan graphique peut par ailleurs faire progresser toute la communauté sur d'autres plans, et permettre à l'auteur de partager ses expériences et démontrer à son auditoire l'étendue des avantages que peut présenter RS/RW par rapport aux autres simulateurs : c'est en forgeant qu'on devient forgeron, et Richard en est un bon exemple quand on voit la progression de son travail au fil des années pour MSTS, sans compter ce qu'il a pu apporter à la communauté. Et il est loin d'être le seul dans ce cas.

     

    Bref, je pense qu'il faut clamer haut et fort qu'on ne jugera pas le travail des auteurs et que, quel que soit le résultat obtenu, ce sera une expérience supplémentaire et bonne à prendre pour la communauté. Je pense qu'il y a aujourd'hui trop peu de créateurs pour RS/RW pour que la communauté puisse se permettre un tel ostracisme, aussi involontaire puisse-t-il être. Malheureusement, l'ostracisme existe aussi dans la communauté d'en face ; je pense que, pour convaincre les personnes de talent qui ont créé pour MSTS de venir nous rejoindre et nous aider, les meilleurs argumentaires viendront de ceux qui ont trempé durablement dans la création pour les deux simulateurs. Le principe du cercle vertueux, finalement.

     

    Pour une partie de la communauté d'en face, il y a plein de bonne raisons pour rester fidèle à MSTS et ne rien entreprendre pour RS ou RW. Ne leur donnons pas des arguments supplémentaires.

     

    "My two cents", comme disent les Anglais Américains...

  10. Posted · Edited by Erakis

    [EDIT]Ah m.... alors, j'ai confondu TVM et KVB, la honte ! :(

     

    Du coup ce qui a été écrit précédemment et ci-dessous n'a plus aucun sens.

     

    [inutile]

     

    Je parlais de la balise KVB censée contenir l'info de déclivité moyenne jusqu'au signal suivant.

     

    Le problème pour calculer la déclivité moyenne résiderait (aussi) dans la connaissance de la distance au prochain signal et je ne suis pas sûr qu'une telle fonction soit accessible depuis le script du signal (il faut que je me replonge dans la doc). Comme solution de rechange envisageable, si on peut calculer la différence en Z, alors on peut aussi calculer la différénce en racine(X²+Y²) ; mais ça ne pourrait pas convenir pour de petits tortillards de montagne (surtout si les cantons sont longs) puisque cette méthode consiste à faire l'approximation que la ligne est droite de la balise jusqu'au signal...

     

    [/inutile]

     

    Désolé...

     

    PS : j'y connais rien en TVM, je préfère y aller par étapes. :)

  11. Posted

    Bonjour,

     

    Effectivement, la TVM semble tout à fait implémentable dans RW, y compris avec les courbes de vitesse. Toute la théorie est couchée sur le papier de mon côté. Bien sûr, il reste quelques écueils possibles : par exemple, je ne suis pas sûr qu'on peut demander au script de "mesurer" la différence d'altitude entre la balise et le prochain signal.

  13. Posted

    Julien,

     

    En fait ce qui pose problème ce n'est pas l'extrusion en elle-même (on peut parfaitement en maîtriser tous les paramètres dans SolidWorks : le polycount peut être jusqu'ici parfaitment maîtrisé), mais la torsion que j'applique ensuite à chacun des câbots pour leur donner un aspect réaliste (qu'ils ne soient pas tous parallèles).

     

    Je vois 2 solutions possible :

    - extruder le profil sur une esquisse 3D et non une esquisse plane afin de rendre compte de la torsion dès l'opération d'extrusion (jamais fait) ;

    - appliquer un modificateur torsion dans 3DS plutôt que SolidWorks (jamais fait non plus).

     

    Je testerai ça dans la semaine.

     

     

    Sinon, si tu veux gagner du temps, j'ai un "business" d'am18

    Overload ! TILT ! Same player shoots again ! :D

    (Traduction : je suis volontiers preneur.)

     

    Merci pour ton aide.

     

    A+

  14. Posted

    Rebonjour,

     

    "Le frais" ? Connaissais pas cette expression. :)

     

    Merci aussi ZvinCe pour les encouragements !

     

    Comme promis, ci-dessous un rendu de l'état d'avancement actuel (cliquez pour agrandir) :

     

    [attachmentid=1855]

     

    Ajouté :

    - éléments de toiture sauf pantos et parties électriques ;

    - poignées de portes basses (donc après rénovation) ;

    - cloisonnement de la baie de ventilation latérale en 6 cellules (il faudra aussi que je teste avec un côté de caisse monobloc, càd non percé, avec une couche alpha, mais j'ai eu peur que ça rende pas terrible -> des avis ?).

     

    J'ai noté un problème de polycount au niveau des câblots d'UM : la fonction "torsion" de SolidWorks (pour pas avoir des câblots parallèles) m'a rajouté des polys en pagaille... Va falloir corriger ça histoire de soulager nos précieuses cartes graphiques. Il y a sûrement moyen de faire ça facilement dans 3DSMax.

    023.jpg

  16. Posted · Edited by Erakis

    [EDIT] Merci à vous deux pour vos encouragements ! :) (Note pour gmarie1 : ah oui bonne idée pour simplifier le texturage. Une petite texture de rouille appliquée partout et hop ! l'affaire est dans le sac. :P )

     

    J'ai oublié de donner quand même quelques précisions (teintées d'un optimisme de bon aloi) : ici n'est présentée que la 9600 mais j'essaierai de proposer également les autres variantes :

     

    - 9400 avec traverses d'origine et jupes ;

    - 9400 à moustaches et khôl ;

    - 9400 à toiture basse et réhausses de panto ;

    - 30000 avec panto monophasé et 3e fanal (cadeau bonux).

    Le tout dans les livrées bleu-vert d'origine, Arzens, Béziers, Béton et TGV.

     

    (Idéalement.)

     

    Je précise aussi que les bogies sont temporaires, faits à la va-vite pour la photo, mais ils seront peaufinés.

  17. Posted · Edited by Erakis

    Bonsoir à tous, et bonne année 2010 !

     

    J'en vois déjà qui maugréent : "Comment ? Encore une électrique ? Et même pas un mythe comme la 6500 mais une simple, ridicule, oubliable petite Vespa ?"

     

    Hé oui, tout ça parce que je suis grand fan du Massif Central, en particulier des Causses et de la ligne qui va avec. J'avoue, j'aurais pu tout aussi bien me lancer dans une 67400 ou un X 2800, mais j'ai préféré me faire la main sur un matériel pour lequel les simmers exigeants que vous êtes ne m'en voudrons pas trop si je rate mon coup (ou, pire, si je ne vais pas jusqu'au bout). Imaginez les retombées si je me plantais sur un truc mythique comme un bleu d'Auvergne !

     

    Bon, j'avoue que la relative simplicité de ces locos m'a encouragé à commencer avec celles-ci.

     

    Ces rendus ne sont pas les derniers (j'ai depuis retravaillé un peu la caisse et notamment la toiture où il ne manque plus que les pantos), mais le plus récent n'a que 2 semaines environ. Explication : je ne suis pas chez moi (j'ai déménagé et je n'ai pas encore internet) et j'ai oublié de mettre la dernière version sur la clé USB... Vous devrez donc vous contenter de réchauffé d'ici la fin de la semaine ! :lol:

     

    Mais voyez plutôt le massacre. D'abord il y a eu...

     

    [attachmentid=1850]

     

    et un peu après...

     

    [attachmentid=1851]

     

    et enfin...

     

    [attachmentid=1852]

     

    Et puisqu'il paraît que la mode est à l'« augmented reality » (oui je sais c'est pompeux), je me suis permis un petit délire :

     

    [attachmentid=1853]

    Image d'origine réalisée par Sylvain Bouard. Lien : www.vuesurlavoie.com

     

    Si vous avez des commentaires (trop de polys par ici, pas assez par là...) : n'hésitez surtout pas !

     

    A bientôt pour les prochaines nouvelles !

     

    [EDIT] avec une compression JPEG un peu moins violente...

    9600_001.jpg

    9600_008.jpg

    9600_013.jpg

    9600_019.jpg

  20. Posted · Edited by Erakis

    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

  21. Posted · Edited by Erakis

    Voici un extrait des règlements :

    Principe

     

    La plupart des postes de conduite sont équipés de la Veille Automatique à contrôle de maintien d'appui (VA).

     

    La VA provoque l'arrêt des trains par déclenchement des opérations d'arrêt automatique (ouverture du disjoncteur, déclenchement QT ou arrêt moteur et mise à l'atmosphère de la CG) :

    - en cas de défaillance du conducteur, lorsqu'il relâche de façon prolongée (plus de 5 secondes) l'un des appuis de veille automatique;

    - lorsque le conducteur ne manifeste pas son activité au cours de la conduite du train (manipulateur de traction, ...) alors qu'il maintient l'un des appuis de veille automatique (une minute environ).

     

    Fonctionnement

     

    La VA est inactive à l'arrêt. Une fonction de l'appareil indicateur de vitesse la rend active au-dessus d'un seuil de vitesse (variable selon le type d'indicateur de vitesse et ne dépassant pas 15 km/h ).

     

    A défaut d'appui par le conducteur sur l'un des dispositifs de VA , il s'en suit :

    - le déclenchement des opérations d'arrêt automatique;

    - sur les lignes équipées de la radio sol-train, lorsque l'engin moteur en est équipé, l'émission de l'alarme VA. Cette alarme VA, destinée à alerter le régulateur, peut avoir pour origine une défaillance physique du conducteur.

    Merci Jules pour le complément d'infos.

     

    Je n'avais notamment pas compris que l'alerte de maintien prolongé pendant 55/60 secondes n'était valide qu'en l'absence d'actionnement des manipulateurs de traction et autres (d'ailleurs, y a-t-il une liste des interfaces homme-machine prises en compte par le calculateur de VACMA ?). J'avais plutôt l'idée (floue) que l'actionnement régulier de ces manipulateurs permettait de s'affranchir complètement de l'actionnement de la commande de VACMA ; c'est peut-être le cas mais ce n'est pas ce que je comprends du règlement que tu as recopié ici. De toute façon cet aspect n'est pas (encore) implémenté dans mon script.

     

    Pour le coup de la vitesse seuil de fonctionnement de la VACMA, y a-t-il un voyant ou un signal sonore qui permet de prévenir le conducteur de l'armement de la VACMA ? Si on imagine un train en phase d'accélération et que le seuil de vitesse est atteint plus vite que prévu, je doute qu'on vienne stresser le conducteur avec d'emblée le retentissement du klaxon de la VACMA et les 2,5 secondes imparties avant FU... Mais je me trompe peut-être ?

  22. Posted · Edited by Erakis

    Concernant tes interrogations sur le fonctionnement de la VACMA et en particulier son initialisation, voila une copie de mon précédent post qui en parle :

    Benoît, effectivement j'avais lu ton post, mais comme tu n'étais pas sûr... Par contre, tu dis que la VACMA se déclenche à partir de 5 km/h, mais est-ce que ça veut dire qu'elle se désactive dès que la vitesse passe en-dessous de la barre des 5 km/h ?

     

    Pour les temps d'appui et de non appui avant sonnerie/klaxon puis FU, je me suis trompé sur une valeur (glanée ici) : le temps entre la sonnerie et le FU en cas de maintien prolongé est de 5 secondes et non 2,5 secondes comme je le croyais. A la ligne 150 il faut donc remplacer la valeur de 57.5 par 60.

     

    Je te solliciterai surement dès que j'aurais avancé sur la cabine de 4200 que j'envisage de modéliser. Pour les nez cassés par contre, sans cabine...

    La perspective de passer un jour au-dessus de la Truyère en BB 4200 me fait dire : avec plaisir !

     

    Par contre je ne suis pas certain qu'il y ait besoin d'un bouton actif supplémentaire dans la cabine (et donc une cabine spécifique) pour profiter d'une commande supplémentaire.

     

    Il faut vraiment que je me fasse une machine "bac à sable" pour tester tout ça...

  23. Posted · Edited by Erakis

    Bonjour à tous,

     

    J'ai suivi le début de ce topic et je me suis dit que l'implémentation de la VACMA serait un bon entraînement à la rédaction de scripts Lua.

     

    Vous trouverez en pièce jointe ce que j'ai pondu, avec force commentaires.

     

    Pour la lecture de ce fichier, je vous conseille le génial Notepad++ (libre et gratuit). Pour voir tous les commentaires sans avoir à jongler avec l'ascenseur horizontal, je vous conseille une résolution de 1680 pixels minimum en largeur (et j'aime bien le thème de coloration syntaxique "Deep Black"). Dans tous les cas, il vaut mieux désactiver le retour à la ligne automatique.

     

    [attachmentid=1678]

    (Je ne suis pas arrivé à joindre mon fichier avec l'extension « .lua », donc vous n'aurez qu'à supprimer l'extension « .txt » pour avoir la bonne mise en forme dans Notepad++.)

     

    Ce programme ne pourra fonctionner qu'avec la création d'un InputMapper contenant le contrôle « CommandeVACMA », ainsi qu'avec la création de 2 contrôles sonores « KlaxonVACMA » et « SonnerieVACMA ».

     

    Il y a une partie, située entre les lignes 130 et 140, qui correspond à la phase d'initialisation de la VACMA. Ce que j'ai mis, c'est une phase de 5 secondes pendant laquelle le klaxon retentit ; au-delà, une pression sur la commande de VACMA (cerclo ou autre) arrête le klaxon et arme la VACMA. Problème : c'est complètement inventé et je n'ai aucune connaissance de la façon dont se passe, à la SNCF, la phase réelle d'initialisation de la VACMA.

    Pour le reste (phase de fonctionnement), il est également possible qu'il y ait des erreurs. Notamment, je ne suis pas sûr que la VACMA soit active dès 0 km/h.

    Je suis donc preneur d'informations complémentaires sur le fonctionnement réel de la VACMA afin de maximiser le réalisme de l'implémentation de la VACMA dans RW (ou RS). Apparemment le règlement UIC 641 et le référentiel infrastructure IN 2695 contiennent toutes les infos, ce dernier IN 2695 n'étant malheureusement pas disponible dans la base de données documentaire de www.securite-ferroviaire.fr contrairement à beaucoup d'autres.

     

    Je recherche également quelqu'un pouvant me donner accès au code source de son matériel moteur afin que je puisse faire un essai sur une "vraie" machine. Bien sûr, les créateurs sont encouragés à essayer de leur côté avec leurs propres créations (avec le code ci-joint).

     

    S'il y a des "codeurs" qui passent dans le coin et s'ils daignent me consentir un peu de leur temps libre, je les encourage à me faire part de leurs suggestions.

     

    Merci d'avance et bonne lecture ! :)

    VACMA.lua.txt

×