PN automatique

[GerardS 539]

Bonjour:

 

Passage à niveau automatique.

Animation : Fermeture et ouverture des barrières.

Fermeture : Commandée par le passage du train,

Fonctionne : - En double voie pour un seul sens de circulation sur chaque voie.

- En voie unique pour les deux sens de circulation.

Ouverture : Les barrières se relèvent automatiquement après 45 secondes.

Le temps de fermeture et d’ouverture des barrières est de 10 secondes

 

A terminer les feux rouge clignotants et le script de commande pour réinitialiser les commandes après le passage d’un convoi.

[attachmentid=1512]

 

[attachmentid=1513]

[attachmentid=1514]

 

[attachmentid=1515]

 

Erratum : Bravo -Julien pour ta, pardon… tes 15000, de beaux engins.

- Spud : pour ta ligne, téléchargée mais pas encore installée, mais cela va se faire.

 

Cordialement

GSi

 

[Loïc 117]

intéressant tous ça

[Spud 144]

Salut,

 

D'abord merci, et merci a toi aussi

 

Vraiment intéressant, je sens qu'il va y avoir de nouveaux objets à installer en plus de la nouvelle signalisation que Jym est en train de nous mettre en place, avant la mise en ligne de la version 1 de la ligne....

 

Par contre petite demande, est il possible que le PN fonctionne avec 4 voies avec un sens de circulation ?

 

Si pas le seul pn ou il y a quatre voies restera en objet statique....

 

Bye

[Jules31 44]

la nouvelle signalisation que Jym est en train de nous mettre en place

 

Je n'ai vu aucune information en ce sens. Pourrait-on en savoir plus ?

[Jules31 44]

Passage à niveau automatique.

Salut Geluc.

Dis-moi, tu bosses sur le sujet des PN avec dede34 ou travailles-tu en solitaire ?

 

Jules

[Spud 144]

Je n'ai vu aucune information en ce sens. Pourrait-on en savoir plus ?

 

Salut,

 

En fait Jym est en train de revoir complète la signalisation et les limites de vitesses de ma ligne...

Pour plus de conformité et de réalisme. et pour un fonctionnement optimal des signaux....

 

Bye

[jym26 434]

Salut,

 

En fait Jym est en train de revoir complète la signalisation et les limites de vitesses de ma ligne...

Pour plus de conformité et de réalisme. et pour un fonctionnement optimal des signaux....

 

Bye

 

Bonjour à tous,

 

Je confirme, mais c'est un vrai plaisir de donner un coup de main tellement cette ligne est bien belle.

Et puis c'est un test grandeur nature pour mes signaux et cela me permet d'être confronté à toutes sortes de situations au niveau de la signalisation et de mettre en place des procédures de test de validation des voies.

Faut dire que "spud" nous a gâté coté diversité des parcours et variété des plan de voies, tout y est, c'est une mine inépuisable de situations différentes avec des problèmes liés directement au programme de kuju et des ses bugs cachés et autres fonctionnements bizaroïdes mais aussi de valider les paramètres de voies (sens de circulation, vitesse limite, aiguillage manuel ou automatique, ect) qui sont difficile à tous maitriser lors de la pose de la voie.

Un petit conseil au créateurs de lignes, testez, testez, testez chaque morceau de ligne en créant des activités sur les différents tronçons, c'est encore le meilleur moyen de j'ai trouvé pour vérifier le "bon état" de la voie.

 

Et bon courage pour la réalisation de ce passage à niveau qui s'annonce de bonne facture et en plus c'est un objet vraiment important qui donne un "very french" cachet sur une ligne bien de chez nous.

 

A bientôt

 

Jean-Yves

[GerardS 539]

Bonjour.

à Jean Yves

 

Je profitte de ton retour sur le forum pour te soumettre une demande concernant tes signaux lumineux.

 

Je pense qu'il manque 2 PL

Un PL à 3 positions -- S un feu rouge -- A feu jaune --VL feu vert

 

et un PL 4 positions --S un feu rouge -- A un feu jaune --VL VL feu vert clignotant -- VL feu vert

 

ceci pour éviter l'usage à tort du feu jaune clignotant.

 

une autre remarque les PL ral 30 et ral 60 présentent à l'annonce d'un carré l'avertissement et le ralentissement, alors que dans ce cas seul l'avertissement devrait ètre présenté.

 

Pour le reste tes signaux dont tout à fait remarquables

 

Pour les PN

le feu cli est ajouté

[attachmentid=1520]

[attachmentid=1521]

cordialement

 

Geluc

 

 

[jym26 434]

Bonjour.

à Jean Yves

 

Je profitte de ton retour sur le forum pour te soumettre une demande concernant tes signaux lumineux.

 

Je pense qu'il manque 2 PL

Un PL à 3 positions -- S un feu rouge -- A feu jaune --VL feu vert

 

et un PL 4 positions --S un feu rouge -- A un feu jaune --VL VL feu vert clignotant -- VL feu vert

 

ceci pour éviter l'usage à tort du feu jaune clignotant.

 

une autre remarque les PL ral 30 et ral 60 présentent à l'annonce d'un carré l'avertissement et le ralentissement, alors que dans ce cas seul l'avertissement devrait ètre présenté.

 

Pour le reste tes signaux dont tout à fait remarquables

 

 

cordialement

 

Geluc

 

Bonjour,

 

Effectivement, tes remarques sont judicieuses. J'avais fait un seul jeu de signaux qui incluaient systématiquement le feu jaune clignotant dans la séquence, pour limiter intentionnellement le nombre de types de feux proposés qui est déja important vu les différentes caractéristiques et surtout le mode de positionnement dans l'éditeur avec les liens et tout ça. Mais effectivement ce feu jaune clignotant devrait être réservé aux cantons courts et donc ne pas être la règle systématique .

Je dis ça en parlant comme un spécialiste , mais en fait , n'étant pas mécanicien à la SNCF et même pas à la SNCF du tout d'ailleurs malgré une tentative de passage du concours d'électricien au service des lignes (y avait déjà de l'idée) mais c'était il y a trés longtemps je radote, je reste seulement amateur ferrovipathe, je ne tiens mes informations sur la signalisation SNCF uniquement de ce que j'ai pu trouver sur internet. ce qui veut dire que je suis ouvert à toutes les bonnes remarques concernant les erreurs contenues dans mon pack.

Je vais donc tenir compte de tes remarques dans une mise à jour des feux qui est en préparation. Mise à jour qui restera entièrement compatible avec la version actuelle bien sûr pour rassurer ceux qui utilisent déjà ce pack.

 

Voilà, allez je me remet au boulot....

 

A bientôt

 

Jean-Yves

 

[Jules31 44]

Bonjour tout le monde et en particulier Jym.

 

Je suis en train de faire une ligne de test (un anneau fermé à double voie avec des voies uniques complétant le tout et pleins d'autres gadgets), à moitié basée sur des sections de lignes et gares existantes (Ligne de Toulouse à Carcassonne). Je m'efforce à la base à tester les besoins en signalisation de dede34 pour sa ligne, et cela, en étant le plus réaliste possible aux niveaux des infrastructures de voie (et donc de la signalisation). J'essaie aussi de me faire plaisir car la signalisation, l'exploitation et la technique ferroviaire, c'est mon petit pêchée mignon. Pour tout cela, j'ai besoin de BAL avec des cantons de 2 km environ pouvant baisser à 1,5 km (besoin quelques fois du feu jaune clignotant), d'IPCS avec communications accessibles à 60 km/h, j'ai même ajouté une bifurcation accessible à 90 en voie déviée vers une voie unique. Sur une autre voie unique (qui est en réalité une VUSS), j'aurai aimé y essayer une signalisation automatique de type "BAPR à une voie banalisée". Pour finir j'ai une gare assez conséquente dont les besoins seront décris plus bas.

 

Je profite donc de ton intervention pour te soumettre quelques remarques sur des défauts constatés sur ta signalisation et te soumettre quelques idées d'amélioration :

 

1) Il serait bien d'avoir des carrés violets sur mats mais juste avec une cible à deux feux (un blanc et un violet) car ils font cruellement défauts. Sur ma ligne, je suis obligé d'utiliser des signaux nains au sol mais normalement, ceux-ci ne sont réservés que pour des manœuvres de refoulement sur voie principale.

 

Mais je te rassure, les carrés violets sur mâts existants sont pertinents même si les feux autres que blanc et violets ne sont pas utilisés dans tes signaux. On est censé les retrouver sur voie de service, sur un signal pouvant donner accès aux voies principales (dans ce cas, on peut avoir en plus du blanc et carré violet un avertissement, sémaphore et voie libre) car je rappelle qu'un feu blanc oblige à appliquer une marche à vue sur voie principale jusqu'au prochain signal.

 

2) Autre souhait, il s'agit des signaux de ralentissement. Il serait intéressant d'avoir plus de liens, ne serait-ce pour pour spécifier 2 ou 3 voies déviées sur lesquelles l'accès doit être limité à 30 ou 60. Je t'explique mon besoin, dans le cas d'une de mes gares qui disposent d'un plan de voie que l'on peut retrouver un peu partout, en tout cas qui est très courant. J'ai une gare avec une voie de passage accessible à pleine vitesse (160 km/h), trois autres voies à quai accessible à 60, et deux accès à un faisceau marchandise et à un faisceau annexe avec accès possible uniquement à 30. N'ayant pas de signaux de protection de la gare de type carré pouvant présenter le ralentissement à 30 et à 60, j'ai du imposer un franchissement général de la gare à 60 par TIV en amont de la gare, puis j'ai mis en place un couple R30/RR30 à l'entrée. Très bien sauf que je ne peux imposer le 30 que pour l'accès à un seul faisceau, et pas pour l'autre (présence d'un seul lien pour la voie déviée). Je n'ai également pas assez de liens pour pouvoir protéger l'ensemble de mes aiguilles sur voie principale (si je manœuvre certains aiguillage, le carré d'entrée couplé au rappel de ralentissement censé protéger ces aiguillages reste ouvert au lieu de présenter le carré fermé ...). La limitation à 60 imposée en amont de la gare est un moyen palliatif au premier problème mais je ne peux pas faire autrement.

 

3) Autre soucis très gênant, c'est le comportement des signaux R/RR quand ils sont pris à revers car comme signalé sur ton site, ils ne se réinitialisent pas correctement. Si tu veux faire une ligne avec une ou plusieurs voies banalisées, tu es foutu, tout comme pour faire des IPCS. Sur ma ligne, j'ai 2 pas d'IPCS avec communications franchissables à 60, donc je dois utiliser le couple R60/RR60, et je me suis retrouvé bloqué plusieurs fois. Une solution palliative est d'utiliser les TIV à distance et d'exécution à 60 mais ce n'est pas règlementaire.

 

4) Et puis, j'ai remarqué qu'un signal RR suivi sur l'une des voies d'un détecteur de dépôt déconnait quelque peu, car des fois, le signal RR reste bloqué sur une indication sans raison, comme la voie libre, l'avertissement ou carrément le sémaphore... Je n'ai pas trouvé de raison. Cela se passe quand je veux diriger un train de mon avant-gare vers mon faisceau frêt et vice-versa. Il peut aussi y avoir des inter-blocages avec le carré violet de sortie de mon faisceau vers les voies principales. C'est assez bizarre. Je pense qu'il faut que j'investigue d'avantage de mon coté pour préciser l'objet du délit et aider au débugage.

 

5) Une autre idée d'amélioration, ce serait d'avoir un signal à cible ronde avec juste la voie libre et l'avertissement (éventuellement en plus R30 / R60) pour pouvoir faire du BAPR ou simplement annoncer un carré isolé. Ce signal supporterait donc une plaque "A". En plus, ils sont utilisés très souvent sur les IPCS). L'idéal, ca serait que leur franchissement n'est aucun impact sur le signal amont (cas du BAPR) car ce type de signal ne se trouve pas à la fin d'un canton.

 

6) Et si le choix de faire un signal à cible ronde était pris, pourquoi pas faire un disque pour les voies uniques, qui fonctionneraitcomme un carré, mais dont l'indication carré serait remplacée par un disque (feux jaune et rouge).

 

 

Pour finir, je pense qu'au niveau de la signalisation, on ne peut pas faire beaucoup d'économie sur les signaux. Cela doit être très fastidieux à mettre en place, mais je pense qu'il est difficile de faire autrement. Je te laisse en tout cas faire le tri car je sais que je suis assez pointilleux avec la signalisation, tu ne m'en voudras pas j'espère Ça doit être déjà assez chiant de faire ce que tu as fait. As-tu regardé au fait du coté des travaux d'AndiS car il semble avoir fait un grand boulot de mise à plat des scripts. J'aurais aimé l'aider au niveau de la conception des scripts mais il semble être assez avancé et travaille avec Paninic pour mapper avec le monde de la signalisation française. Je me demande ce que cela donnera mais s'il y a moyen de mutualiser les efforts, je pense que ça ne peut être que bénéfique.

 

En tout cas, je suis le dossier de prêt et s'il faut que je mette la main à la patte, ça serait avec plaisir en fonction de mes disponibilités.

 

Bonne journée tout le monde et good luck !

Edited May 1, 2009 by Jules31

[GerardS 539]

Bonjour

 

PN automatique,

Les feux cligotants sont terminés.

[attachmentid=1522]

 

[attachmentid=1523]

 

Reste à terminer le script

 

Cordialement

GSi

[Jules31 44]

Bonjour Geluc.

 

Je renouvelle ma question : travailles-tu avec Dédé sur les PN car il a déjà fait des feux et des barrières (d'un modèle différent des tiennes) et il cherche à scripter l'ensemble.

 

Je trouve également la visière de tes feux bien trop courtes. De plus, ils ont un aspect un peu bizarre tes feux (je ne sais pas si c'est la qualité de l'image qui fait çà ou pas mais les bords ne sont pas nets (ainsi que pour la cloche).

 

Benoît (alias Jules)

Edited May 5, 2009 by Jules31

[dede34 3]

Bonjour Geluc.

 

Je renouvelle ma question : travailles-tu avec Dédé sur les PN car il a déjà fait des feux et des barrières (d'un modèle différent des tiennes) et il cherche à scripter l'ensemble.

 

Je trouve également la visière de tes feux bien trop courtes. De plus, ils ont un aspect un peu bizarre tes feux (je ne sais pas si c'est la qualité de l'image qui fait çà ou pas mais les bords ne sont pas nets (ainsi que pour la cloche).

 

Benoît (alias Jules)

Salut jules

Je vais repondre a sa place.

Non, Geluc ne travaille pas avec moi, et ne m'a jamais contacté.

S'il prefere travaillé seul, aucun probleme tout le merite et pour lui s'il reussi a faire marcher son PN

Maintenant apres avoir réussi, s'il veut bien m'aidé a faire de meme avec le mien, je lui passer le source 3ds max, ou meme le contraire.

Maintenant s'il veut refaire tout les PN, aucun soucis !!

je ne suis pas jaloux :lol:

Geluc, si tu y arrive t'es un chef

Bye

 

[GerardS 539]

Salut jules

Je vais repondre a sa place.

Non, Geluc ne travaille pas avec moi, et ne m'a jamais contacté.

S'il prefere travaillé seul, aucun probleme tout le merite et pour lui s'il reussi a faire marcher son PN

Maintenant apres avoir réussi, s'il veut bien m'aidé a faire de meme avec le mien, je lui passer le source 3ds max, ou meme le contraire.

Maintenant s'il veut refaire tout les PN, aucun soucis !!

je ne suis pas jaloux :lol:

Geluc, si tu y arrive t'es un chef

Bye

Bonjour.

 

A dede34.

 

Non,je ne veux pas refaire tous le PN. D'ailleurs j'ai opté pour ce type de barrières pour, justement ne pas faire double emploi d'avec le tien.

 

Je travail sur 3Dcanvas donc je pense que nous ne pouvons associer nos efforts qu'à partir de BlueprintEditor .

 

Pour le script

J'ai la commande de fermeture de la barrière par passage du train sur le lien

2 liens : un pour chaque sens de marche. Voie unique ou pour chaque voie en DV.

 

Par contre le temps de fermeture des barrière est forfaitaire, les barrières s'ouvres aprés 45 s.

 

Pour plus d'infos contact moi par couriel.

 

Cordialement

 

Geluc

 

 

 

[Jules31 44]

Hello Geluc.

 

J'aurais aimé te soumettre 3 idées d'améliorations pour tes objets (non pas sur la modélisation mais sur l'interaction de ton objet avec la voie via le script et le lien). Je les ai classé par importance décroissante.

 

1) Pour les doubles voies, il me semble qu'il serait souhaitable d'avoir 4 liens au lieu de 2 (2 par voie pour chacun des sens de circulation).

 

Voila pourquoi:

 

- pour gérer les cas d'IPCS ou de voies banalisées

- pour gérer les circulations à contre-voie, en plaçant le lien pour le sens opposé au sens normal à quelques mètres du PN pour simuler la zone courte (zone de quelques mètres en aval du PN provoquant la fermeture du PN quand elle est occupée lors de circulation à contre-voie).

 

Cette amélioration me parait la plus souhaitable étant donné le nombre de cas réel qu'elle pourrait couvrir et qu'il serait donc possible de modéliser sur les lignes de RS.

 

2) Pourquoi ne pas avoir un PN pour le cas avec plus de 2 voies ? Je propose un PN avec 3 voies parcourables dans les deux sens (donc avec 6 liens, 2 par voie). Le cas avec 3 voies se rencontrent sur certaines lignes ou proche de certaines gares. Par contre, faire un PN avec plus de 3 voies ne me parait pas utile pour le moment, à part pour des cas vraiment isolés.

 

3) Alors là, il serait de revenir sur le principe de fermeture pour une durée forfaitaire pour se rapprocher plus de la réalité :

 

- à savoir pour une voie et un sens de circulation avoir 2 liens, un permettant de provoquer la fermeture du PN, l'autre provoquant son ouverture.

 

 

 

Voila. Qu'en penses-tu ?

 

Jules

[GerardS 539]

Bonjour.

A Jules

 

J’avais décidé de ne plus intervenir, mais je vais tout de même te répondre.

 

1) Nul en anglais, et pas mieux en programmation je galère pour créer ce script.

 

2) Le script en l’état est un mélange de HP_Shunt.lua (Signal anglais de manœuvre) et de UK AWS permanent.lua (Balise AWS permanent)

 

Ceci pour éviter que le PN se comporte comme un signal et interfère sur la signalisation.

 

Pour le moment chaque barrière comporte 2 liens, qui doivent être franchi dans le sens normal.

Donc 4 pour le PN complet.

Ce nombre étant ramené à deux si création du PN complet, deux barrières ou même 4 avec feux clignotants.

 

Chaque lien comme pour l’AWS ne réagit que dans un sens de circulation.

 

Après franchissement les commandes ne sont pas réinitialisées, ce qui fait que le deuxième mouvement ne ferme pas le PN.

 

La fermeture à durée forfaitaire me déplait également,

 

Obtenir la fermeture par le premier lien et l’ouverture par le second ne posent pas de problème, mais pour le moment

je n’ai que deux liens opérationnels.

 

Donc reste à faire :

- fermeture et ouverture du PN commandées par un lien.

(Comme c’est la loc qui déclenche la commande le lien d’ouverture devra donc être placé à 750m du PN (longueur maxi des trains marchandises si cela n’a pas changé)

- Rendre opérationnel plus de deux liens pour obtenir ces améliorations.

 

J’ai fait parvenir à dede34 mon script , peut-être pourra t’il l’adapter à son PN et surtout l’améliorer .

 

Nota. Rail Simulator 2 va sortir au mois de juin, S’il comporte des PN opérationnels comme M.Train Simulator, avec commande du PN et arrêt de la circulation routière tout ce travail devient obsolète.

Raison pour laquelle j’ai arrêté l’élaboration de la Ligne TER Alsace.

 

Cordialement

Geluc

 

 

 

[Jules31 44]

Je comprends ton soucis vis à vis de RS2.

je suis aussi content de trouver une base commune de réflexion sur ces PN.

 

Finalement, comme trop souvent, le problème réside encore dans les scripts LUA, par le peu de connaissance de la communauté à leur sujet, par le manque d'aide de kuju, et par le manque de compétence en programmation sur le forum. Le fait que ces scripts soient dépendants de la plateforme de simulation n'encourage pas non plus les vocations car l'interopérabilité et la maintenabilité des créations se voit alors compromise. Pourtant on devrait bien voir que l'on devra toujours supporter cet inconvénient et l'on devra toujours porter les scripts d'un simu à l'autre (jusqu'au jour où les boites de développement s'accorderont à définir des normes communes en ce domaine, mais ne rêvez pas :lol: ). Cela demande donc d'être plus entreprenant à ce niveau et devrait mobiliser plus d'effort qu'actuellement. Mais je suis pessimiste sur ce point quand je vois que mon post sur le langage LUA n'a mobilisé personne.

 

Pour le reste (à savoir le travail de modélisation), les compétences sont là. Malheureusement, je regrette quand même plusieurs choses qui me semblent être un frein aussi important que le précédent pour le développement de simulateurs ferroviaires en France. La première est le peu de vision globale qu'ont les modeleurs. Quand un thème particulier commence à être modélisé, il ne l'est souvent que de manière parcellaire, et cela nuit à la mise en place de scripts adaptés car trop souvent ces scripts ne sont mis au point que pour la partie qui a été modélisé sans vision d'ensemble, et quand les modèles sont par la suite complétés, les scripts ne sont pas alors pas prévus pour et cela exige un gros effort pour leur intégrer les nouveaux modèles. L'autre point est le manque de collaboration et de transparence de la communauté en terme de modélisation de ce type, par l'absence de diffusion des modèles eux-mêmes (pas de problème pour les scripts car les packages distribués pour RS inclus ses scripts en clair). Il est alors impossible de mener en parallèle la modélisation et la conception de scripts par les spécialistes en leur domaine, ou alors d'envisager d'enrichir un jeu d'objets en restant compatible avec ceux déjà modélisés.

 

Prenons l'exemple de la signalisation. Ce que je dis plus haut est flagrant. Il y a peu de signaux modélisés, les modèles ne sont pas publics (donc impossible de les enrichir par les autres créateurs en étant compatible avec les signaux existants), les scripts ont été écrits (ou devrais-je dire adaptés à moindre coût à partir de scripts faits pour d'autres type de modélisation) pour les quelques objets modélisés, sans vision globale de la signalisation en France et sans conception globale. Pensez alors si on avait eu des signaux mécaniques (qui sont morts-nés) à rendre interopérable avec la signalisation lumineuse existante. Pensez à l'impact sur les scripts à écrire. Aurait-il été aisé d'utiliser les scripts existants sans les remettre profondément en cause ?

 

Malheureusement, la communauté ne semble pas s'orienter dans le bon sens, et les efforts à mettre en œuvre sont alors très épuisants et désespèrent beaucoup de monde, créateurs comme utilisateurs. On est une communauté faible, désorganisée, sans vision long terme. Tant qu'il n'y aura pas de prise de conscience collective sur ce point, les gens travailleront tous de leur coté (ou par groupes isolés) et nous tomberont dans les travers que j'ai décrit au dessus. Dans d'autres pays (comme chez les anglo-saxons), cela se passe mieux, car probablement ils ont plus d'appuis chez les développeurs de simulation (par exemple la signalisation allemande ou anglaise est déjà fournit et assez élaborée) et les communautés d'utilisateurs et de créateurs sont bien mieux organisées. Je rêve du jour où des gens en France se regrouperont pour fonder des projets collaboratifs proches de ce qu'on trouve dans le domaine des logiciels libres sur internet.

 

Mais si on laisse ainsi sans rien faire, sans rien dire, on n'avancera pas.

 

Idem, si tu décides de ne plus répondre sur ce forum (ce qui est ton droit le plus total), je te le dis franchement, même si il y a eu des critiques assez virulentes (je comprends les critiques mais pas la virulence, soyons clair), ta présence et ta participation sur le forum ne peut qu'être une bonne chose pour faire avancer la communauté, et vu la faiblesse de celle-ci, nous avons besoin de tout le monde en France.

 

Dernière info, je suis en train de bosser avec dede34 sur sa ligne et sur les PN, et de ce fait, je compte bien mettre mon nez dans les scripts que tu lui as transmis pour voir ce que je peux faire. Bien entendu, si l'on fait des progrès à ce niveau, tu seras mis dans la boucle comme cela doit.

Edited May 13, 2009 by Jules31

[pierreg 3,466]

Bonjour à tous,

 

Jules31, à propos de ton post sur le langage LUA : merci. Je l'ai lu, je me suis dit : "on verra plus tard, on ne va pas se disperser". Et puis, comme je l'ai lu sur UKTrainsim, à quoi bon développer une signalisation spécifique si la moindre rame AI n'arrive pas à la respecter ?...

 

Au risque de ne plus rester dans la bonne rubrique (PN automatique : Julien, tu peux déplacer ), je veux quand même répondre au reste de tes propos en donnant mon impression :

Bien sûr les développements pourraient se faire de façon plus coordonnée mais depuis six mois que je me suis vraiment mis à RS et parcouru les forums un peu partout, l'impression est la même : RailSimulator a promis beaucoup mais il est totalement démotivant pour les développeurs.

 

Que ce soit aux US, en Angleterre, en Allemagne, en Italie ou en Espagne, au bout de 18 mois, il y a très peu de choses nouvelles opérationnelles et terminées. Pour ce qui est du matériel roulant freeware, il me semble qu'il y a moins d'une vingtaine de modèles publiés dont la moitié sont des transpositions de modèles MSTS et beaucoup sont incomplets (ombres, cabine, sons, etc...).

Chez les anglo-saxons donc, je ne vois pas en quoi ça se passe mieux : ça cause plus (avec un tout petit nombre de compétences pointues) car ils sont plus nombreux, c'est tout...

 

À mon avis cela n'est pas une question d'organisation mais tient à deux raisons : le marché du simulateur ferroviaire "ouvert" est étroit et TrainZ et MSTS l'ont épuisé dans tous les sens du terme : on a vu, on a joué et seuls les très mordus sont restés fidèles. Les fidèles ont vieilli, leur motivation a changé de domaine et la nouvelle génération prête à retrousser les manches pour mettre le nez dans le cambouis est encore moins nombreuse que la précédente.

 

Quelques développeurs passionnés se sont mis à RS, d'autres ont attendu MSTS2 mais le marché semble bien terminé. De plus RS, à part un rendu graphique amélioré mais mal finalisé, se révèle totalement défaillant sur le réalisme de l'exploitation ferroviaire qui pourrait faire l'intérêt d'un tel logiciel (TrainZ avait pris initialement le parti "ludique" avec un peu plus de réussite).

 

RS est un jeu et le développement pour RS est en général un loisir (certains font de la programmation pendant leurs loisirs) mais ce développement doit aboutir sinon, ce n'est plus un loisir, c'est une "galère". Je n'ai aucune compétence sur la programmation de la signalisation (je n'ai pas lu la doc) mais à lire les forums j'ai compris que le problème était le même que pour le matériel roulant : un paquetage très prometteur mais une foule de points de détail non résolus. La mise au point et la finalisation d'un matériel roulant dans RS consomme énormément de temps et de patience (alors que la modélisation 3D est souvent gratifiante en elle-même). Je vous ai d'ailleurs promis une petite FAQ évolutive sur le sujet... Ce sera ma façon de faire avancer les choses.

 

RailSimulator 2 risque de n'être rien de plus qu'un réétiquetage "a minima" du même logiciel avec quelques addons mais avec les mêmes bugs : sinon ça se saurait et l'équipe compétente n'aurait pas le temps de blogger comme elle le fait...

 

A+

PierreG

 

[pml3 303]

Tout d'abord, bravo à Geluc pour son PN.

Il est vraiment superbe.

 

et je rebondis sur l'analyse de Pierreg que je trouve particulièrement pertinente.

 

Développer pour RS, quand on dépasse les objets statiques, c'est vite compliqué,

et c'est difficile d'amener au bout, au jeu, un projet.

(j'ai peur pour la loco que j'ai commencé!)

 

Il faut être tenace, et ne pas faire plusieurs choses à la fois.

 

Bon courage pour les scripts, Geluc

[GerardS 539]

 

2) Autre souhait, il s'agit des signaux de ralentissement. Il serait intéressant d'avoir plus de liens, ne serait-ce pour pour spécifier 2 ou 3 voies déviées sur lesquelles l'accès doit être limité à 30 ou 60.

 

Bonjour

à Jules31

 

SNCF,Le rappel de ralentissement 30 et 60 répètent signal ouvert sur la loc.

Testé rappel de ralentissement 30 sur RailWorks ,répétition sur la loc , signal ouvert.

Donc pour le RR30 la répétition est correcte, pas encore testé RR60.

 

Autre sujet (réponse tardive, )

 

: Il y a quelque temps tu avais demandé à Jean Yves , la possibilité d’avoir un RR à plus de 3 liens (2voies), J’ai d’abord pensé que le RR (2 voies) était suffisant, ors ta demande était justifiée, Je viens de créer une situation où il me faut 6 liens (5 voies).

 

Comme Jean Yves à créer 6 RR30, J’ai modifié les fichiers concernant le RR30 N S pour obtenir un RR30 6 liens

 

[attachmentid=1663]

Sur Fichier bin ajout _5v au nom

 

[attachmentid=1664]

 

Remplacer les 3 liens par 6

 

[attachmentid=1665]

 

Sur Fichier .xml mêmes opérations

nom

[attachmentid=1666]

liens

[attachmentid=1667]

 

Résultat:

 

[attachmentid=1668]

 

Comme jean Yves à créer 6 RR30

[attachmentid=1669]

 

En gardant 2 RR30 d’origine , RR30_N_C et RR30_SP_C, on peut modifier les 4 autres et obtenir :

RR30 3v RR30 4v RR30 5v RR30 6v

 

cordialement

Geluc

 

 

[Jules31 44]

Merci Geluc pour ta réponse.

 

Je regarderai çà dès que j'aurai un peu de temps libre, chose que j'ai du mal à trouver ces temps ci ...