Vos souhaits / remarques sur l'évolution d'OR

Discussions générales sur ORTS.

Modérateur : Modérateurs

Règles du forum
Si le sujet que vous souhaitez ouvrir concerne un problème ou une question qui nécessite une aide active de la part des membres du forum, merci de le poster dans la rubrique "ORTS: Aide et recherche", et non dans la présente rubrique!
BB22210
Messages : 590
Enregistré le : 25 oct. 2004 23:34
Localisation : Isère (38)
Contact :

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar BB22210 » 02 févr. 2017 19:13

Hello,

Désolé je me suis trompé de Forum <2< <1< :arrow:
bye
Guignol et ficelle de préférence ...

Avatar du membre
fred37
Messages : 464
Enregistré le : 29 sept. 2006 15:29
Localisation : Savigné Sur Lathan (37)
Contact :

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar fred37 » 11 févr. 2017 16:24

Bonjour à tous,
On pourrait pousser le bouchon un peu plus loin comme changer le standard des sons du Wav par du MP3 (ou OGG) bien moins gourmand. Comme cela été fait pour les textures en DDS...

Tout en gardant la configuration des SMS actuel, la modification permettrai de monter en gamme la qualité des sons sans mettre à genoux les ressources de OR (qui semble plus que limité, car nombreux sont les plantages faisant référence aux sons dans les LOG, nous sommes pas mal a avoir remarqué le problème, et même avec des sons et des SMS datant de nombreuses années).

Faire une comparaison d'un son Wav en qualité CD à 44khz stéréo 16 bits:
60 (secondes) * 44000 (taux d’échantillonnage) * 2 (stéréo) * 2 (16 bits = 2 octets) = 10.56Mo
La même chose en MP3 on arrive à 1.373Mo pour 60s avec un bitrate de 192kb/s

Donc environ un 1/10ème de poids en moins, ce qui peut être significatif, pour la conception de sons détaillés, et puis entre nous se serait une évolution.

@+
Fred.
Modifié en dernier par fred37 le 12 févr. 2017 14:55, modifié 1 fois.

Avatar du membre
RM77
Testeur
Messages : 1106
Enregistré le : 03 août 2005 8:19

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar RM77 » 12 févr. 2017 12:28

Bonjour à tous

De retour après une absence un peu prolongé, j'ai relu ce qui se dit ici et je suis surpris qu'à aucun endroit on ne parle de la signalisation et de sa programmation.

Le RGS a écrit :Certains ordres ou informations intéressant la sécurité de la circulation sont donnés aux
agents concernés, en particulier aux conducteurs, à l’aide de signaux.
Tout agent, quelle que soit sa fonction, doit obéissance passive et immédiate aux
signaux le concernant

La programmation avec ce mini "C" et les scripts associés ( sigcfg et sigscr.dat ) ne me gêne pas du tout et est à la porté de tout le monde en quelques minutes. Mais pourquoi en Unicode ??? (sigcfg) Comme pour tout les autres fichiers dans ce format, ça double le volume du fichier texte et ça limite la taille des fichier W à environ 1Mo et 50% d'objets en moins sur une parcelle.
Sinon, personnellement (et je ne dois pas être le seul), je trouve aberrant depuis la sortie de MSTS qu'on ait à notre disposition que 8 valeurs pour commander les informations données par un signal lumineux ou par des signaux mécaniques groupé et/ou combinés. Un simple exemple avec un signal dit à 9 feux a la possibilité de renvoyer au conducteur 17 informations différentes et que rien n'empêche un même signal de pouvoir toutes les présenter (Bon courage aux enclencheurs et surtout si c'est un poste à leviers)
1 - Signal éteint,
----- 1.a : plaque Nf
----- 1.b : plaque F
2 - Carré,
3 - Sémaphore,
4 - Rouge Clignotant,
5 - un feu blanc
6 - un feu blanc clignotant
7 - Avertissement,
8 - Avertissement et Rappel 30,
9 - Avertissement et Rappel 60,
10- Avertissement clignotant,
11- Avertissement clignotant et Rappel 30,
12 - Avertissement clignotant et Rappel 60,
13 - Ralentissement 30,
14 - Ralentissement 60,
15 - Vert clignotant,
16 - Voie libre.

Ca ne serait pas complet si je ne parlais pas de la TVM qui peut afficher toutes les vitesses maximum de circulation possible sur LGV, qui peuvent être fixe ou clignotante, et ça jusqu'à 320 kmh plus d'autres informations comme les couper courant, ... soit 18 taux seulement pour la TVM300, 27 pour la TVM430 et le système ayant des réservent, on peut encore en ajouter. Pour moi, il n'est pas possible d'avoir une vraie simulation si on ne peut pas reproduire une vraie situation de signalisation. L'idéal serait d'en disposer de 32. Il serait bon aussi de prévoir plusieurs lien à fin de pouvoir imposer une vitesse différente sur les aiguilles en fonction de la direction. Une tentative a été faites dans OR avec les signaux de type SPEED que j'ai testés, mais alors, il devient impossible d'utiliser MSTS et après en avoir utilisé une bonne trentaine, j'ai découvert que certains refusaient de fonctionner. Donc retour à la case départ et je n'ai pas touché 20000F. ?,
Le monde ne s'est pas fait en 1 jours. Alors prions mes bien chers frères, pour qu'avec "OpenRails" ce soit pour demain.

A+

Raymond
Il y a deux catégories de gens sur terre, ceux qui causent pour ne rien dire et ceux qui feraient mieux de la fermer avant de l'ouvrir. (Pierre Dac)

Avatar du membre
Bernard56
Messages : 521
Enregistré le : 14 mai 2012 21:42
Localisation : (29) Fouesnant Les Glénan
Contact :

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar Bernard56 » 21 févr. 2017 20:27

Bonsoir à tous,

A propos d'évolution, une qui me permettrait peut-être ... de faire le grand saut consisterait
à un outil permettant de vérifier le TDB et le RDB et cerise sur le gâteau l'utilitaire permettant de le corriger.
Pour l'instant, qui pourrait sous OR effectuer ce genre de corrections ? <2<
En espérant qu'un jour ...
Amicalement.
Bernard
Créateur des lignes Quimper - Savenay et de RBZH (Réseau Breton)
http://voies-ferrees-bretonnes.e-monsite.com
https://www.youtube.com/channel/UCQesLUQpkpfbZryRkQNJJ8w

Avatar du membre
RM77
Testeur
Messages : 1106
Enregistré le : 03 août 2005 8:19

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar RM77 » 22 févr. 2017 7:13

Bonjour
Bernard56 a écrit :...A propos d'évolution, une qui me permettrait peut-être ... de faire le grand saut consisterait à un outil permettant de vérifier le TDB et le RDB...
Cet outils existe déjà, il est dans OR et la vérification se fait au lancement de l'activité. Le résultat est dans "OpenRailsLog.txt".
Maintenant, pour reconstruire la base de données des voies (TDB) et des routes (RDB) il est possible de le faire avec MSTS mais hélas c'est un peu bugué surtout si la route et un peu trop grande à son gout.

Bernard56 a écrit :...Pour l'instant, qui pourrait sous OR effectuer ce genre de corrections ? <2<
...
Et bien moi, par exemple, et quelques autres seulement...Que ce soit pour OR et/ou MSTS puisque ce sont les même fichiers et les même règles à respecter.

Dans la base de données il ne faut pas oublier aussi le tsection.dat local que rien ne sait reconstruire en cas de problème. Le seul moyen est de le reconstruire manuellement comme j'ai du le faire récemment pour une route en cours de transformation par Hicham(Jabri). On trouvait un mélange de version d'xtracks. Toutes les nouvelles voies dynamiques posées avec la version 3.n, étaient tout simplement oubliées dans le tsection.dat.
"Horace" permet de convertir les divers versions d'xtracks, mais pas si il y a un mélange de version car dans ce cas toutes les sections de voies dont l'identifiant est supérieur à 375, se trouvent renumérotées dans les fichiers W d'une valeur de 40000 devenant introuvable dans le GLOBAL/SHAPES et dans sont tsection.dat.

Un tel outils de reconstruction de la base de données serait cependant le bien venu, mais il ne doit pas oublier le tsection.dat local, facile à reconstruire manuellement mais il est un peu long à refaire .

A+
Il y a deux catégories de gens sur terre, ceux qui causent pour ne rien dire et ceux qui feraient mieux de la fermer avant de l'ouvrir. (Pierre Dac)

Avatar du membre
StationWhere
Messages : 1291
Enregistré le : 23 oct. 2010 16:28
Localisation : lot (46)

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar StationWhere » 22 févr. 2017 9:16

Bonjour.
Bernard56 a écrit :...A propos d'évolution, une qui me permettrait peut-être ... de faire le grand saut consisterait à un outil permettant de vérifier le TDB et le RDB...
RM77 a écrit :
...Cet outil existe déjà, il est dans OR et la vérification se fait au lancement de l'activité. Le résultat est dans "OpenRailsLog.txt"....

Oui... Bien sùr... Le RESULTAT est dans OpenRailsLog mais je suis d'accord avec Bernard56 quand il demande de VERIFIER et pas seulement de constater.
Qui n'a pas été tenté de s'écrire quelque chose, un jour... comme ça... Un truc à soi qu'on modifie à la demande...
L'ennui et le problème c'est que l'utilitaire perso en question se plante quand le TDB est vérolé. He oui....

N'importe comment, ça ne vaudrait jamais un outil sérieux. Un espèce de TRACKVIEWER qui nous montre les dégats et nous permette d'intervenir dessus.

I had a dream ... ( An other dream )
Dell XPS 8300 W7 Vers Intég 64b.

Avatar du membre
Bernard56
Messages : 521
Enregistré le : 14 mai 2012 21:42
Localisation : (29) Fouesnant Les Glénan
Contact :

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar Bernard56 » 22 févr. 2017 13:48

Bonjour à tous,

@RM77 :
Je suis très heureux d'apprendre (désolé j'ai pas du tout lire ... =, ) que le TDB et RDB étaient contrôlés au lancement d'une activité.
Créer une petite activité pour contrôler, bien évidemment pas compliqué.

Mais est-on certain que MSTS ou OR "écrivent" exactement (parlons langage informatique : à l'octet près) la même chose, lors de la pose d'une voie, d'une aiguille .. etc !

Mais je rejoins StationWhere, un outil comme par exemple TRACKVIEWER serait très pertinent pour contrôle de la route (à tout moment) et comme je disais, cerise sur le gâteau, indiquer au moins la portion de voie, l'aiguille, la portion de route en erreur (MSTS : retour bureau sans explications), après on pourra toujours faire appel ... aux personnes compétentes !!! (tu fais bien partie de ma liste des personnes concernées) ... (.
Encore le cas ce matin, travail sur une parcelle en posant des voies, après multiples modifications, sauvegarde et quand je relance l'éditeur sur cette fameuse parcelle, boum retour bureau !!! Que faire ? Restorer et recommencer ... Alors qu'avec un utilitaire s’il avait pu me dire la cause du plantage, pas obligé de restorer et de perdre le travail ... mais bon, une sauvegarde de ce matin pas grave !!!

Nous sommes nombreux "à souffrir" des caprices de MSTS et "faire souffrir" ceux qui nous aident à corriger, si on pouvait éviter la même chose pour ceux qui se lancent avec OR ....

@StationWhere :
I had a dream ... ( An other dream )
Alors que notre rêve se réalise ... (.

Bonne continuation à vous.
Amicalement.
Bernard
Créateur des lignes Quimper - Savenay et de RBZH (Réseau Breton)
http://voies-ferrees-bretonnes.e-monsite.com
https://www.youtube.com/channel/UCQesLUQpkpfbZryRkQNJJ8w

Avatar du membre
StationWhere
Messages : 1291
Enregistré le : 23 oct. 2010 16:28
Localisation : lot (46)

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar StationWhere » 24 févr. 2017 13:18

Bonjour.
Bernard56 a écrit :Mais est-on certain que MSTS ou OR "écrivent" exactement.... la même chose, lors de la pose d'une voie, d'une aiguille .. etc !

Oui. j'ai testé sur une pose simple il faut dire. C''est pareil.
Il faut dire aussi autre chose qui peut ètre utile. On peut se servir de TSRE pour récupérer des situations problèmatiques de TRPIN 0 0.
Pourquoi? Parce que TSRE peut sur commande enlever ou rajouter un rail existant au TDB.
Bon... Je ne veux pas m'étendre plus ici la dessus.
Cordialement.
Dell XPS 8300 W7 Vers Intég 64b.

ActivMaker
Messages : 213
Enregistré le : 25 janv. 2011 20:23

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar ActivMaker » 04 mars 2017 21:01

Bonjour,

une qui me permettrait peut-être ... de faire le grand saut consisterait
à un outil permettant de vérifier le TDB et le RDB et cerise sur le gâteau l'utilitaire permettant de le corriger.


Effectivement c'est idée....Que j'ai commencer à creuser depuis déjà quelques temps . J'ai travaillé sur un outil permettant de reconstituer les TDB et RDB . A ce jour cet outil est loin d'être terminé , j'ai arrêté le dev en 2016 pour avancer sur mes lignes. Mais je pense pouvoir retrouver du temps en 2017 pour le continuer....
J'informerais sur l'état d'avancement (ou pas) de cet outil.
A bientôt.

Avatar du membre
Bernard56
Messages : 521
Enregistré le : 14 mai 2012 21:42
Localisation : (29) Fouesnant Les Glénan
Contact :

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar Bernard56 » 04 mars 2017 21:27

Bonsoir à tous,
Bonsoir ActivMaker,

Très bonne nouvelle d'apprendre que tu es sur ce genre de projet. ;?
S'il est possible de te donner un coup de main, j'en serais ravi.
Amicalement.
Bernard
Créateur des lignes Quimper - Savenay et de RBZH (Réseau Breton)
http://voies-ferrees-bretonnes.e-monsite.com
https://www.youtube.com/channel/UCQesLUQpkpfbZryRkQNJJ8w

Avatar du membre
Sharpe49
Messages : 316
Enregistré le : 23 août 2010 4:46
Localisation : Lyon (69)

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar Sharpe49 » 18 mars 2017 5:29

RM77 a écrit :Bonjour à tous

De retour après une absence un peu prolongé, j'ai relu ce qui se dit ici et je suis surpris qu'à aucun endroit on ne parle de la signalisation et de sa programmation.

Le RGS a écrit :Certains ordres ou informations intéressant la sécurité de la circulation sont donnés aux
agents concernés, en particulier aux conducteurs, à l’aide de signaux.
Tout agent, quelle que soit sa fonction, doit obéissance passive et immédiate aux
signaux le concernant

La programmation avec ce mini "C" et les scripts associés ( sigcfg et sigscr.dat ) ne me gêne pas du tout et est à la porté de tout le monde en quelques minutes. Mais pourquoi en Unicode ??? (sigcfg) Comme pour tout les autres fichiers dans ce format, ça double le volume du fichier texte et ça limite la taille des fichier W à environ 1Mo et 50% d'objets en moins sur une parcelle.
Sinon, personnellement (et je ne dois pas être le seul), je trouve aberrant depuis la sortie de MSTS qu'on ait à notre disposition que 8 valeurs pour commander les informations données par un signal lumineux ou par des signaux mécaniques groupé et/ou combinés. Un simple exemple avec un signal dit à 9 feux a la possibilité de renvoyer au conducteur 17 informations différentes et que rien n'empêche un même signal de pouvoir toutes les présenter (Bon courage aux enclencheurs et surtout si c'est un poste à leviers)
1 - Signal éteint,
----- 1.a : plaque Nf
----- 1.b : plaque F
2 - Carré,
3 - Sémaphore,
4 - Rouge Clignotant,
5 - un feu blanc
6 - un feu blanc clignotant
7 - Avertissement,
8 - Avertissement et Rappel 30,
9 - Avertissement et Rappel 60,
10- Avertissement clignotant,[*]
11- Avertissement clignotant et Rappel 30,
12 - Avertissement clignotant et Rappel 60,
13 - Ralentissement 30,
14 - Ralentissement 60,
15 - Vert clignotant,
16 - Voie libre.

Ca ne serait pas complet si je ne parlais pas de la TVM qui peut afficher toutes les vitesses maximum de circulation possible sur LGV, qui peuvent être fixe ou clignotante, et ça jusqu'à 320 kmh plus d'autres informations comme les couper courant, ... soit 18 taux seulement pour la TVM300, 27 pour la TVM430 et le système ayant des réservent, on peut encore en ajouter. Pour moi, il n'est pas possible d'avoir une vraie simulation si on ne peut pas reproduire une vraie situation de signalisation. L'idéal serait d'en disposer de 32. Il serait bon aussi de prévoir plusieurs lien à fin de pouvoir imposer une vitesse différente sur les aiguilles en fonction de la direction. Une tentative a été faites dans OR avec les signaux de type SPEED que j'ai testés, mais alors, il devient impossible d'utiliser MSTS et après en avoir utilisé une bonne trentaine, j'ai découvert que certains refusaient de fonctionner. Donc retour à la case départ et je n'ai pas touché 20000F. ?,
Le monde ne s'est pas fait en 1 jours. Alors prions mes bien chers frères, pour qu'avec "OpenRails" ce soit pour demain.

A+

Raymond


Bonjour,

Comme je viens moins souvent sur le forum et qu'il n'y a plus de notifications e-mail, je viens seulement de lire ce message.

Personnellement, je serais même allé encore plus loin :
  • Pouvoir coder les signaux dans le langage de programmation natif du logiciel, le C# (de la même manière que pour les scripts pour le matériel roulant)
  • Cela pourrait permettre de mettre un script par fichier plutôt que de tout mettre dans un seul fichier.
  • Pouvoir définir soit même les indications plutôt que de rester dépendant d'une simple variable énumérée.
  • Pouvoir récupérer ces nouvelles indications dans les scripts TCS pour pouvoir gérer de manière plus fine la signalisation.
  • Pouvoir afficher ces indications sur le cab-signal.
Cependant, il faut que le référent signalisation d'OR accepte cette idée, ce qui n'est pas gagné.
Cédric Gniewek
Développeur Open Rails

Scripts Open Rails pour matériel roulant : signalisation française et robinet de freinage PBL2
https://github.com/Sharpe49/OpenRails_Scripts

Avatar du membre
RM77
Testeur
Messages : 1106
Enregistré le : 03 août 2005 8:19

Re: Vos souhaits / remarques sur l'évolution d'OR

Messagepar RM77 » 18 mars 2017 8:40

Bonjour

Je suis heureux de voir que le point de vue des retraités et des actifs de la signalisation se rejoint. Le but est également pour un bon fonctionnement en cabine de la TVM et du KVB.
Je n'ai pas osé aller aussi loin, car la programmation en C#, bien qu'assez simple, n'est quand même pas à la porté de tout le mondes. Ouvrir une fenêtre c'est bien, mais si on l'ouvre trop grande, on a 50 versions d'OR au bout de deux ans.
Une constatation que j'ai faite récemment est une différence de comportement entre MSTS et OR. Sur MSTS, on trouve certains signaux qui ont 5, 6,... ,n têtes (HEAD5, HEAD6,... , HEADn). Les spécifications de MSTS ne donnent aucune limite et MSTS accepte et gère ces n têtes. Il n'existe qu'une seule restriction et qui concerne les têtes de type USER limitées à 4.

Code : Tout sélectionner

SIGSUBT_ values.  Describe the purpose of a signal shape sub-object.
   DECOR                                      - Decorative
   SIGNAL_HEAD                            - A signal head
   NUMBER_PLATE                           - A number plate
   GRADIENT_PLATE                      - A gradient plate
   USER1 – USER4                          - User-defined features

Cependant, MSTS étant pour une fois en avance, il accepte ces ntêtes, mais son moteur de reconstruction de la base de données, ne prend en compte que les quatre premières(hic) d'où erreur lors de la reconstruction et il ne reste plus qu'à supprimer/replacer le signal si MSTS le veut bien car il plante souvent dans ce cas là.
Dans OR, c'est différent, il n'accepte que quatre têtes de type HEAD (HEAD1,HEAD2,HEAD3 et HEAD4). Il ignore les suivantes d'où un disfonctionnement des signaux en comportant plus de 4 et comme pour le moment, OR ne sait pas reconstruire la base de donnée (TSRE non plus), rendre OR compatible sur le nombre de tête non limitées ne serait pas un luxe. Pour info, le signal mécanique le plus chargé que j'ai connu, se trouvait à Nogent sur Marne. C'était un signal de BAM-Est et qui comportait un Carré, un ralentissement, un rappel de ralentissement, un avertissement, un sémaphore de BAM-EST (Sémaphore de couverture), une pancarte G mobile et un TIV100e mobile, soit en tout sept têtes de signal; un vrai totem indien. En plus, ce signal était équipé d'un système d'approche et pour aller vers le Garage, le carré ne s'ouvrait qu'à 50m du signal. Ce signal est impossible à reproduire aujourd'hui sauf en plaçant 2 signaux à 30cm l'un de l'autre et en déployant des ruses de Sioux (pour un totem, c'est normal ?2? ) pour les programmer.
A+
Il y a deux catégories de gens sur terre, ceux qui causent pour ne rien dire et ceux qui feraient mieux de la fermer avant de l'ouvrir. (Pierre Dac)


Retourner vers « ORTS: Général »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité