Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - DDEFF

Pages: 1 2 [3] 4 5 ... 55
31
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 06:05:10 pm »
Je suis d'accord qu'on n'a pas l'utilité du TCO pour l'instant.
Je l'ai dessiné dans l'éditeur , en 2 versions (Une pour vérifier les infos et une pour m'en servir dans le gestionnaire.

Je lis un répertoire dans lequel des fichiers sont identifiés (dont le JSON et le TCO), alors je lis tout.
Mais je ne ferai rien avec le TCO pour l'instant, évidemment.

Merci pour ton aide

Denis :P

32
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 05:19:16 pm »
Je vais essayer de lire le JSON, en mettant ton programme un peu "à ma sauce", mais en gardant les écritures sur une ligne quand je les comprends.
C'est plus compliqué quand tu fais sauter des accolades (dans les if, j'ai un peu de mal). Mais c'est assez clair.

Je récupérerai aussi le TCO sous forme de tables (j'aurais pu faire une seule table, mais pleine de vides) car je n'utiliserai pas de tube ni de messages.

On va voir ce que ça donne, ça sera déjà pas mal.

J'ai remarqué une subtilité dans le JSON pour les voisins des zones :
Tu les vois comme une arrayList de plusieurs ArrayList alors que moi, je le voyais comme un objet d'ArrayList. C'est hyper simple à corriger dans l'éditeur_JSON.
Il faudra me laisser un peu de temps.

A suivre
Denis :P

33
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 04:55:15 pm »
C'est assez étrange : dans ton programme, il n'y a pas de "Class" ...
En fait, la description des objets se fait dans l'onglet JSON, JSONObject.

Je vais essayer de lire le JSON, en l'écrivant un peu plus à ma

34
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 12:59:06 pm »
J'ai compris !

La zone, elle, a le nom du signal et s, c'est le signal.

Denis

35
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 12:32:23 pm »
Merci, c'est parfait. Ce sera très utile.

Analyse de l'onglet json :

On crée un objet "json" qui est tout ce qui est entre les accolades principales
On crée des objets contenus dans le JSON (zones, signaux, …)
On lit tout le JSON d'un seul coup avec lectureJson(String f);
La syntaxe "lectureJson(no==1?"Z1.pde":"Z2.pde");" veut certainement dire si no==1, on lit Z1.pde, sinon on lit Z2.pde.
Après, on lit tous les "grands" objets du JSON (zones, aigs, …) avec getJSONObject
Subst(json); sert à traduire les textes clairs pour les humains en nombres plus compacts et faits pour le programme.
Suit l'initialisation des clés de chaque objet : etatZone(), trainZone(), verrZone()
Une variable String s est déclarée et on va chercher dans le JSON, le signal côté impair qui va aller remplir s. Et si s n'est pas null, on fait ZoneSign(s,z);, ce qui nous donne la zone du signal correspondant. Sauf que dans le signal du JSON, il n'y a pas de zone du signal...

Denis

36
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 10:12:05 am »
C'est bien la partie que j'avais lue.
Mais tu as une notation très compacte, avec des variables à une seule lettre qui sont très efficaces, je le reconnais, mais un peu dures à lire.
Et je pense que tu es plus dans du Java que dans du Processing (tu fais appel à Java dès le début) et c'est parfois déroutant pour moi.

Ex :
  for (String z : (Set<String>)zones.keys()) { String s; // pour toutes les zones     
    etatZone(z,LIBRE); // etat libre
    trainZone(z,null);   // pas de train
    verrZone(z,null); // pas de verrou (null) (sinon "nom" d'itineraire pour zones)
   
    if ((s=signIZone(z))!=null) zoneSign(s,z); // a voir (utilite)
    if ((s=signPZone(z))!=null) zoneSign(s,z);// zone du signal dans signal
  }

Je ne comprends pas la syntaxe de la première ligne : De quelles "keys" parle-t-on ?
La dernière ligne avec un "=" et un "!=" presque dans la même parenthèse m'est incompréhensible...

J'utilise beaucoup de void XX () {} et très peu de int XX () { return ...}, String XX () {return...}, tout l'inverse de toi.
Comme disent les jeunes, il y a un "gap" entre nous au niveau programmation...

Denis

37
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 10, 2025, 09:19:44 am »
Bonjour,

Merci pour ces précisions.

Quand je disais "dans le setup", c'était sous forme de liste, du même type que les voisins de zones dans le JSON, en tenant compte, justement, de la position des appareils de voie.
Mais je me rends compte que ça ne ferait pas avancer le problème.
C'est effectivement dans la classe Signal que ce sera au meilleur endroit.

J'avais bien vu dans ton programme que la lecture du JSON était très courte (quelques lignes) et je n'avais pas saisi.

Dans Processing, si j'ai bien compris, il y a deux fonctions qui lisent (ou écrivent) soit un objet {...}, soit une ArrayList [..., ...].

Mais vu le mélange complexe d'accolades et de crochets qu'il y a dans un JSON, je ne m'y retrouvais pas et c'est pour ça que je n'ai pas utilisé les fonctions d'écriture dans la construction du JSON dans l'éditeur.
J'ai donc fait tout le travail "à la petite cuillère", ce qui est très compliqué, très long et pas satisfaisant du tout.

Donc, oui, je préfèrerais qu'on mette les infos du JSON dans des objets avant de les utiliser.

On garderait la lisibilité du JSON par un humain (par rapport à une table), mais on perdrait la logique interne du JSON qui, justement, permet de "travailler dedans".
Je ne dis pas que j'en viendrai à "travailler dedans", plus tard, quand j'aurais bien intégré toutes les subtilités du JSON.

Merci pour ton aide

Denis :P

38
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 07:08:54 pm »
Signal voisin d'un signal : ça dépend des itinéraires.

Un signal est dans une zone. On a les voisins de la zone en fonction des positions des appareils de voie dans le JSON.
Donc, on peut calculer le signal voisin.
On pourrait le faire dans le signal du JSON ou alors dans le setup du gestionnaire.
C'est facile à ajouter dans le JSON, mais je pense que ça sera redondant. Je trouve que ça serait mieux dans le setup.

JSON : est-ce qu'on travaille directement dans le fichier ou est-ce qu'on extrait les infos dans des objets et on travaille dans les objets ?

Denis

39
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 05:42:06 pm »
Mais on peut faire les deux, justement.
Je comprends mieux quand on applique à un cas concret.

On aura besoin d'objets, de leurs liens et d'explications au fur et à mesure. Je ne veux pas me presser.

Tu as démarré par les signaux et je pense que c'est une bonne piste.

1°) De quels objets on a besoin pour les signaux ?
2°) Quels lien y-a-t' il entre eux ?
3°) Comment rentrer les infos du JSON dans ces objets ?
Et peut être d'autres choses ...

Denis

40
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 04:54:47 pm »
Il faut déjà faire la liste de tous les objets dont on aura besoin.

Et, "accessoirement", il faut lire le fichier JSON pour affecter les bonnes informations aux bons objets.
La façon dont j'ai généré le JSON montre clairement que je n'ai pas utilisé les fonctions JSON de Processing parce que je ne les ai pas vraiment comprises.  ::)

Denis

41
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 04:33:01 pm »
On a donc le régulateur qui est, en quelque sorte, une "surcouche" du gestionnaire, lequel gère uniquement la sécurité et dit si telle opération est réalisable ou non.
Ai-je bien saisi ?

Denis

42
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 03:37:18 pm »
Peux-tu être plus précis ? Quelques exemples ?

Denis

43
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 03:24:57 pm »
Alors j'ai un problème. Il fait quoi, le gestionnaire ?

Denis

44
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 09, 2025, 03:07:56 pm »
Bonjour,

Avant de me lancer dans les lignes de programme, je vais faire un cahier des charges de ce que je veux faire comme gestionnaire.

Le conducteur du train part avec sa Feuille de Route qui lui donne un but et des gares de passage (entre autres). Il y a aussi les horaires sur lesquels je ferai l’impasse.

Il faut donc un objet "Feuilles de route" qui engrange toutes les feuilles de routes actives à un moment donné.

Dans les gares, il faudra des itinéraires. Objet "Itineraire"

A noter qu’on ne choisit pas tous les itinéraires de toutes les gares entre le départ et le but avant le départ (comme je faisais dans mon ancien gestionnaire).

J’ai attendu suffisamment longtemps dans ma vie devant les panneaux d’affichage pour savoir que les itinéraires se décident "au dernier moment".

Un itinéraire est d'abord enregistré : on mémorise la voie d'entrée et la voie de sortie dans toutes les gares traversées. Quand le train sera à proximité de la gare, c'est là qu'on pourra lancer la recherche d'itinéraire pour cette gare, ce qui donnera la voie choisie dans la gare, à ce moment.

Il y a un classement des priorités des trains.

Train de voyageurs rapide (Express) ou lent (Omnibus)
Train de marchandises rapide (Régime Accéléré) ou lent (Régime Ordinaire).
On a EX > OM > RA > RO à la SNCF.
A noter qu'en Amérique, les trains de marchandise sont prioritaires sur les trains de voyageurs.

Puisqu'on parle d'itinéraires, on ne peut pas accéder à un appareil de voie donné directement.
Pas de boutons pour changer la position d'un appareil de voie sur le TCO, ni de clic sur un écran.
On doit passer par un itinéraire.

Quand l'itinéraire se forme, il modifie la position des appareils de voie (si c'est possible) et interdit aux itinéraires incompatibles de se former (c'est l'enclenchement).

Comme il y a souvent plusieurs itinéraires possibles entre un point A et un point B, il faut trouver une façon de les prioriser pour qu'un seul itinéraire soit proposé, celui qui a la plus forte priorité. Sachant aussi qu'un itinéraire d'un express passe avant celui d'un omnibus, même si l'omnibus est arrivé avant. De plus, un express passe prioritairement sur l'itinéraire le plus direct.

La priorisation ne peut pas être l'itinéraire le plus court, sinon un omnibus peut bloquer la gare. D'où le poids des appareils de voie dans le fichier "Zones"

Une fois les appareils de voie en position, on peut décider de l'affichage des feux puisqu'ils tiennent compte de la position des appareils de voie et des occupations des trains.

Une fois que les feux sont affichés, on peut lancer les trains, les faire ralentir et s'arrêter puisqu'ils obéissent aux feux.

Et on recommence au début en regardant si de nouveaux itinéraires sont possibles après le déplacement des trains.

Denis  :P

45
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: avril 08, 2025, 05:52:07 pm »
Merci Pierre.

Ce post arrive pile au bon moment : je vais pouvoir commencer le gestionnaire sur de bonnes bases.  ;)
Et quand j'aurais bien compris, je reviendrai sur le JSON.

Commençons par le signal. On a une classe Signal () {} qui a deux méthodes ouvrir () {} et fermer () {}.
Effectivement, "ouvrir un signal" n'est pas assez précis, mais il faut que la méthode existe dans l'objet Signal dont on va hériter, quitte à être vide.

"Ouvrir un signal" a deux fonctions : allumer les LED qui vont bien sur le signal et agir sur l'état du train correspondant.
J'imagine qu' "Ouvrir" fait partir le train et "Fermer" l'arrête ?
Mais on peut aussi ouvrir un ralentissement ? Ou ouvrir un avertissement ?

Je pense que oui, par référence aux signaux mécaniques.

J'imagine qu'il faut un objet Cible() {} pour indiquer comment traduire "C" en positions de LED à allumer ?

Denis  :P

Pages: 1 2 [3] 4 5 ... 55