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!
steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 17 juil. 2014 9:21

Bonjour,
Je lance ce fil en espérant que vous y répondrai avec entrain (.
Je le met en parallèle avec celui où vous énumérez les caractéristiques MSTS manquantes dans OR . Ici, ce serait plutôt pour y parler de souhaits, de possibilités, etc. à ajouter à OR pour le rendre plus attractif, plus jouable, plus 'moderne' !
Jusqu'à maintenant, le gros challenge fût d'aligner OR sur les possibilités de MSTS, d'assurer une compatibilité des deux simulateurs vis à vis des routes et du matériels roulant. L'après commence à se préparer et, même si cela reste encore discret, les débats sur la suite commence à s'animer. Vos avis peuvent être utiles, certaines directions ont été ébauchées (Timetable, Station, ...), sans que cela ne soulève de gros débats ici ou ailleurs. Pourtant, cela devient urgent de mettre en avant vos souhaits.

A vous lire

Stef
Steamy stef - Image

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 17 juil. 2014 9:30

Je me réponds, histoire de séparer les choses...

Je sais que certains travaux récents, non disponibles sous MSTS comme le dévers, ont reçu un bon accueil. Pareil pour l'intégration de certains systèmes dans le jeu comme la répétition de la signalisation en cabine. Toutes ces évolutions ne touchent pas directement à la base d'OR, les infos issues de MSTS.
Le gros débat actuel touche sur le besoin ou non de 'reproduire' certains comportements de MSTS dans OR. Par exemple,
L'utilisation des 'trains fantômes'. Est-ce une réelle nécessité ? Dans MSTS, plus que certainement, mais dans OR... qu'en pensez-vous ?
La multiplicité des Waiting Points. MSTS supporte la présence de multiple WP sur une même section de voie. OR essaie toujours de les réduire au maximum. ... ?
La compatibilité des activités est un gros débat et la source de beaucoup de problèmes. Beaucoup de routes ont été 'arrangées' pour s’accommoder de certains soucis sous MSTS. Vouloir en assurer une complète compatibilité va obliger à 'implémenter' des bugs MSTS sous OR, et j'aime pas beaucoup ça. Selon vous, doit-on aller dans cens ou doit-on trouver d'autres vois ?

Stef
Steamy stef - Image

Avatar du membre
BB25187
Administrateur
Messages : 15057
Enregistré le : 09 mai 2004 1:07
Localisation : Grenoble
Contact :

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

Messagepar BB25187 » 17 juil. 2014 21:00

Bonjour,

Désolé. J'ai toujours dans l'idée d'essayer de répondre à tes questions. Mais ces dernières semaines, j'ai été pas mal chargé. Ca se calme un peu. J'essaye de te faire ça dans les jours qui viennent, car ça mérite de développer un peu sur la politique actuelle de développement d'OR, qui ne me semble pas claire du tout (car justement souvent tiraillée entre l'ajout de nouvelles capacités et la gestion dogmatique de l'héritage).
Cela dit pour résumer en une ligne et comme avant gout, je ne crois vraiment pas que la recherche de la compatibilité à 100% ne soit la bonne voie, surtout quand il s'agit de reproduire des incorrects, buggés ou carrément absurdes de MSTS. Et hélas, les activités reposent sur pas mal de cas comme ça!
A suivre donc pour ce qui me concerne!

A+
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image

nicober
Modérateur
Messages : 2200
Enregistré le : 21 févr. 2004 22:36
Localisation : Québec (Qc) Canada
Contact :

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

Messagepar nicober » 17 juil. 2014 21:30

Bonsoir à tous

Je me lance en espérant que d'autres suivront.

steamystef a écrit : Le gros débat actuel touche sur le besoin ou non de 'reproduire' certains comportements de MSTS dans OR.


Si le train fantôme peut être supprimé, alors pourquoi le conserver?
Pourquoi devoir utiliser 6 ( WP ) de 10 secondes, alors qu'un seul de 60 secondes pourrait suffire?
Le tout est à savoir si l'activité fonctionnera correctement ou pas.

steamystef a écrit : La compatibilité des activités est un gros débat et la source de beaucoup de problèmes.
Beaucoup de routes ont été 'arrangées' pour s’accommoder de certains soucis sous MSTS.
Vouloir en assurer une complète compatibilité va obliger à 'implémenter' des bugs MSTS sous OR,
et j'aime pas beaucoup ça. Selon vous, doit-on aller dans cens ou doit-on trouver d'autres vois ?


A mon humble avis, VOUS VOUS DEVEZ DE TROUVER D'AUTRES VOIES - C'est une ABERRATION et un NON-SENS que d'implémenter les bugs existants de MSTS sous OR. Dès le lancement de Open Rails, ses concepteurs se sont évertués à nous dire que OR n'était pas un nouveau Bin-Patch de MSTS, mais bien un logiciel de simulation à part entière. Reproduire les bugs de MSTS n'en ferait ni plus ni moins qu'une GROSSE BEAN_PATCH pour un MSTS amélioré. Et ses détracteurs n'en seraient que ravis, car il y en a bien plus qu'on le pense. On sait très bien que le calcul des distances et des vitesses par MSTS est erroné, cela a déjà fait l'objet de certains débats anciennement. Ce n'est toujours bien pas de la faute des concepteurs de OR si certaines routes sont trafiquées ou mal conçues juste à cause des bugs de MSTS . Tout d'abord, celles bien faites en souffriraient et celles du future traineraient constamment ce boulet juste pour quelques routes. C'est le cas de ma route Q-C, où il manque approximativement 2 miles ( un peu plus de 3.25 Km). Je dois concevoir avec ces erreurs ou la refaire complètement. C'est impensable de demander à ce que OR s'adapte à ma route à cause d'une erreur de conception. Je dois vivre avec, "that's it that's all".

Ce que j'ai de la misère à comprendre c'est que les concepteurs d'activités pour MSTS se sont adaptés à la gymnastique de MSTS, mais maintenant, plusieurs voudraient que ce soit OR qui s'adaptent à des centaines d'activités comportant chacune leur particularité. C'est comme on le dit "Mettre la chârue devant les boeufs". Vouloir plaire à tous est pratiquement impossible et cela risque de faire de OR une véritable "Tour de Babel". Désolé si cela en choque quelques uns, je sais que les bonnes vieilles habitudes sont très difficile à changer, mais on y peut rien. Ou vous allez de l'avant et l'on s'adapte ou on reste sur place et on piétine.

Un des grands souhaits que je verrais prochainement sous OR serait la simplification des fichiers ENG et WAG. L'ajout de plusieurs parties communes comme c'est le cas présentement pour les cabines et les sons qui font référence à des dossiers communs comme ( Common.cab et Common.snd ). On pourrait facilement mettre en commun tous les systèmes de freinage qui ne doivent pas être si nombreux que cela. Ce qui simplifierait l'édition de ses fichiers et diminuerait les risques d'erreurs du fait de n'avoir à modifier des dizaines de fichiers pour un type de wagons. On aurait qu'un seul fichier à modifier pour un ensemble de wagons qui s'y réfère. Et rien nous empêcherait d'y ajouter en plus nos propres fichiers si on le désire.

Faire un effort pour trouver ce qui ne fonctionne pas sur certaines routes qui refusent toujours de fonctionner sous OR. Comme par exemple la route RFSP qui au lancement donne toujours un message d'erreur. Au moins pouvoir faire fonctionner toutes les routes conçues pour MSTS en mode exploration sans se faire sortir.

Une plus grande flexibilité dans le paramétrage des caméras, surtout la vue "Trackside" ( 4 ). Lorsque l'on veut utiliser cette caméra aux endroits où il y a beaucoup de végétation, sur le bord de la voie ou encore en milieu urbain, on se retrouve constamment coincé dans la végétation ou encore
dans les bâtiments et on ne voit absolument rien ou presque de notre train qui passe. C'est bien frustrant de prendre une image ou encore de vouloir faire une vidéo dans ces conditions. La possibilité tout comme dans MSTS de faire nous même nos propres paramétrages serait souhaitable.

Bon bien voilà pour un premier jet. Si d'autres idées me viennent à l'esprit je compléterai plus tard. (.

Amicalement!
Nicober

«La Terre n’appartient pas à l’Homme, c’est l’Homme qui appartient à la Terre.»
[ Sitting Bull ]

Avatar du membre
CM63
Messages : 1947
Enregistré le : 13 août 2010 21:48
Localisation : Un peu au large de la faille de Limagne
Contact :

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

Messagepar CM63 » 17 juil. 2014 22:10

Bonsoir,

J'ai longtemps hésité à répondre à ce fil car j'ai bien peur que cela restera encore une fois lettre morte. Il faudrait un véritable système de prise en compte des demandes, une gestion des priorités, une personne qui se charge d'"élaguer", c'est-à-dire de dire "telle demande demandée par A est presque la même chose que telle autre de B ou est incluse, donc on simplifie, et on demande l'accord aux personnes concernées.Il faudrait aussi gérer les demandes contradictoires, comme par exemple celle qui consiste à être compatible avec MSTS ou non, ou au contraire à abandonner la compatibilité avec MSTS (pour cela on pourrait prendre un système de référendum, ou tout le monde voterait oui/non, dans le cas de la compatibilité MSTS je pense qu'une majorité sortirait (contre)).
Et il faut quelqu'un et un système (une appli web hébergée) pour gérer tout cela ?+ . Je me tatais pour me porter candidat, je verrai (. . Peut-être qu'un tel système existe chez Elvas Tower? Il y a un truc pour les bugs, mais pour les demandes d'évolution?

Alors maintenant je vais mettre mon grain de sel:
- contre la compatibilité avec les bugs de MSTS,
- moi j'aimerais bien un mode "flotte", c'est-à-dire non pas "j'ai la BB 67400" et je peux la cloner en autant d'exemplaires que je veux (situation actuelle), mais j'ai la "BB 67429" et pas une autre, et elle est soit dans la rame joueur, soit dans une rame trafic, soit en stationnement "statique" (attelable), soit en stationnement "décor" (non attelable, et traversable comme du beurre, mais c'est pour décharger le process),
- non pas "j'ai le wagon GBL" et je peux le cloner en autant d'exemplaire que je veux, mais : "j'ai 50 wagons GBL tous numérotés", et même chose pour ce qui est de leur emplacement.

Qu'en pensez-vous? En fait quand je jouais avec OR je procédais de cette façon, mais cela me faisait jongler avec l'éditeur d'activité, car il fallait que je gère cela moi-même, que je dise : telle rame qui était en statique, que je viens d'atteler, il faut que je la vire et que je l'ajoute dans la rame joueur, et je me plantais :4: , et boum !

Bonne soirée.

PS : d'accord avec Nicober sur les paramètres des .eng et de .wag, la possibilité d'en mettre certains une seule fois dans un fichier, lorsqu'on veut spécifier des paramètres communs à plusieurs véhicule. En fait c'est très simple à faire : il suffirait de créer une fonction "include" dans les fichiers, et cela marcherait pour tout type de fichier véhicule. Si quelqu'un peut le proposer à Elvas Tower. Ok, je le ferai peut-être puisque je suis inscrit sur le site.
Image

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 18 juil. 2014 11:58

BB25187 a écrit :Bonjour,

Désolé. J'ai toujours dans l'idée d'essayer de répondre à tes questions. Mais ces dernières semaines, j'ai été pas mal chargé. Ca se calme un peu. J'essaye de te faire ça dans les jours qui viennent, car ça mérite de développer un peu sur la politique actuelle de développement d'OR, qui ne me semble pas claire du tout (car justement souvent tiraillée entre l'ajout de nouvelles capacités et la gestion dogmatique de l'héritage).
Cela dit pour résumer en une ligne et comme avant gout, je ne crois vraiment pas que la recherche de la compatibilité à 100% ne soit la bonne voie, surtout quand il s'agit de reproduire des incorrects, buggés ou carrément absurdes de MSTS. Et hélas, les activités reposent sur pas mal de cas comme ça!
A suivre donc pour ce qui me concerne!

A+


Ce sera avec intérêt que je te lirai. Pour ce qui est de la politique OR, la situation est un peu vague actuellement.
Stef
Steamy stef - Image

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 18 juil. 2014 12:15

nicober a écrit :...Si le train fantôme peut être supprimé, alors pourquoi le conserver?

C'est ce que je pense aussi mais voilà, certaines routes sont conçues pour les utiliser!

nicober a écrit : Pourquoi devoir utiliser 6 ( WP ) de 10 secondes, alors qu'un seul de 60 secondes pourrait suffire?
Le tout est à savoir si l'activité fonctionnera correctement ou pas.

Oui et non! Des WP qui se suivent juste pour ralentir un train et ainsi faciliter certaines activités, OK
Mais un ou deux WP placer à des endroits clés et dans un but précis... je suis pour les garder. (simulation du chargement d'une rame de wagons ).

nicober a écrit :A mon humble avis, VOUS VOUS DEVEZ DE TROUVER D'AUTRES VOIES - C'est une ABERRATION et un NON-SENS que d'implémenter les bugs existants de MSTS sous OR. Dès le lancement de Open Rails, ses concepteurs se sont évertués à nous dire que OR n'était pas un nouveau Bin-Patch de MSTS, mais bien un logiciel de simulation à part entière. ...

La compatibilité est une arme à double tranchants. Elle est nécessaire pour assurer une base large de routes exploitable sans devoir passer par la case 'outils de création'. Mais elle devient un boulet dès qu'on la pousse trop loin et qu'on se laisse influencer par les utilisateurs réticents aux changements. L'introduction d'un nouveau flag 'Enhanced compatibility with MSTS activities' devrait permettre un début de séparation mais cela complique le programme.

nicober a écrit :...Ou vous allez de l'avant et l'on s'adapte ou on reste sur place et on piétine.
C'est souvent une question d'influence. Celui qui râle le plus, qui gronde le plus est écouté, les autres suivent <2<
Il reste le problème des possibilités d'évolutions compte tenu de l'existant. Je reviendrai sur ce point.

nicober a écrit :Un des grands souhaits que je verrais prochainement sous OR serait la simplification des fichiers ENG et WAG....

En effet, ce serait quelque chose d'intéressant, cela pourrait être ajouter dans les demandes, à suivre.

nicober a écrit :Faire un effort pour trouver ce qui ne fonctionne pas sur certaines routes qui refusent toujours de fonctionner sous OR. ...

Ce point est-il repris sur le 'launchpad' où ici ?

nicober a écrit :Une plus grande flexibilité dans le paramétrage des caméras,

Idem point précédent.

Je dis cela, non pour m'en débarrasser mais pour savoir si cela a été aborder quelque part!

Merci
Stef
Steamy stef - Image

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 18 juil. 2014 13:55

CM63 a écrit :...J'ai longtemps hésité à répondre à ce fil car j'ai bien peur que cela restera encore une fois lettre morte.

Meuh non...

CM63 a écrit :Il faudrait un véritable système de prise en compte des demandes, une gestion des priorités, une personne qui se charge d'"élaguer", c'est-à-dire de dire "telle demande demandée par A est presque la même chose que telle autre de B ou est incluse, donc on simplifie, et on demande l'accord aux personnes concernées.Il faudrait aussi gérer les demandes contradictoires, comme par exemple celle qui consiste à être compatible avec MSTS ou non, ou au contraire à abandonner la compatibilité avec MSTS (pour cela on pourrait prendre un système de référendum, ou tout le monde voterait oui/non, dans le cas de la compatibilité MSTS je pense qu'une majorité sortirait (contre)).
Et il faut quelqu'un et un système (une appli web hébergée) pour gérer tout cela ?+ . Je me tatais pour me porter candidat, je verrai (. . Peut-être qu'un tel système existe chez Elvas Tower? Il y a un truc pour les bugs, mais pour les demandes d'évolution?

Il y a bien le système des 'blueprints' sur le Launchpad... il faut voir avec le Management Team, poser la question sur Elvas Tower...

CM63 a écrit :...moi j'aimerais bien un mode "flotte",

Il y a de l'idée! cela croise certaines demandes pour 'trier' le matériel roulant par ligne... Mais ici, un peu plus précis...
Merci

Stef
Steamy stef - Image

Avatar du membre
CM63
Messages : 1947
Enregistré le : 13 août 2010 21:48
Localisation : Un peu au large de la faille de Limagne
Contact :

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

Messagepar CM63 » 18 juil. 2014 15:40

Bonjour,

steamystef a écrit :Il y a bien le système des 'blueprints' sur le Launchpad... il faut voir avec le Management Team, poser la question sur Elvas Tower...


Désolé, je ne sais pas ce que sont "blueprints" et "launchpad" =, , je pense (comme je l'ai déjà dit) qu'il y a bien quelque chose pour le signalement des bugs, mais pas pour les demandes d'évolution. Enfin je regarderai.

Au sujet des trains fantômes

Je ne comprends pas le problème, de toutes façons les trains fantômes ne demandent pas de fonctionnalité particulières au(x) logiciel(s), un train fantôme c'est un train dont la 3d est vide, non? Si vous tenez absolument à mettre des trains fantômes, rien ne vous empêchera.

Bonne journée.
Image

Avatar du membre
BB25187
Administrateur
Messages : 15057
Enregistré le : 09 mai 2004 1:07
Localisation : Grenoble
Contact :

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

Messagepar BB25187 » 19 juil. 2014 9:00

Hello,

Juste une petite réaction rapide sur deux points.

Le premier point concerne le système de suivi des demandes et de vote. Je pense que c'est en effet une bien meilleure méthode que les long fils de collectes des desideratas, qui finissent par partir dans tous les sens et ne permettent que très difficilement (voire très rarement) de dégager des points de vue communs. Cela étant dit, le "tracker" de "bug" (mais il contient déjà autre chose que des bugs au sens strict) permet déjà (ou permettrait facilement):
- De distinguer ce qui est du niveau du défaut de ce qui est une demande de fonctionnalité (ajout d'une catégorie particulière si elle n'existe pas encore). On a souvent recours à ces catégories multiples dans les systèmes de suivi et bases de connaissances logicielles. Ça permet de regrouper des échanges et discussion sur un bug/une évolution dans un enregistrement particulier, donc sans mélanger tous les sujets. Ça reste bien entendu moins formel qu'un système de vote.
- A n'importe quel utilisateur, d'indiquer qu'un enregistrement l'affecte également. Bien utilisé pour les vrais bugs, cette fonctionnalité permet de connaitre l'impact du défaut en nombre d'utilisateurs... pour peu bien entendu que les utilisateurs fassent l'effort de cliquer! Pour une demande d'évolution, elle permettrait de savoir combien d'utilisateurs sont intéressés.

Le second point concerne les points d'attente. A mon avis, il soulève une question bien plus générale. Avant de la développer et de généraliser, mais pour vous permettre de mieux comprendre mon propos par la suite, je vais donc commencer par parler des points d'attente. Je pense en effet que fournir un moyen de pouvoir arrêter un train de trafic pendant un temps donné à un endroit donné (pas forcément au niveau d'un quai ou d'un signal) est quasiment indispensable pour permettre la mise en place d'activités intéressantes. Pour le train du joueur, c'est pareil: on imagine bien une mission qui imposerait un arrêt d'une durée bien spécifiée en pleine voie.
Ça, c'est un objectif. Il faut le distinguer clairement des moyens employés pour l'atteindre, autrement dit, des modalités d'implémentation. Pourquoi devrait-on reprendre absolument la manière dont ces points d'attente étaient définis et utilisés dans MSTS? Ne serait-il pas plus judicieux de profiter de la mise en place des "timetables" pour intégrer une notion de points d'arrêt programmé dans la marche des trains qu'elles décrivent? Plutôt que de singer simplement MSTS, on ouvrirait la porte à un système intégré et largement plus puissant de définition des "activités". De plus, un des usages des points d'attente dans MSTS consistait à cacher la misère de la gestion des priorités des trains. Ne serait-il pas plus intéressant et plus ambitieux d'implémenter un véritable système de gestion des priorités, qui permettrait d'aller bien au delà du périmètre très limité des points d'attente? Là encore, les timetables peuvent être le bon endroit pour donner la main à l'utilisateur pour contrôler ces priorités. Si l'on allait par là, les trains fantômes, qui n'étaient eux aussi que des palliatifs mal-pratiques deviendraient sans doute totalement inutiles.

En abordant la question des points d'attente et des trains fantômes, on voit qu'une manière d'avancer consiste d'abord à bien faire la distinction entre l'objectif à haut niveau et les modalités d'implémentation. Si certains objectifs généraux doivent être repris des fonctions de MSTS, en revanche à mon avis il ne faut pas s'enfermer dans des modalités d'implémentation qui ne se justifient plus en dehors du contexte de MSTS. Il vaut bien mieux envisager une implémentation plus générique, plus flexible et qui offrirait davantage de possibilités.

Il y a un autre point sur lequel on a très bien vu que la tentative de simple reproduction de ce qui se faisait dans MSTS n'était pas la bonne voie: il s'agit des fichiers d'environnement. OR permet une gestion dynamique des conditions météo. Pourquoi s'en priver en ne reprenant que le support des environnements qui existait dans MSTS? Il vaudrait bien mieux réfléchir à mettre en place ce qui manque dans OR pour varier les ambiances: amélioration des précipitations, variations de l'aspect des couvertures nuageuses, variations des teintes au lever/coucher du soleil, variation des hauteurs et teintes des cours d'eau et des lacs, ... tout cela sans forcément chercher à s'appuyer sur le format des fichiers d'environnement.

Et ce qui vaut pour les points d'attente et les trains fantômes, ou pour les fichiers d'environnement, vaut également dans pas mal d'autres domaines.

Pour résumer: pour avancer, il faudrait systématiquement distinguer clairement les objectifs des modalités d'implémentation. Et pour s'aider à ne pas s'enfermer dans des solutions ou des modes de pensée, il pourrait être intéressant dans certains cas de s'écarter de la stricte terminologie MSTS.

Il faudra que je revienne plus tard sur les développements des mois passés et un certain nombre d'autres points touchant à ce sujet...

A+
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image

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

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

Messagepar StationWhere » 19 juil. 2014 15:40

Bonjour.
Je suis très attaché aux échanges que je trouve sur ASW. On trouve ici quelques personnes pour qui l'arbre ne cache pas la forêt.
Ce nouveau sujet, une fois de plus, m'interesse.
Comme je l'ai dit je crois dans d'autres posts, il y a plusieurs types d'utilisateurs ici et, en ce qui me concerne, je me sens atypique dans MSTS ou OR.
Ce qui me plait, c'est de mettre en oeuvre un réseau de voies disparues ou encore apparentes dans une région qui va de Limoges à Gaillac et de Tulle à Aurillac. Je trouve là matiére à activités de passagers, minerai, graines, vin, bestiaux, etc... ou je crois utiliser à peu près toutes les fonctionalités de MSTS. Des 6 routes fournies avec le logiciel, je n'ai jamais utilisé d'Acela sur le couloir Nord Est. Ca me pompe l'air de circuler sur un terrain plat en voyant défiler un paysage qui n'est pas le mien. La seule route que j'ai parcouru est celle de St Anton/Innsbruck dans la Golsdorf 380.
BB25187 a écrit :je vais donc commencer par parler des points d'attente

J'ai tenté d'utiliser les points d'attente pour pallier le fait que la priorité n'était pas toujours donné au service JOUEUR dans MSTS. Ca n'a jamais marché. Dans MSTS. Dans OR je n'ai jamais essayé.

Depuis que je suis inscrit sur ASW, j'ai, à plusieurs reprises, fait appel à des expèriences concernant le CHARGEMENT (refueling). Apparemment, personne ne s'est préoccupé de ce point.
Pourtant, je trouve ça pas mal de faire un plein de sable, charbon, fuel, eau, courrier, etc... pour mener à bien une activité. (des activités dans ce sens existaient dans EUROPE1 et EUROPE2). Ce n'est que dans les dernières versions récentes de OR qu'on a pu aperçevoir un début sur ce chapitre. Entre nous, c'est bien la preuve qu'il est (ou était ) tourné vers le tout électrique. Aujourd'hui encore, OR, par appui sur la touche 'T', peut indiquer: "Il n'y a aucun point de ravitaillement accesible, faites le plein immédiatement".!!!! Ouaf! Ouaf!
Que dire du fonctionnement de OR pour ce qui est des DIESEL et VAPEURS.... C'est le jour et la nuit entre MSTS et OR!

CM63 a écrit :...moi j'aimerais bien un mode "flotte...

Je pense qu'un mode flotte serait trop lourd vu le nombre de créations un peu bancales. Par contre un système de functions library concernant les freins, les sons, l'accouplement, etc... serait utiles aux concepteurs de wagons et d'engins.
Il me semble que la gestion des textures de terrain est très lourde sous MSTS (et donc sous OR). Il existe, dans MSTS, un Bouton prévu pour repeindre le terrain. Ce bouton est inneficace en présence de format compressé. Pourquoi ne pas permettre au créateur de 'PEINDRE SON TERRAIN' comme ça lui chante? C'est implementé dans TrainZ et c'est du meilleur effet.

BB25187 a écrit :...le système de suivi des demandes et de vote....

Difficile à mettre en oeuvre... Le nombre de créateurs de routes ou d'objets, étant inférieur au nombre d'utilisateurs finaux, il y a de fortes chances que seuls Param Installation et FPS soient pris en compte. Et puis il faut nous laisser nun peu de problèmes à résoudre... Le petit truc qui marche presque mais c'est pas tout à fait ça....!

Enfin, il faut bien se rendre compte que si notre vieux MSTS est toujours là... C'est grace à OR. Non pas 'Abandonware'.

Cordialement
Dell XPS 8300 W10 Vers 64b.

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 21 juil. 2014 0:14

Merci de vos réactions.
Un peu tard pour répondre correctement, je le ferai rapidement.

Stef
Steamy stef - Image

Avatar du membre
BB25187
Administrateur
Messages : 15057
Enregistré le : 09 mai 2004 1:07
Localisation : Grenoble
Contact :

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

Messagepar BB25187 » 21 juil. 2014 16:09

Hello,

nicober a écrit :Faire un effort pour trouver ce qui ne fonctionne pas sur certaines routes qui refusent toujours de fonctionner sous OR. Comme par exemple la route RFSP qui au lancement donne toujours un message d'erreur


J'ai soumis un bug et un patch. Aux développeurs de voir s'ils veulent l'intégrer, le problème d'origine venant bel et bien de la TDB de la route!

A+
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image

nicober
Modérateur
Messages : 2200
Enregistré le : 21 févr. 2004 22:36
Localisation : Québec (Qc) Canada
Contact :

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

Messagepar nicober » 21 juil. 2014 19:08

Bonjour

Désolé pour le retard à répondre mais quelques jours de congé ça ne fait pas de tord, surtout en été qui est bien trop court ici.

Pour ce qui concerne les vues de caméras dont la vue 4:
Le sujet a déjà été évoqué à quelques reprises sur le forum d'Elvas Tower mais James Ross ne semblait pas intéressé a y apporter des modifications. Mais depuis peu,il y a un post de Dave Nelson ( Genma Saotome ) le grand manitou du forum d'Elvas Tower qui a repris ce sujet de ce que devrait être les caméras sous OR et il n'y est pas allez avec le revers de la cueillère avec ses suggestions.
http://www.elvastower.com/forums/index. ... mera-sets/
Reste à savoir ce que cela va donner, mais ses propositions fortement détaillées semblent très intéressantes. Je pourrais facilement vous en faire une démonstration en vidéo de l'inutilité de la vue 4 tel qu'elle existe présentement sous OR sur la route russe à voies étroites UZD_Sh (Indusrial Route). Vous me direz que la vue 8 permet beaucoup de flexibilité. Oui j'en conviens, mais elle ne suis pas votre train et vous devez vous ajuster bien avant que votre train n'arrive. Dans le cas des TGV c'est impensable.

La simplification des fichiers ENG et WAG.... :
Ici aussi le sujet a été évoqué avec détails par Genma Saotome sur Elvas Tower le 23 juin 2014.
http://www.elvastower.com/forums/index. ... le-w-wags/
2 problèmes semblent empêcher ceci:
- La compatibilité de ses fichiers avec MSTS
- Les fichiers consists semblent incapables d'utiliser un chemin absolu s'ils sont organisés dans une bibliothèque centrale.
Il ne semble pas y avoir de suite pour l'instant.

Pour les routes de MSTS qui ne fonctionnent pas sur OR:
Je n'ai pas encore soumis de rapports sur ces routes, car il m'a sembler avoir lu de la part d'un membre de l'équipe de OR que dorénavant on devait s'arranger avec ces routes. Ici je pense plutôt ouvrir un sujet à part soit sur Elvas Tower ou encore ici avec bien entendu le fameux fichier log accompagnant toute session sur OR. RFSP est l'une des 3 routes qui me posent des problèmes et Vincent vient de s'en occuper en proposant un patch dans la rubrique des bugs de OR. Good!
viewtopic.php?f=125&t=22937
Je m'occuperai de vous soumettre les 2 autres prochainement.

Point d'attente et autres:
Je n'élaborerai pas beaucoup plus sur les points d'attente n'ayant pas une grande expertise dans les activités. Par contre permettre de poser son point d'attente exactement où le créateur d'une activité le souhaite serait bien plus logique que de tout le temps déplacer ce point au prochain aiguillage. Je ne vois pas pourquoi un train devrait toujours poursuivre jusqu'au prochain aiguillage, par contre le chemin réservé à ce train pourrait lui se poursuivre jusque là.


Pour ce qui concerne le mode "Flotte":
A mon avis le système des Mini-Routes gèrent très bien une flotte de trains. A titre d'exemple j'ai divisé les USA en plusieurs parties dont chacune a sa propre flotte. L'Ouest gère le UP et le BNSF, l'Est gère le NS et le CSX - J'ai une section spéciale pour la Milwaukee RR. Même scénario au Canada avec le CP et le CN, plus le Québec. En Europe, j'ai divisé cela par pays. Mais je peux toujours subdiviser peu importe la région, par époques, par voies de différentes largeurs ou encore les tramways et les subways. Open Rails permet facilement d'ajouter de nouveaux profils d'installation et de gérer tout cela efficacement. L'inconvénient majeur, encore une fois hérité de MSTS, c'est de devoir toujours dupliquer les fichiers Sounds et Global qui devraient se retrouver en 3 ou 4 Global dans un dossier commun. Je n'ai jamais compris pourquoi en 2001, à la sortie de MSTS, il fallait toujours multiplier les fichiers, alors qu'en ce temps là l'espace sur DD était très restreint comparativement à aujourd'hui. Les programmeurs de Kuju ne devaient pas connaitre les possibilités de l'aliasing. Pourtant il ne s'agit que de donner un chemin pour situer l'endroit où sont installés les fichiers communs.

A+
Nicober

«La Terre n’appartient pas à l’Homme, c’est l’Homme qui appartient à la Terre.»
[ Sitting Bull ]

steamystef
Messages : 103
Enregistré le : 08 janv. 2004 14:10
Localisation : Erpent, Belgique
Contact :

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

Messagepar steamystef » 23 juil. 2014 0:38

BB25187 a écrit :...Le premier point concerne le système de suivi des demandes et de vote. Je pense que c'est en effet une bien meilleure méthode que les long fils de collectes des desideratas, qui finissent par partir dans tous les sens et ne permettent que très difficilement (voire très rarement) de dégager des points de vue communs.

Nous sommes bien en phase mais le Team OR n'est pas le seul concerné dans ce cas, il y a aussi les responsables des sites hébergeurs.

BB25187 a écrit :Cela étant dit, le "tracker" de "bug" (mais il contient déjà autre chose que des bugs au sens strict) permet déjà (ou permettrait facilement):
- De distinguer ce qui est du niveau du défaut de ce qui est une demande de fonctionnalité (ajout d'une catégorie particulière si elle n'existe pas encore). On a souvent recours à ces catégories multiples dans les systèmes de suivi et bases de connaissances logicielles. Ça permet de regrouper des échanges et discussion sur un bug/une évolution dans un enregistrement particulier, donc sans mélanger tous les sujets. Ça reste bien entendu moins formel qu'un système de vote.
- A n'importe quel utilisateur, d'indiquer qu'un enregistrement l'affecte également. Bien utilisé pour les vrais bugs, cette fonctionnalité permet de connaitre l'impact du défaut en nombre d'utilisateurs... pour peu bien entendu que les utilisateurs fassent l'effort de cliquer! Pour une demande d'évolution, elle permettrait de savoir combien d'utilisateurs sont intéressés.

Je ne suis pas assez à l'aise avec ce système, je n'interviens que rarement dans cette partie vu qu'au départ je suis plus dans la mise en place d'un nouvel outil. Mais les choses évoluent avec le départ de Rob.

BB25187 a écrit :Le second point concerne les points d'attente. A mon avis, il soulève une question bien plus générale. Avant de la développer et de généraliser, mais pour vous permettre de mieux comprendre mon propos par la suite, je vais donc commencer par parler des points d'attente. Je pense en effet que fournir un moyen de pouvoir arrêter un train de trafic pendant un temps donné à un endroit donné (pas forcément au niveau d'un quai ou d'un signal) est quasiment indispensable pour permettre la mise en place d'activités intéressantes. Pour le train du joueur, c'est pareil: on imagine bien une mission qui imposerait un arrêt d'une durée bien spécifiée en pleine voie.
Ça, c'est un objectif. Il faut le distinguer clairement des moyens employés pour l'atteindre, autrement dit, des modalités d'implémentation. Pourquoi devrait-on reprendre absolument la manière dont ces points d'attente étaient définis et utilisés dans MSTS? Ne serait-il pas plus judicieux de profiter de la mise en place des "timetables" pour intégrer une notion de points d'arrêt programmé dans la marche des trains qu'elles décrivent? Plutôt que de singer simplement MSTS, on ouvrirait la porte à un système intégré et largement plus puissant de définition des "activités". De plus, un des usages des points d'attente dans MSTS consistait à cacher la misère de la gestion des priorités des trains. Ne serait-il pas plus intéressant et plus ambitieux d'implémenter un véritable système de gestion des priorités, qui permettrait d'aller bien au delà du périmètre très limité des points d'attente? Là encore, les timetables peuvent être le bon endroit pour donner la main à l'utilisateur pour contrôler ces priorités. Si l'on allait par là, les trains fantômes, qui n'étaient eux aussi que des palliatifs mal-pratiques deviendraient sans doute totalement inutiles.

Le soucis des WP et des trains fantôme c'est la compatibilité avec MSTS. Deux courants contraires se font sentir dans le team et l'idée actuelle est de concilier autant que pssible.
Les 'timetable', il s'agit du dernier projet de Rob. Comme personne n'a réellement suivi son travail et que ce n'est pas une urgence, je crains que cela soit quelque peu reporté à une version ultérieure.

BB25187 a écrit :En abordant la question des points d'attente et des trains fantômes, on voit qu'une manière d'avancer consiste d'abord à bien faire la distinction entre l'objectif à haut niveau et les modalités d'implémentation. Si certains objectifs généraux doivent être repris des fonctions de MSTS, en revanche à mon avis il ne faut pas s'enfermer dans des modalités d'implémentation qui ne se justifient plus en dehors du contexte de MSTS. Il vaut bien mieux envisager une implémentation plus générique, plus flexible et qui offrirait davantage de possibilités.

Les choses ne sont pas aussi simples malheureusement. Dans l'état actuel du développement, nous devons faire avec ce que nous héritons de MSTS. Tu l'as certainement remarqué pour d'autres fonctionnalités, le team a bien du mal à se détacher des anciens formats. Les techniques actuelles nous permettraient d'utiliser de nouveaux types de fichier pour 'compléter' les infos mais on en reviens toujours aux vieux formats. Il est vrai que cela pourrait nécessiter des outils plus spécifiques, comme l'éditeur d'activités ou plus modestement sa partie 'station' qui utilise un format JSON.

BB25187 a écrit :Il y a un autre point sur lequel on a très bien vu que la tentative de simple reproduction de ce qui se faisait dans MSTS n'était pas la bonne voie: il s'agit des fichiers d'environnement. OR permet une gestion dynamique des conditions météo. Pourquoi s'en priver en ne reprenant que le support des environnements qui existait dans MSTS? Il vaudrait bien mieux réfléchir à mettre en place ce qui manque dans OR pour varier les ambiances: amélioration des précipitations, variations de l'aspect des couvertures nuageuses, variations des teintes au lever/coucher du soleil, variation des hauteurs et teintes des cours d'eau et des lacs, ... tout cela sans forcément chercher à s'appuyer sur le format des fichiers d'environnement.

Idem que précédemment. Cela va vite, et la mise au point prend du temps que l'on ne peut consacrer à ce genre d'évolution, mais cela reste intéressant à noter.

Merci,
Stef
Steamy stef - Image


Retourner vers « ORTS: Général »