henrion

Merci, je comprends mieux. cela ne va pas être simple à programmer un pas d'IPCS

Je crois qu'il faut que tout le monde se calme car cela dérape sec et cela ne fait pas avancer le schmilblik. Comme je l'ai dit on a besoin de tout le monde. Certains sont très doués dans la création d'objets ou de matériel, d'autres dans la création de route..... Ils y mettent beaucoup de passion et de temps et on ne les remerciera jamais assez. D'autres par contre découvrent ce logiciel et ceux qui sont plus expérimentés les aident sans problème dans leur démarche. C'est à quoi sert un forum. La communauté est un tout qui doit être en harmonie. Arrêtons donc la guerre des petites phrases et revenons à l'essentiel. Chacun est là pour que l'ensemble de la communauté se retrouve soudée derrière ce simulateur. Donc faisons tous un effort. Si je peux suggérer à Julien de clore ce sujet afin que tout le monde retrouve sa sérénité. Bonne soirée PS: je n'ai pas vu que Julien avait déjà répondu. Désolé

Il serait intéressant de savoir combien de temps vous avez mis pour arriver à un tel niveau de qualité de vos créations. Cela donnerait une idée. Pour moi cela se compte en pas mal d'années de pratique. Personnellement je suis nul de chez nul en création 3D et c'est pas faute d'avoir essayé . Je suis toujours admiratif devant des créateurs tels que vous et cela quel que soit le logiciel .

J'en suis heureux car comme disait justement Erakis, on a besoin de tout le monde. Bonne journée

Bonjour Richard. Je vous remercie pour votre post. Je vous connais par site interposé puisque je fréquente aussi assidûment activitysimulatorworld. En effet j'ai en parallèle MSTS et railworks mais je dois dire que je suis plutôt tourné vers la simulation de vol . Sans faire de polémique aucune, j'ai toujours été surpris du peu d'intérêt que suscitait Railworks. Pourtant il me semble prometteur. MSTS ne doit sa notoriété qu'aux créateurs talentueux dont vous faites partie. Microsoft n'a fait qu'un patch. Depuis on a eu xtracks, le binpatch... Quand je regarde Railworks, je m'aperçois que l'on est déjà à plusieurs patchs et qu'il me semble mieux suivi que MSTS. Mais c'est quand même un produit commercial avec les défauts qui y sont liés. Sous MSTS, on est arrivé au bout de la représentation du matériel français, il ne manque plus que la BB 75000 et le matériel bimode, ce qui ne va pas tarder. Certains matériels récents comme les BB 27000 et 37000 de yoyo81 sont d'un niveau de représentation comparable à ce qui se fait sous Railworks. C'est pourquoi je me demande ce qui empêche les créateurs de se lancer sous railworks pour essayer de relancer la machine vers un logiciel quand même plus performant (et c'est normal qu'il le soit). Mais je me souviens que lorsque Rail simulator est sorti, ce fut sur les forums un tir groupé sur ce logiciel, ce qui a entraîné de facto une scission entre le monde de MSTS et celui de Railworks. D'ailleurs je ne m'amuserait pas à poser la question initiale de CMBH sur activitysimulatorworld car cela déclenchera tout de suite une réaction virulente. je crois qu'il faut laisser aux gens le temps d'évoluer. Je suis sûr que dans quelques temps l'intérêt pour Railworks apparaîtra et que la passerelle entre les deux logiciels se fera. Maintenant, ce qui me gêne c'est votre réaction vis-à-vis de ce site. Je ne suis pas webmaster mais je n'ai pas la même vision que vous. Je ne pense pas que l'on fasse la différence sur ceux qui viennent de MSTS ou pas. Ici on ne parle que de Railworks donc les choses sont claires. Nous avons affaire à des passionnés ou des curieux tout simplement et je n'ai pas du tout la sensation que l'on prenne les gens de haut. Il y a ceux qui ont des connaissances, qui les transmettent et ceux qui essayent d'en profiter. C'est ce qui fait un bon forum. Chaque fois que je pose une question, j'ai une réponse. Maintenant si je n'en ai pas c'est que personne n'est capable de me la donner. J'essayerai alors de trouver la réponse tout seul. Le fait de demander de faire une recherche avant de poser une question est commune à tous les forums que ce soit ceux de simulation de train ou de vol. Cela évite d'avoir à réécrire les mêmes choses. C'est je pense un bon principe à inculquer à ceux qui n'ont pas ce réflexe mais ce n'est en rien un rejet d'autrui. Si l'on sent que c'est un débutant, il est évident qu'une réponse lui sera fournie. En ce qui concerne l'aide , en fait il y a très peu de gens capables de donner un coup de main dans la création. Je pense que l'on est encore à l'époque de la découverte des finesses de ce simulateur. Si vous me posez une question sur la programmation des signaux, j'arriverai à vous donner une réponse mais pas en ce qui concerne la création d'objets ou de routes. Mais je crois que l'esprit d'entraide existe sur ce site car on a déjà pu le constater. En fait, ce qui m'intrigue c'est qu'il n'y a pas de vrai travail d'équipe comme on peut le voir dans Flight Simulator où il y a vraiment des équipes de créateurs. Mais c'était déjà le cas avec MSTS. Chacun travaille de son côté à un projet. Mais je conviens que c'est vraiment difficile à faire. Je regrette personnellement que vous ne fréquentiez plus ce forum car on a tous à apprendre des autres et j'espère que vous changerez d'avis. Amicalement Bernard

sauf que steam ne prend en compte que ceux qui sont dans le bon répertoire

le dossier railworks n'est pas à part puisqu'il se trouve dans le répertoire steam\steamapps\common

Bonjour. En effet j'ai eu le même problème en essayant de jouer avec une ligne téléchargée. J'ai eu le même message d'erreur concernant la ligne 113. En fait Railworks patine dans la semoule quand il ne trouve pas un asset ou matériel prévu par la route. j'ai donc tout désinstallé et tout réinstallé sauf que les assets n'apparaisaient pas et que le packageInfo était pratiquement vide (sauf les assets installés par le jeu). Donc, en l'absence d'avoir fait au préalable une sauvegarde des répertoire assets, routes et packageInfo, il faut réinstaller le jeu proprement, vérifier qu'il fonctionne avec les routes de base, faire une sauvegarde du jeu (cela évite d'avoir encore à le réinstaller s'il y a problème) puis réinstaller un par un tous les assets. Essayer le jeu. Si le jeu marche , faire une première sauvegarde des 3 répertoires ci-dessus avant de télécharger et d'installer une route supplémentaire. Si le jeu fonctionne, installer ensuite les routes supplémentaires en vérifiant au préalable qu'il n'y a pas d'update nécessaire à cette ligne. Une fois que c'est fait, et que cela marche refaire la sauvegarde des 3 répertoires cités ci-dessus pour être à l'abri d'un crash futur. Si cela ne marche pas contactes moi par MP Il ne faut pas baisser les bras car il y a une solution à tout. Bonne journée

Bonjour, Je vais vous raconter le gag qui vient de se produire chez moi sous Railworks. J'avais installé un tas d'assets et quelques routes en plus de celles d'origine. J'ai installé celle de SAD et lorsque je l'ai lancée, un message d'erreur est apparu et Railworks s'est bloqué. Je redémarre donc mon ordinateur et lorsque je lance Railworks, plus aucun asset n'apparaît ainsi que les routes supplémentaires installées. Or elles sont bien dans les assets et content et n'ont donc pas été supprimées du répertoire Railworks. Elles apparaisent dans le packager mais point dans le package manager. Je ne comprends donc pas pourquoi railworks ne les prend plus en compte. Si quelqu'un connaît une solution sinon je vais être obligé de tout réinstaller asset par asset. Bonne soirée.

En fait après désinstallation puis réinstallation, en cherchant bien j'ai compris ce qui s'est passé: Lors du blocage, cela a provoqué la perte d'un répertoire important de Railworks, celui appelé PackageInfo. Lorsque l'on installe un asset avec le package manager, s'installe également dans ce répertoire un fichier du même nom avec l'extension .pi. Si ce répertoire est détruit, il va être recréé à l'ouverture suivante de Railworks mais vide. Les assets seront toujours bien présents dans railworks mais n'apparaîtront pas dans le package manager. Le fichier à l'extension .pi peut être ouvert avec notepad et définit les différentes composantes de l'asset. C'est donc un répertoire important à sauvegarder. Bonne soirée

Bonjour. Les panneaux de type A (donc à lettre F), lorsqu'ils sont sur nacelle, possèdent un oeilleton. Concernant les panneaux E (ralentissement 30 ou 60 à lettre F), ces signaux possèdent-ils également un oeilleton lorsqu'ils sont sur nacelle? Il serait logique que oui mais je n'ai jamais vu de photos de cette configuration.

En fait, si un créateur veut créer des signaux concernant des époques différentes, la seule chose à laquelle il doit faire attention c'est utiliser les mêmes "nodes" pour les feux (c'est à dire le nom attribué à chaque feu lors de la création du modèle 3D). Dans ces conditions, un signal polymère et un signal métal auront le même script.

On ne peut pas tester la présence d'un oeilleton ou non, cela est conçu dans le modèle 3D. Par contre on peut faire allumer ou non les feux que l'on veut mais ce serait dommage d'avoir un modèle 3D avec un oeilleton et ne pas le faire fonctionner. En fait ma question demandait s'il était désormais utile de créer des modèles 3D avec un oeilleton dans les cas évoqués ci-dessus.

Dans ces conditions la question que l'on peut se poser est la suivante: est-ce que cela vaut le coup de représenter des signaux à lettre F en nacelle comportant un oeilleton? Cela peut faire l'économie d'un script même si la différence entre un script avec oeilleton et l'autre sans est vraiment très très minime ( deux ou 3 lignes).

Geluc Avec Jules31, on parlait des signaux portant la lettre F en nacelle. Ces derniers peuvent porter un oeilleton. On ne parlait pas non plus du rappel de ralentissement mais uniquement du ralentissement 30 ou 60 en nacelle qui porte la lettre F. Ce dernier peut donc comporter dans ces conditions un oeilleton. Bonne soirée

Je ne pense pas que cela existe pour les cibles rondes car à mon sens cela ne concerne que ceux pouvant afficher le sémaphore afin de différencier du carré.

Merci C'est bien ce qu'il me semblait mais n'ayant jamais vu de photo, excepté pour les panneaux A, je voulais en avoir la confirmation. Cela est parfaitement logique.

Bonjour, C'est une excellente question et je me la pose depuis longtemps. Il faudrait d'ailleurs la poser sur un site consacré à MSTS mais avec beaucoup de diplomatie pour ne pas déchaîner les passions . En effet, il y a beaucoup d'inconditionnels de MSTS qui ne veulent pas entendre parler de Rail simulator même si les graphismes de MSTS commencent à être ceux d'un autre age. Je regarde de temps en temps un site belge consacré aux simulateurs de trains. Dans leur forum, il y a une partie consacrée à MSTS et une autre à Rail Simulator/Railworks. Ce qui me frappe c'est la vitalité du forum MSTS alors que celui de Railworks est inexistant. Il faut dire qu'au départ Rail Simulator avait de très nombreux bugs et n'a pas su attirer les gens, ceux-ci reportant leurs attentes sur la sortie de Train Simulator 2. L'arrêt de ce programme, en l'absence de tout logiciel crédible, a peut être provoqué un repli sur MSTS. Mais si je me souviens bien, MSTS a été également long à démarrer en ce qui concerne la francisation du matériel et des lignes. En fait beaucoup de créateurs maitrisent parfaitement MSTS et se sentent comme un poisson dans l'eau avec ce simulateur et n'ayant pas encore tout réalisé, ils ne sentent pas encore le besoin de voir autre chose. Il faudrait pour cela que Railworks sache les attirer. Passer sur Railworks signifie souvent de passer de Gmax à 3DSMax ou 3DCanvas et donc réapprendre un logiciel. De plus la programmation sous Railworks est complexe et très différente de MSTS. Et comme par ailleurs la documentation fournie par Kuju n'est pas des plus claires, ce sont autant de facteurs qui peuvent ne pas inciter les créateurs à franchir le pas. Par chance, un créateur de renom du monde de MSTS est passé sur Railworks en la personne d'Hervé JANIN. Je pense que son exemple en entrainera d'autres et c'est une question de temps. En attendant nous avons la chance d'avoir sur ce site des créateurs de très très grande qualité qui ne peuvent que contribuer à amorcer la pompe. Faudrait-il peut être qu'ils fassent connaître leurs créations sur des sites consacrés à MSTS pour essayer d'attirer vers Railworks.

Bonjour. Le script de la rampe AWS est, me semble t-il, utilisé par le crocodile de Nicolas. La longueur de son script par rapport à celui de la grille TPWS m'a intrigué car normalement le système AWS est plus simple que celui du TPWS qui contrôle en plus la vitesse. Après avoir regardé le script, j'ai plusieurs remarques à faire que je soumets à votre appréciation: 1°) Le script utilise une variable gOccupation. Cela est dû au fait que la rampe AWS est située largement en amont du signal (100 à 200 mètres). Cette variable permet de réinitialiser la rampe si un train la franchit puis fait rebroussement sans avoir passé le lien 0 du signal suivant. Cela n'est pas utile pour nos crocodiles qui sont positionnés à proximité immédiate du signal. 2°) Il y a plusieurs fonctions qui n'ont aucune utilité. Je m'explique. La fonction OnConsistPass ne fait pas appel à la fonction BaseOnConsistPass, pourtant on retrouve cette dernière dans le script. Il en va de même pour la fonction OnSignalMessage vis-à-vis de la fonction BaseOnSignalMessage. En fait ce qui s'est passé c'est qu'en faisant un copier-coller des variables globales issues des Common Scripts, les autres fonctions de ces common scripts ont été également rajoutées. Bien sûr, la présence de ces fonctions inutiles n'empêchent pas le script de fonctionner correctement mais cela l'alourdit inutilement. 3°) Plus de 95% des variables globales définies n'ont aucune utilité dans ce script. Il suffit de regarder le script TPWS pour voir la différence. Mais là aussi cela n'empêche pas le script de fonctionner. C'est un peu le revers de la médaille d'avoir fait un système de fichiers communs. En fait pour avoir un bon script pour le crocodile, il faudrait reprendre le script TPWS en lui retirant le contrôle de la vitesse. Ce qui m'amène à une dernière remarque qui me semble la plus importante. Les scripts AWS et TPWS fonctionnent bien mais en n'utilisant que les états de base des signaux (Blocked, Clear, Warning). Or le script des crocodiles doit reprendre les mêmes états que ceux des signaux. Si l'on se réfère à l'IN 1493, les crocodiles doivent prendre en compte d'autres états comme par exemple les ralentissements 30 et 60. Ce qui veut dire que tous les créateurs de signaux devront adopter la même dénomination des états sinon les crocodiles ne fonctionneront pas correctement ou il faudra un crocodile adapté à chaque créateur ce qui compliquera considérablement la tâche des créateurs de lignes. Il faut donc une uniformisation de la dénomination des états. Pendant la période de fin d'année, j'en avais préparé une mais comme j'ai vu sur le site de Jean-Yves MATHIEU que la sortie de la V2 de ses signaux est imminente, on pourrait adopter la sienne. Ce qui permettrait de créer un script pour le crocodile beaucoup plus complet. Bon dimanche

Bonjour, Avec jules31 nous avons parlé de la préparation des signaux qui nous laissait un peu perplexe. J'ai rapidement regardé aujourd'hui un script anglais et je crois avoir saisi le fonctionnement général. Je pensais que cela ne concernait que la signalisation anglaise. En fait, dans Railworks/Rail Simulator, cela concerne apparemment à la fois la signalisation britannique et allemande. Pour schématiser, par défaut, certains signaux sont systématiquement au rouge même si le canton est libre. Lorsqu'un train approche, un message est retransmis par une rampe AWS et/ou un autre signal de block (et cela plusieurs signaux à l'avance) pour dire qu'un train arrive vers lui et qu'il doit prendre l'état adéquat. Une fois le signal franchi, le signal est réinitialisé au rouge et reste au rouge tant qu'un autre train n'arrive pas. Maintenant pour mieux comprendre l'enchaînement des actions, il vaut mieux prendre le script d'un signal allemand que celui d'un sémaphore à plusieurs têtes anglais surtout que la programmation n'a pas l'air simple.

j'ai regardé les fichiers sources fournis par Kuju autant en entrée qu'en sortie. Je pense que cela se passe comme cela. Lors de la création d'un objet on obtient les fichiers IGS et XML. Ensuite on les place dans le répertoire source de railworks. Si ce répertoire n'existe pas, on le crée manuellement. Le fichier IGS est la forme 3D et le fichier XML n'est autre qu'un fichier texte formaté comportant tous les aspects techniques liés à la forme 3D: le nombre de têtes que possède le signal, les nodes (en fait la position des feux)......... Lorsque l'on lance le fichier blueprint, celui-ci va ouvrir et lire le fichier XML. On va y placer les adresses du fichier IGS, du fichier LUA et s'il y a des modifications à apporter, on peut le faire car l'interface est assez conviviale. Ensuite, lorsque l'on compile, cela abouti me semble t-il à deux fichiers: - le fichier GeoPcDx qui est la transformation du fichier IGS donc du modèle 3D en format lisible par le programme. - le fichier Bin qui est la transformation du fichier XML là aussi en fichier lisible par le programme. Dès que l'on veut faire une modification, il faut impérativement repasser par le blueprint et réexporter ensuite. Cela est-il nécessaire pour les scripts? D'après la documentation de Kuju, il semblerait que oui. Mais comme je le disais plus haut, ce n'est pas clair. Je pense que les créateurs d'objets seront plus compétents que moi pour répondre correctement.

1°) en fait, et c'est un cas spécifique à la signalisation britannique, lorsqu'un train passe sur le croco, il envoie un message pour dire au signal qu'un train arrive vers lui. Après il faudrait regarder dans le script des signaux à quoi sert exactement de préparer un signal à l'arrivée d'un train mais je ne l'ai pas encore fait. Lorsqu'il y a rebroussement le croco envoie un nouveau message qui annule celui qui a été envoyé précédemment pour remettre le signal à son état antérieur; c'est dans ce sens qu'il y a réinitialisation. Je vais me pencher sur les scripts des signaux britanniques pour voir si cela a une utilité pour nous mais il me semble bien que non. En ce qui concerne la bidirectionnalité du croco cela me semble possible car si l'on regarde les scripts, ils n'envisagent seulement que le cas que du train allant vers l'avant. Il n'y a aucune raison de ne pas pouvoir le programmer dans l'autre sens. C'est à essayer. 2°) En ce qui concerne le code inutile, il n'y a aucun souci pour le conserver. Il n'y a aucun effet sur la durée d'exécution du script. A propos de la lecture des scripts, je ne pense pas qu'ils soient compilés puisque l'on peut les ouvrir et les modifier comme l'on veut. Mais ce n'est pas clair dans la documentation officielle. En fait à partir du blueprint je crois que l'on transforme le fichier xml en fichier bin. On indique dans le blueprint l'adresse du fichier lua et on compile mais il me semble que si l'on fait des changements dans le fichier texte lua sans changer son adresse, il n'y a pas besoin de repasser par le blueprint.

Merci pour cette réponse.

Bonjour, Est-ce que quelqu'un utilise Railworks sous seven 64 bits? J'aimerai savoir s'il a pu constater une hausse significative des fps par rapport à un système 32 bits comme cela est le cas pour Flight Simulator X. Merci d'avance.

Bonne année à tous et surtout une bonne santé.