Salut Cyril,
ril86 a écrit:Voici quelques idées de développement pour alimenter la pile de Jp
:
Ca tombe bien, je commençais à m'ennuyer
ril86 a écrit:_Commande événementielle, soit:
Pouvoir lancer une action ou une suite d'actions en fonction d'un ou plusieurs évènements type:
-Détection d'une situation genre position d'un ou des trains ou rebouclage d'un itinéraire.
-Temporisation déclenchée par le démarrage du mode run ou autre.
Les actions générées pourraient déclencher des fonctions sur un/des décodeurs loco ou accessoires. (Je soupçonne que les actionneurs sont là pour ce genre de choses).
Nous avions abordé ce sujet avec le regretté JYL. En résumé, c'est l'ouverture et l'extension du mécanisme de sécurité actuellement câblé dans le simulateur.
C'est une excellente idée, et bien sûr, un axe d'évolution de CDM-Rail. Mais en même temps, c'est une modification énorme de la structure du programme.
Et c'est typiquement le genre d'évolution que je ne ferai pas avec l'architecture actuelle de CDM-Rail (trop gros, trop monolithique). Par contre, ça rentrerait dans le coeur de simulation de CDM-Rail++ (voir coin des développeurs).
Mon problème actuel, comme je l'ai déjà dit, c'est d'arriver (comme je suis le seul développeur) à gérer à la fois la maintenance et la poursuite de la mise au point sur la version actuelle, tout en cherchant à migrer vers la nouvelle architecture.
Autrement dit, à chaque fois qu'une fonctionnalité nouvelle est introduite, je cherche à faire en sorte qu'elle soit réutilisable dans la nouvelle architecture, de façon à pouvoir migrer progressivement de l'architecture actuelle à la suivante.
Dès que j'aurai convergé suffisamment sur ces questions d'interaction entre contrôleurs (ma priorité absolue actuelle, parce que c'est vraiment ce qui coince le plus sur le programme), j'avancerai sur l'aspect distribution de CDM-Rail sur plusieurs machines avec plusieurs postes de commandes et de visualisation. Tu vas me dire que ce n'est pas ce dont tu parles, mais en fait, ça passe pour moi par le même mécanisme, à savoir une FIFO de commandes beaucoup plus large que le jeu actuel, et qui puisse passer par réseau.
... ET une étape clé pour aller dans ce sens, c'est ce que nous avons démarré avec l'utilisation à distance d'un portable, ou d'une console Nintendo.
Désolé si c'est un peu fumeux. Mais en gros, la réponse c'est:
- ce dont tu parles est trop gros pour le greffer sur CDM-Rail actuel. La difficulté est presque plus de faire un éditeur convivial pour définir ces conditions et enchainements. Tu vois le mer... de la définitions des itinéraires. Eh bien, le risque c'est d'avoir ça au carré
- mais ça pourrait aussi être un logiciel satellite qui communique avec l'exécution de CDM-Rail via TCP-IP, donc soit sur une autre machine, soit évidemment sur la même.
ril86 a écrit:-Complément de la fonction "Liste des éléments de voies":
Avoir les longueurs de voie flexible d'indiquées dans la liste.
Pouvoir remplir une colonne "stock" et avoir le delta entre le "stock" et les éléments implantés sur le dessin (type Raily).
C'est une bonne idée, et en plus, facile à mettre en oeuvre. Je peux facilement calculer la longueur totale des rails hors éléments de bibliothèque.
ril86 a écrit:-Intégration et pilotage d'un réseau Car system (ça peut rejoindre ou intégrer la première idée: détection/condition => action(s)).
Oui, ça pourrait probablement entrer dans le cadre de ce qu'on discutait plus haut.
Il ne faut pas hésiter à en discuter. Toutes ces discussions m'aident à me clarifier les idées sur la façon d'organiser la suite.
JP
