Brimborions      xylakaviens
	fbNauvatag xyljack.net

•      Gullah
  • Lexique gullah-fr
  • Récits « gullah »
• L'Assommoir
  • Chronologie
  • Ch. I^er
  • Ch. II
  • Ch. III
  • Ch. IV
  • Ch. V
  • Ch. VI
  • Ch. VII
  • Ch. VIII
  • Ch. IX
  • Ch. X
  • Ch. XI
  • Ch. XII
  • Ch. XIII
  • Page des cartes
  • Dossier
• MLCJP
• Chanson²
• Stellae
• PH12T
•   23/3
• VB6
  • Sombre
  • Autres
• IEEE-754
• TS-OR  Lignes
  • Accro
  • Dagon
  • ETNA
  • OrlyVal
  • Phosfer
  • Sydney
• TS-OR  Outils  
  • Formats
  • ITR
  • Perflog
• Babël
• Miscella
•       LVdN
  • Présentation
  • Tableaux
  • Épisodes
  • Personnages
  • Anonymes
  • Annexes
•   Petit écran
  • Instagram
  • Ça va se savoir
  • L'Appel gagnant
• BoysLove

♣_______Page mise à jour le 30 janvier 2018 vers 10h30 TUC

Formats des fichiers de MSTS

Quand on parle de format de fichier .s ou .w, on oppose généralement deux états : décompressé (lisible dans le bloc-notes) et compressé (dans lequel un œil humain ne peut rien distinguer d'intelligible, en dehors de l'en-tête).

Maintenant, si l'on observe l'interface de Tk_Zipper, on retrouve ces deux formats, respectivement dans ·Unicode /u et· Compressed /c· mais accompagnés d'un troisième, nommé· Binary /b· · ·aaa

Ces trois formats sont aussi ceux dont Martyn T. Griffin et Paul Gausden comparent les avantages et les inconvénients dans le Hits and Tips de Steam4Me  [⇒], sous les noms respectifs de uncompressed, compressed et tokenised.

Pourtant, le fichier TSUtil_en.txt contenant l'aide pour TSUtil de Carl-Heinz Rive, fait état de quatre formats différents : Unicode text (UT), Compressed binary (CB), Unicode binary (UB) et Compressed text (CT). C'est ce document qui est repris ci-dessous, sous forme de deux tableaux annotés.

Première partie : caractérisation des quatre formats

Nom TS-Util	UT	UB	CT	CB
	Unicode Text Texte Unicode	Unicode Binary Binaire Unicode	Compressed Text Texte compressé	Compressed Binary Binaire compressé
TK Zipper	Unicode /u	Binary /b	·	Compressed /c
autres noms	décompressé | texte uncompressed	compilé tokenized | reduced	·	compressé | binaire compressed
128 premiers octets · ·Ⓐ··	ÿþS·I·M·I·S·A·@· @·@·@·@·@·@·@·@· @·J·I·N·X·0·s·1· t·_·_·_·_·_·_··· ······s·h·a·p·e· ··(· ·······s·h· a·p·e·_·h·e·a·d· e·r· ·(· ·0·0·0· 0·0·0·0·0· ·)· ·	SIMISA@@@@@@@@@@ JINX0s1b______·· G····Š···F······ ······D···¯····· ···E············ ·····îÎ’>ÿ•©?··‘ ¾eÇ:@E·········· ·······îÎ’>ÿ•©?· ·‘¾‚â1E········	ÿþS·I·M·I·S·A·@· F·Ä·ê·····@·@·@· @·xœí]Koå¸ræv·Üÿ ` ›ô·‘zoƒl·ä±É" »··í±=pÛF·Ï`ú߇b ±·)ŠzØÇŸoW"··ñ%• JÔG²X,–þMý«úOõ?ª PG¥Õ«:D¿¿©·pÿ£ºW WêEݪ·õO·ç—(ï`c·	SIMISA@F·Š··@@@@ xœí]·pVÕ·>Y·IØB ·)[·@BX·°,·Éÿ··A ÙÜjª EÅŠ¨·ÔºÔ…‚@ ¡Ö·ÅVŠµVe··¥ÕJ1i §‹ètqÔ:L§·*Lí··· ´µ·Ñ¡éùÞ·ßÿ¿÷Îû/ ÷·qb½Ï9žÿœ÷½û¾{ß =÷Ý{߉ž5g~Kíõu—]
en-tête	Unicode long	Ansi long	Unicode court	Ansi court
Filiation ·Ⓑ··
Avantages	· ·Peut être lu ou modifié · · ·par vous et moi	Exploitable par Train.exe	?	· Occupe moins de place · · ·sur le disque · Chargement un peu · · ·plus rapide
Taille sur le disque ·Ⓒ··

Ⓑ··En remplaçant les quatre colonnes en ligne par deux colonnes sur deux lignes, on peut aussi représenter cette filiation de cette façon· · ·aaa Malheureusement, comme on le verra dans la note Ⓕ·, le chemin imposé par MSTS n'est pas toujours aussi simple que sur ce schéma. q··Il n'est pas sûr que compilation· soit le terme le plus couramment employé ; comme mentionné plus haut, en anglais, Carl-Heinz Rive utilise l'expression Unicode Binary (qui se justifie mais n'est pas très intuitive) et d'autres, Tokenized file (difficile à traduire) ; or, dans leur texte sur Steam4Me·, Griffins et Gausden écrivent à ce propos :

L'annexe 1 contient une comparaison illustrée et commentée des deux versions UT et UB d'un (court) fichier de parcelle (fichier .w placé dans le répertoire \World d'une ligne).

Deuxième partie : d'un type à l'autre

Pour son fonctionnement (dans le jeu ou dans les éditeurs), MSTS utilise un grand nombre de fichiers (l'installation de base en compte plus de dix-huit mille), que l'on peut répartir en divers types d'après leur extension (une bonne soixantaine, au total) : .s (fichiers de forme), .w (parcelles), .t (tuiles), .act (activités), .pat (chemins), .eng (motrices), .con (rames), .env (environnement), .sms (gestion des sons), .dat (gestion des objets interactifs), .ace (textures), etc.

Or toute la première partie ci-dessus ne vaut que pour les trois types .s, .w et .t . Si l'on excepte les fichiers de texture .ace (qui contiennent des images, un peu comme les fichiers .bmp ou .tga), la grande majorité des autres est constituée de textes en Unicode 16, autrement dit au format UT ; mais FFEditc_Unicode.exe (l'utilitaire de MSTS permettant de passer d'un format à l'autre) limite son action aux fichiers .s, .w et .t, tout comme ses équivalents TK_Zipper ou la fonction fmgr de TSUtil ; si on leur soumet un fichier .sd, par exemple, aucun fichier compilé ou compressé n'est produit.

Le programme SDenUB.exe (écrit en VB6) essaie donc de reproduire le fonctionnement de FFEditc_Unicode.exe dans un cas très spécifique: la compilation UT → UB d'un fichier .sd (et encore faut-il préciser que les ESD_Complex_Box· ne sont pas supportés) ; l'utilité pratique est donc quasiment nulle, mais l'expérience ne manque pas d'intérêt, et le résultat est positif puisque MSTS accepte la version UB du fichier aussi bien dans le jeu que dans l'Éditeur d'activité (mais elle entraîne un plantage complet d'OpenRails).

Exemple de conversion :

Quelques remarques :

1. ·Le dernier mot-clé (ESD_No_Visual_Obstruction·) se suffit à lui-même et, dans le fichier UT, n'a pas de paramètre ; dans la version UB, le mystérieux octet 0 fait qu'un paramètre nul a quand même une longueur de 1.
2. ·Plus délicat : au début du fichier, la construction de Shape ( rappelle celles de Tr_WordFile ( ou Static ( dans le fichier .w (cf·. l'annexe 1) ; mais dans ces deux cas, le paramètre était une liste de mots-clés avec leur propre paramètre (commençant respectivement par par VDbIdCount ( et UiD () ; ici, la première partie du paramètre de Shape ( est une simple chaîne de caractères (le nom du fichier .s) ; on se trouve donc devant un dilemme pour choisir la longueur à placer dans les quatre octets qui suivent 47·00·00·00 (le token correspondant à Shape) : faut-il y mettre la longueur totale du paramètre jusqu'à la parenthèse fermante finale (mais alors la longueur de la chaîne sera perdue) ou celle de la chaîne (mais on ne saura plus où se termine le paramètre complet) ; la comparaison avec des situations approchantes dans les fichiers .s montre que c'est la première solution qui est retenue ; mais cela suppose que MSTS sache qu'il doit interpréter les quatre octets suivant la longueur et l'octet 0 (ici 0A·00·63·00) non pas comme un token mais comme la longueur d'une chaîne de caractères sur deux octets suivis du premier caractère de la chaîne.· ·Retour à la surprise
3. ·Les six groupes de quatre octets formant le paramètre de ESD_Bounding_Box· sont de type float·, « à virgule flottante » ; SdEnUB reprend les fonctions créées pour le programme ProBin·  [⇒] ; elles occupent plus d'un tiers de SdEnUB.

Comme il a déjà été indiqué, ni ffeditc_unicode ni TK_Zipper ni TSUtil (et, par conséquent, RouteRiter) ne prennent en charge les fichiers autres que .s, .w et .t ; il existe pourtant un utilitaire capable de convertir les quatre formats pour tous les types de fichiers Unicode 16 : Simis-Editor, de James Ross.·Ce programme fait donc (en mieux et en beaucoup plus grand) ce que fait SdEnUB. On peut le télécharger à cette adresse [⇒] ou trouver le site ici [⇒].

L'un des éléments les plus intéressants de cet utilitaire se trouve dans son répertoire Resources, qui contient les fichiers .bnf (donc la syntaxe des mots-clés) de tous les types de fichiers supportant ce genre de conversions. L'annexe 3 donne quelques exemples empruntés aux fichiers de parcelle.

Annexe 1 : UB vs UT

1. · Ici, les octets du fichier UB sont affichés sous la forme de leur valeur en hexadécimal.
2. · Légende :

   	Token (sur 4 octets)	Mot-clé (de longueur variable)
   	Longueur du bloc (sur 4 octets)	Bloc (de la parenthèse ouvrante à la parenthèse fermante)
   	Paramètres (juxtaposés)	Paramètres (séparés par une espace ou un saut-de-ligne)

3. · Comme on peut le voir, seuls les mots-clés et les tokens se correpondent de façon univoque.

   Pour la division en sections (d'un mot-clé au suivant), le fichier UT emploie des séparateurs (parenthèses, espaces, tabulations, sauts-de-ligne -- ces trois derniers étant quasiment interchangeables et pouvant être redondants) ; le fichier UB, lui, enregistre seulement la taille (en octets) de chaque section.

   Le même principe s'applique aux paramètres.

4. · Pour qui voudrait plus de précisions sur la notation hexadécimale, les données de base se trouvent sur ce site  [⇒] et plus de détails sur Wikipedia  [⇒];
5. · À qui en connaît le principe, rappelons qu'Intel range les octets des valeurs numériques dans l'ordre inverse de la « normale »· (appelée big endian·) ; par exemple, le nombre 12 34 apparaîtra sous la forme 34 12 (d'où le format Unicode 16 low endian· où l'octet de poids fort qui code le type d'alphabet vient après l'octet de poids faible qui code le caractère). Mais les choses se compliquent lorsqu'on a à faire à des données de types différents.·Supposons deux nombres 12 34 et 56 78 (qui apparaissent normalement· comme 12·34 56·78), on les trouvera en low endian· sous la forme 34·12·78·56 mais si le même 12·34·56·78 doit représenter un nombre sur quatre octets, on le trouvera sous la forme 78·56·34·12 .
6. · Première surprise : dans le fichier UB, on peut voir que chaque groupe de quatre octets indiquant la taille du bloc est suivi d'un octet 00 non encadré ; cet octet fait bien partie du bloc lui-même puisqu'il est inclus dans la taille (ainsi trouve-t-on fréquemment la suite 05·00·00·00·00 -- les quatre premiers octets indiquant un bloc de cinq octets, à savoir ce 00 suivi des quatre octets du paramètre, lorsqu'il s'agit d'un entier ou d'un nombre à virgule flottante). Je n'ai pas pu déterminer à quoi il correspondait ou servait.
7. · Deuxième surprise à retardement : quand le paramètre est une chaîne (par exemple, SERNA1.s, qui est le nom du fichier de l'objet), celle-ci est enregistrée au format Unicode ; ainsi peut on lire 53 00·(qui code le S) puis 45 00 (E) jusqu'à 2E 00 (pour le point) et 73 00 (pour le s), le tout occupant 16 octets ; or on peut voir que ces seize octets sont précédés de 08 00, qui est inclus dans la taille du bloc (13 00 00 00 -- soit 19 en décimal = le 00 + ces 08·00 + les seize octets de SERNA1.s en Unicode) ; en fait, ces deux octets 08·00 contiennent la longueur de la chaîne au format Ansi ; mais quelle est l'utilité de cette indication puisqu'on peut la retrouver immédiatement à partir de la longueur du bloc ?
   
   NB- Peut-être un début de réponse ici.
8. · Ce n'est pas une surprise mais quand même une particularité : si l'on considère la partie centrale du fichier, on peut trouver dans le format UT cinq fois le chiffre 1 (encadré en jaune ci-dessous pour plus de commodité) :
   

   ---

   
   et constater que ce chiffre a des équivalents variés dans le format UB :
   •· le premier est représenté par 01·00·00·00 -- soit effectivement la valeur 1 sur quatre octets au format Intel ;
   •· celui de SERNA1.s est représenté par les octets 31·00 qui codent le chiffre 1 en tant que chaîne Unicode en low endian· ;
   •· mais les trois suivants n'apparaissent nulle part dans leur équivalent UB : au premier et au dernier (où l'on a à faire au nombre entier) correspond 00·00·80·3F et à la valeur décimale -497,401 correspond 54·B3·F8·C3 ; où peut bien se cacher le 1 dans ces groupes de quatre octets ? il s'agit en fait des nombres à virgule flottante, encodés selon la norme IEEE 754 ; une page voisine  [⇒] est consacrée à ce type particulier d'encodage.
9. on a vu plus haut que le format UB n'utilisait pas de séparateurs mais se guidait sur la longueur déclarée des blocs ; nous en avons ici deux exemples éclairants :
   •·au mot-clé Static correspond le token 03·00·04·00, suivi de la longueur du bloc qui lui est associé : 71·00·00·00 (soit 113 octets) ; dans le fichier UT, le mot Static est suivi par une espace, une parenthèse ouvrante, un saut-de-ligne et une tabulation avant le mot-clé suivant UiD ; dans le format UB, les quatre octets indiquant la longueur du bloc Static sont suivis immédiatement par [00] 6C 00 04·00 -- le token correspondant à UiD, dont la longueur indiquée est de 5 octets ; on voit comment cette imbrication des longueurs permet de recréer une hiérarchie correspondant à l'imbrication des parenthèses sans séquenceur explicite ;
   •·dans le format UB, le fichier se termine par les quatre octets 01 00 00 00 correspondant au paramètre 1 de StaticDetailLevel ; dans le format UT, ce 1 est suivi d'une espace, d'une parenthèse fermante, d'un saut-de-ligne, d'une tabulation, d'une seconde parenthèse fermante, d'un autre saut de ligne et d'une troisième parenthèse fermante ; ces éléments sont absents du format UB puisque la longueur BF·00·00·00 indiquée à la troisième ligne du fichier (soit 191 octets) suffit pour déterminer que le bloc qui commence ici au quarante-et-unième octet s'arrêtera au deux cent trente-deuxième -- le dernier du fichier.______Revenir·à·l·̓·analyse·des·formats.

Annexe 2 : Jusqu'au-boutisme…

Quand, dans la fenêtre [Enregistrer sous…] du bloc-notes (Notepad.exe·), on déroule la liste [Encodage], on obtient les options suivantes : · · ·aaa On retrouve sous l'appellation UTF-16 le format que nous avons déjà nommé de façon récurrente UT (dans lequel chaque caractère du texte est codé sur deux octets) ; mais on peut voir que la liste distingue deux variantes dans ce format : LE et BE, pour Little Endian· et Big Endian, plus ou moins officiellement traduit en français par Petit boutisme· et Gros boutisme·.

Dans la variante BE, le premier octet écrit ou lu (c.-à-d. celui qui a l'adresse la plus basse en mémoire ou sur le disque) est le code de l'alphabet ; vient ensuite celui du caractère.·Et inversement dans la variante LE.

Mais pourquoi accorder tant d'importance à ce qui peut apparaître comme très anecdotique ? C'est que

1. · loin de se limiter aux couples codant chaque caractère dans un fichier de texte UTF-16, cette inversion de l'ordre des octets se retrouve dans le traitement de toutes les données, y compris numériques (comme on peut le voir dans le fichier UB de l'annexe 1), et qu'elle y complique singulièrement les choses.·Prenons un exemple : soit, comme paramètre d'un token, une suite de huit octets 01 à 08 ; elle peut correspondre à

   ---

   ·	Big Endian	Little Endian
   quatre couples codant un caractère Unicode	01··02··03··04··05··06··07··08	02··01··04··03··06··05··08··07
   deux valeurs numériques sur quatre octets · ·(comme les nombres à virgule flottante courants)	01··02··03··04··05··06··07··08	04··03··02··01··08··07··06··05
   une valeur numérique sur huit octets · ·(par ex. un nombre à virgule flottante en haute précision)	01··02··03··04··05··06··07··08	08··07··06··05··04··03··02··01

   ---

   Pour un qu'un œil humain puisse interpréter cette suite au format Big Endian· (ou qu'un esprit humain puisse la traiter), il suffit de savoir où placer les limites des différentes valeurs ; il en va autrement du format Little Endian, qui nécessite tout un travail préalable de reconstruction.

   ---

2. · il se trouve que MSTS fonctionne sous Windows, Windows s'appuie sur MS-Dos, MS-Dos utilise des processeurs Intel et Intel a choisi le Little Endian·.

Pour plus de détails (et de pondération) sur le boutisme·, on peut se référer à cette page de Wikipédia  [⇒].

Annexe 3 : FFEditc_Unicode

Lors de son installation, MSTS crée (entre autres choses) un répertoire \UTILS et un sous-répertoire \UTILS\FFEDIT dans lequel est placé le programme ffeditc_unicode.exe accompagné de divers fichiers complémentaires ; c'est ce programme qui permet de changer le format d'un fichier du jeu comme on a pu l'observer dans la première partie.

Aujourd'hui, il n'est plus guère employé puisque TSUtils et TK_Zipper en offrent des équivalents plus faciles à manier, mais l'étude des fossiles reste une activité pleine d'intérêt.

Première précision : le programme s'exécute dans une fenêtre de la console MS-Dos ; par ailleurs, la seule aide dont on dispose est ce qui s'affiche quand on entre la commande ffeditc_unicode.exe /?, que l'on peut traduire ainsi :

Ci-dessus, la ligne Utilisation indique la syntaxe de la commande ; les paramètres obligatoires figurent entre < >, les paramètres facultatifs entre [ ] et | sépare plusieurs éléments entre lesquels il faut choisir. Ainsi, le seul paramètre obligatoire est le nom du fichier à convertir ; encore faut-il que ffeditc_unicode.exe et le nom du fichier soient précédés de leurs chemins respectifs s'ils ne se trouvent pas dans le répertoire courant de MS-Dos (celui qui est indiqué en début de ligne, avant le < et le curseur clignotant). Les paramètres /k et /o: sont assez clairs ; reste [/c|/u] ; les crochets indiquent un élément facultatif ; on aura donc trois formes (et trois effets) possibles : ffeditc_unicode.exe <fichier> ffeditc_unicode.exe <fichier> /u ffeditc_unicode.exe <fichier> /c Comme on peut le deviner, c'est ce paramètre qui permet de fixer le format de sortie de la conversion (pour plus de clarté, nous l'appellerons commutateur) ; et, puisque nous avons quatre formats possibles en entrée (UT, UB, CT et CB), il y aura douze cas de figure à considérer, rassemblés dans ce tableau· · ·aaa S'il a l'avantage d'être complet, ce tableau est difficile à appréhender dans sa globalité ; d'où le second schéma moins détaillé mais peut-être plus « parlant » · ·d d · ·d d

·

·

La logique qui régit l'emploi de ce commutateur peut surprendre à plus d'un titre : ·Il y a deux façons de décompiler un fichier UB en UT : soit sans commutateur, soit avec /u ; idem pour décompresser un fichier CB en UT ; mais aucune commande directe pour compresser un fichier UT en CT (ce qui n'est pas trop gênant, vu l'inutilité de ce dernier) ni pour compresser un fichier UB en CB (plus perturbant, vu que CB est le format dans lequel se trouvent les fichiers lors de l'installation et UB, le seul que Train.exe puisse exploiter directement). Pour cette opération, il faut employer deux fois de suite la commande sans commutateur : la première fois, le fichier UB sera décompilé en UT, la deuxième, il sera recompilé en UB puis compressé en CB. Pourquoi irait-on faire simple… ? Ultime surprise : pour passer de CB (fichier compilé puis compressé) à CT (fichier non compilé mais compressé), il faut utiliser le commutateur /c -- ; pour prendre un exemple, la « compression » d'un fichier de 3 395 octets fournira un fichier de 6 522 octets. Comprenne qui pourra.

Quand on décompresse un fichier .w de CB en UT ou de CB en UB, le fichier obtenu peut contenir une erreur qui rend son utilisation problématique.

Le problème se situe dans ces ViewDbSpheres (ce qui vaccine les parcelles dépourvues de telles zones). Un exemple simple figure dans le schéma ci-contre · ·aaa le carré représente la parcelle, avec une VDbS n°·0 comprenant elle-même deux VDbS plus petites, numérotées 1 et 2. · · · On dispose donc d'une sorte de structure gigogne où deux ViewDbSpheres peuvent être soit sœurs·(comme 1 et 2) soit dans un rapport mère-fille· (comme 0 et 1).·Dans le fichier de format UT, cette structure est matérialisée par l'indentation et les parenthèses. · ·aaa Mais (comme cela apparaît dans la première annexe) le format UB ne dispose pas de cette ressource et tout se passe dans la longueur assignée à chaque bloc. Dans notre exemple, la longueur déclarée pour la VDbS(0) englobera toute la suite de la section encadrée en violet alors que celle des VDbS(1) et VDbS(2) correspondra aux trois lignes de chacune. L'erreur de ffeditc_unicode est qu'il considère systématiquement que chaque nouvelle VDbS est la fille de la précédente, aboutissant à cet état · ·aaa La dernière copie d'écran montre un dernier exemple encore plus caricatural. Au-delà du simple aspect, deux conséquences néfastes dans le jeu ou l'Éditeur d'itinéraires : ·certains objets ne peuvent pas être affichés ; par endroits, des « textures folles » envahissent l'écran. Avant l'arrivée de TK_Zipper, TSUtils ou Simis-Editor, la seule solution sûre consistait à ouvrir la ligne dans l'Éditeur d'itinéraires, aller sur la parcelle à décompresser, déplacer légèrement un objet puis enregistrer la ligne : l'Éditeur d'itinéraires enregistre toujours au format UT -- et sans erreur. Mais le procédé devenait vite fastidieux quand on avait besoin de décompresser, par exemple, les deux mille huit cent deux parcelles de la Ligne du Grand Est. Plus inquiétant que cette erreur elle-même, ce qu'elle révèle : Trains.exe (qui gère le jeu et les éditeurs à l'exception de l'extracteur de géométrique) convertit correctement les quatre formats de tous les fichiers qu'il a à utiliser ; pourquoi avoir choisi de réinventer la roue en créant un nouveau programme pour faire la même chose en plus rabougri (fichiers .s, .w et .t seulement) et avec une erreur gênante ? Compétition entre deux équipes de Kuju ? amnésie des créateurs ?

···

Mais à quelque chose malheur peut être bon : l'autonomie de ffeditc_unicode a nécessité la création de tables et de listes ; les deux plus utiles sont newshape.bnf et worldfile.bnf qui contiennent la syntaxe des mots-clés utilisés dans les fichiers .s et .w, et livrent donc deux sortes d'informations particulièrement intéressantes :

1. ·le type de chaque paramètre ; on trouve essentiellement
   

   uint	entier non signé (quatre octets)	sint	entier signé (quatre octets)
   float	nombre à virgule flottante (quatre octets)	string	chaîne (longueur variable dans les deux premiers octets)

   on a vu plus haut que dans Mot_clé ( 1 ) le chiffre 1 pouvait correspondre aussi bien à un entier qu'à un nombre à virgule flottante ; s'il est compilé comme nombre à virgule flottante, il apparaîtra sous la forme 00 00 FF 38 (au format Intel) ; mais si, lors de la décompilation, 00 00 FF 38 est considéré comme un entier, on obtiendra Mot_clé ( 1065353216 ), ce qui risque de poser quelque problème.
2. ·le cercle des mots-clés disparus : parmi les mots-clés listés, quelques-uns m'étaient inconnus ; ils se répartissent en deux catégories :
   Ⓐ·· quatre paramètres de Static ( ; aux côtés de FileName ou VDbId, on trouve Quality ( {float} ), MaxVisDistance ( {float} ), Direction ( {float} {float} {float} ) et NoDirLight ( [{uint}] ), jamais rencontrés dans un fichier .w ; et pourtant… ils figurent bien dans quelques fichiers de parcelles des lignes originales de Kuju :
   •·Quality ne se rencontre que dans le fichier w-012520+014779.w de la ligne USA2 (La Passe de Marias·) pour sept objets Telepole (fonction prévue pour permettre de placer une rangée complète de poteaux télégraphiques) ; le mot-clé figure aussi dans les paramètres de quelques autres objets (par exemple Static, Gantry ou TrackObj mais pas dans CollideObject ni DynTrack) ; bizarreries supplémentaires : ces Telepoles utilisent également les mots-clés MaxVisDistance et Direction ; enfin, quoiqu'ils n'aient pas de StaticDetailLevel (ni dans le fichier .bnf ni dans le fichier .w), l'Éditeur d'Itinéraire leur attribue un SDL de -1 ;
   •·MaxVisDistance apparaît dans deux fichiers de JAPAN1 (Tokyo-Hakone·) et dix de USA2 (La Passe de Marias·) ; dans worldfile.bnf, il est prévu pour tous les types d'objets à l'exception de DynTrack, Hazard et SpeedPost, et offre un exemple caractéristique des risques de confusion mentionnés en 1·: worldfile.bnf (de Kuju) lui donne pour paramètre un nombre à virgule flottante alors que le fichier world.bnf de Simis Editor classe ce paramètre parmi les entiers non signés ; conséquence logique pour le premier Telepole de w-012520+014779.w : Simis Editor décompile le paramètre en 29486 (soit 00 00 73 2E en hexadécimal Big Endian) alors que RouteRiter (utilisant le fichier .bnf de Kuju) le décompile en 4.132E-41 (notation scientifique· pour la valeur décimale 0,00000000000000000000000000000000000000004132 -- soit, s'il s'agit de mètres, une fraction de milliardième de milliardième de milliardième de milliardième de millimètre ; belle précision) ; ffeditc_unicode, lui, arrive à 4.13187e-041 ; mais si, dans worldfile.bnf, on remplace
   ___________MaxVisDistance ==> :float,MaxViewDist . · ·par
   ___________MaxVisDistance ==> :uint,MaxViewDist . .
   alors ffeditc_unicode décompresse bien en MaxVisDist ( 29486 ), tout comme Simis Editor.

   Reste à déterminer ce que représente ce mot-clé ; la logique voudrait qu'il permette d'indiquer la distance à laquelle l'objet reste visible ; mais les essais dans l'Éditeur d'Itinéraires n'ont pas été concluants ; de plus, cette fonction fait (ou ferait) double emploi avec les lods (level of detail·) qui, dans le fichier .s de l'objet, déterminent son apparence en fonction de l'éloignement ; avantage ou inconvénient, les lods· s'appliquent automatiquement à toutes les instances de l'objet alors que MaxVisDist· ne porte que sur l'objet précis dans lequel la commande est placée.

   •·Direction : le mot-clé ne doit pas être confondu avec l'omniprésent QDirection qui, comme l'indique son initiale, correspond à un quaternion et a donc en paramètres quatre valeurs de type {float} ; Direction, lui, a comme paramètre trois nombre {float} qui sont sans doute les angles de lacet, roulis et tangage exprimés en radian, comme on les trouve dans les fichiers .tdb et .rdb. Sans pouvoir vérifier toutes les occurrences (qui apparaissent dans une cinquantaine de fichiers des six lignes originales de MSTS), il semble bien que Direction remplace QDirection dans tous les objets Telepole et eux seuls.
   •·NoDirLight : c'est le plus répandu puisqu'il est utilisé dans près d'une parcelle sur deux des six lignes d'origine (trois cent cinquante-sept sur sept cent vingt-sept), sa fonction apparaît clairement dans la mesure où il est réservé à des arbres.
   

   Pour donner rapidement une idée du problème que peuvent représenter les arbres dans la simulation, il suffit de comparer ces deux objets · · aaa Au format UB, l'arbuste occupe 274 kO en mémoire quand le bâtiment n'en consomme que 31 (quasiment un rapport de 9 à 1) ; il était donc impérieux de réduire le poids des fichiers des objets constituant la végétation, d'autant plus que les lignes d'origine sont des lignes rurales (à l'exception de USA1 et, pour moitié, de JAPAN1) ; pour y parvenir, on a créé les arbres au moyen de deux (ou trois voire quatre) plans verticaux se coupant en leur milieu, comme on peut le voir dans l'image ci-dessous.

   Bien sûr, la vue en plongée n'est pas du meilleur effet mais, de face et à distance raisonnable, le résultat est correct, surtout pour un poids d'à peine 3 kO. bbb · · Placer le curseur de la souris sur l'image pour afficher ce résultat. Mais il arrive que le mieux soit l'ennemi du bien ; pour améliorer le réalisme du décor, MSTS a prévu de varier l'éclairage des surfaces en fonction à la fois de l'heure et de leur orientation, comme on peut l'observer dans la copie d'écran ci-dessous, prise vers 18 heures :

   Hélas ! ce qui convient aux bâtiments produit un effet nettement moins heureux sur les arbres cruciformes · · aaa · · ; mieux vaut alors un éclairage identique dans toutes les directions. Placer le curseur de la souris sur l'image pour voir cet aspect · ·aaa C'est ce changement d'éclairage que devait permettre NoDirLight ; mais il s'est retrouvé dans la même situation que MaxVisDistance : plutôt que d'avoir à préciser pour chacun des milliers d'arbres un type particulier d'éclairage, mieux valait fixer ce type à la source dans le fichier .s de l'arbre ; c'est ce que fait l'un des paramètres du mot-clé vtx_state : pour -5, l'éclairage dépend de l'heure et de l'orientation (cas général) ; pour -9, il ne dépend que de l'heure (arbres cruciformes) ; avec -8, la surface est éclairée au maximum quelles que soient l'heure et l'orientation (pour l'éclairage nocturne, notamment) ; on trouve aussi quelques autres valeurs intermédiaires.

   ·

   ---

   Remarque : Ces quatre mots-clés sont décelables une fois les fichiers CB d'origine décompressés avec ffeditc-unicode ou l'un de ses équivalents ; mais si on charge la ligne dans l'Éditeur d'Itinéraires et qu'après avoir modifié la parcelle dans laquelle ils se trouvent, on enregistre le fichier, l'Éditeur d'Itinéraires supprime au passage les lignes Quality ( ), MaxVisDistance ( ) et NoDirLight () ; par contre, il conserve telle quelle la ligne Direction ( ), sans la transformer en QDirection.

   ---

   Ⓑ·La seconde série de mots-clés inattendus se compose de Wagon, Engine et Train ; elle se distingue de la précédente par trois caractéristiques (au moins) :
   q··Ces mots-clés ne sont pas vraiment des inconnus puisqu'on les trouve de façon récurrente dans les fichiers .wag (wagons), .eng (motrices) ou .con (rames), mais pas ailleurs ;
   w··sauf erreur, il n'y en a aucune occurrence dans aucun des fichiers .w d'origine ;
   e··ils ne sont pas prévus pour servir de paramètres à un objet mais sont eux-mêmes des noms d'objet, comme Static, CarSpawner ou TrackObj.

   D'après worldfile.bnf, on pourrait rencontrer quelque chose comme

   Wagon (

   UId ( 12 )

   WagonData ( Labor ) (1)

   CoupledWith ( 0 )

   CollideFlags ( 0 )

   FileName ( Labor.s )

   StaticFlags ( 00008000 ) (2)

   Position ( 75.427 1 -312.452 )

   QDirection ( 0 0 0 1 )

   MaxVisDistance ( 100 )

   VDbId ( 0 )

   NotCoupledToActiveTrain ( 0 )

   )

   ---

   Engine (

   UId ( 13 )

   Camera ()

   WagonData ( Labor ) (1) (3)

   EngineData ( Labor ) (1) (3)

   CoupledWith ( 0 )

   Flip () (3)

   Inverse () (3)

   FileName ( Labor.s )

   Position ( 175.427 1 -312.452 )

   Direction ( 0 0 0 )

   EngineVariables ( 0 -1.56 8 0 0 -4 )

   MaxVisDistance ( 100 )

   NotCoupledToActiveTrain ( -1 )

   )

   ---

   Train (

   UId ( 14 )

   FirstWagon ( 3 )

   TrainData ( Labor )

   )

   ---

   (1)· Worldfile.bnf indique seulement que le paramètre est une chaîne de caractère ; difficile de savoir à quoi elle correspond précisément.
   (2)· Le paramètre est défini comme un {dword} (= double world·), c'est-à-dire un nombre de quatre octets comme {uint} ou {float} mais où chacun des trente-deux bits a une signification propre, indépendante des autres ; c'est ainsi que MSTS repère, par exemple, un objet Static animé· ou objet de terrain ou encore les objets interactifs, etc. Il est donc impossible de prédire la valeur attendue ; voir cependant la copie d'écran ci-dessous.
   (3)· Contrairement à d'autres règles de syntaxe, worldfile.bnf liste pour chaque objet tous les mots-clés pouvant servir de paramètres sans préciser s'ils sont obligatoires ou facultatifs ni si certains en excluent d'autres (comme c'est très vraisemblablement le cas de Direction, QDirection et Matrix3x3.

   Si l'on place dans un fichier de parcelle les trois objets Wagon, Engine et Train tels qu'ils sont présentés ci-dessus,

   q··on peut ouvrir la ligne et charger la parcelle sans problème dans l'Éditeur d'Itinéraires mais les objets eux-mêmes sont absents (invisibles et impossibles à sélectionner) ;
   w··si l'on ajoute, supprime ou déplace un objet quelconque de la parcelle, l'enregistrement échoue et l'Éditeur se ferme ;

   e··par contre, si le fichier .w ne contient que l'objet Wagon (sans Engine ni Train), l'Éditeur conserve Wagon lors de l'enregistrement de la parcelle modifiée, en « corrigeant » certaines lignes · · aaa e··Enfin, ni le jeu ni Simis Editor n'acceptent ces objets (pas même la version corrigée de Wagon) mais OpenRails, lui, s'accommode des trois, à la façon de l'Éditeur d'Itinéraires.

   ···