Du format des fichiers .s, .w et .t

Les documents, recettes et petits trucs qui sont utiles à tout fan de MSTS!

Modérateur : Modérateurs

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 26 août 2012 4:39

___Ia ora na.

___Quand on parle de format de fichier .s ou .w (et il en va de même pour les fichiers .t), 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).
___Si l'on observe l'interface de Tk_Zipper, on retrouve ces deux formats, Compressed / c et Unicode / u mais également un troisième, nommé Binary / b :
Image
___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 n° 23 de Steam4Me, sous les noms respectifs de compressed, uncompressed et tokenized.

___Pourtant, le fichier TSUtil_en.txt contenant l'aide de TSUtil, créé par Carl-Heinz Rive , fait état de quatre formats différents. C'est ce document qui est repris ici, sous forme de deux tableaux annotés.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Première partie : caractérisation des quatre formats
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Image
Notes :
~~~~~~
(1) La représentation de ces débuts de fichiers est en partie conventionnelle :
a} sur le disque ou en mémoire, les octets se suivent linéairement ; c'est par commodité de mise de page qu'ils sont ici groupés par lignes de 16 ;
b} chaque octet représente un nombre, de 0 à 255 ; c'est également par commodité que ce nombre est ici représenté par le caractère ASCII lui correspondant ;
c} de plus, les valeurs de 0 à 31 équivalent à des caractères non imprimables ; ces derniers sont ici remplacés par un point au milieu de la ligne ; c'est notamment le cas de l'octet 0 qui forme couple en Unicode pour représenter un caractère dans l'alphabet latin.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(2) On pourrait aussi représenter cette filiation de la façon suivante, en ne tenant plus compte des quatre colonnes :
Image
___Comme on le verra dans la note (6), le chemin imposé à l'utilisateur n'est malheureusement pas toujours aussi simple que ce schéma le laisserait augurer.

{2a} la compression utilisée par MSTS est de même nature que celle qu'effectuent des utilitaires comme WinZip ou WinRar, mais elle recourt à un algorithme différent (ZLib), et chaque type de fichier présente un en-tête particulier, hors compression ; l'intérêt de cette opération est purement économique (moins de place sur le disque, chargement plus rapide en mémoire) puisqu'aucun programme ne peut travailler sur un fichier compressé ;

{2b} la compilation :
xxx>>> voir le détail dans la deuxième partie
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(3) il faut interpréter ce pour comme signifiant utilisable en l'état par... ou directement exploitable par... ; bien sûr, si on ouvre une ligne dans l'Editeur d'itinéraires, MSTS charge et affiche les objets .s quel qu'en soit le format ; mais ce qui est pris en compte ici est le format dans lequel les fichiers sont (ou doivent être) finalement transformés pour pouvoir servir effectivement.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(4)
a} il ne s'agit que d'un exemple, pas du résultat d'une étude scientifique ;
b} les deux zones en rouge figurent la taille relative des mêmes fichiers compressés avec WinRar.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Deuxième partie : le format UB compilé
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
NB- il n'est pas sûr que ce terme soit le plus courant ; comme mentionné précédemment, en anglais, on parle de tokenized file - mais token est difficile à traduire ; or, dans leur texte de Steam4Me, Griffins et Gausden écrivent à propos de ce format :

Akin to the object code created when a source program is compiled
Cette comparaison avec la création des exécutables dans certains langages a paru permettre cet emploi.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

Nous partirons d'un exemple : la section d'un fichier .w plaçant un objet de type Static ;
<!> contrairement aux débuts de fichiers dans le tableau <2>, les octets seront représentés ici par leur valeur en notation hexadécimale ;
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
a} celles et ceux qui voudraient plus de précisions sur cette notation trouveront les données de base
sur ce site et plus de détails sur Wikipedia;
b} à qui en connaît le principe, rappelons qu'Intel range les octets des valeurs numériques dans l'ordre inverse ; ainsi, le nombre 1234ABCD apparaîtra sous la forme CD AB 34 12.
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

Image

Dans son format UT comme dans son format UB, le fichier est en fait composé de quatre sortes d'éléments :

A} les mots-clés, remplacés par une valeur numérique (le token anglais, valeur-clé ci-dessous) ; on trouve dans le tableau précédent diverses nuances de bleu ou de violet pour les distinguer ;

B} les valeurs numériques (en rouge, orange ou jaune), codées (sauf exception) sur quatre octets, de 00 00 00 00 à FF FF FF FF, et présentant trois types d'utilisation :
>> entier naturel (de 0 à 4 294 967 295, en décimal)
>> entier signé (de -2 147 483 648 à 2 147 483 647)
>> nombre à virgule flottante ; pour simplifier, disons que trois octets (moins un bit) servent à stocker les chiffres et l'autre octet (plus un bit), le signe (+ ou -) et la place de la virgule ; ce système permet de placer dans un nombre fixe d'octets (ici, quatre) des valeurs décimales ou très grandes ou très petites, avec une précision plus ou moins satisfaisante ;

C} les chaînes de caractère, stockées en Unicode (sans guillemets, on verra plus bas pourquoi) ;

NB- dans l'exemple précédent, on trouve trois fois la valeur 1 ; on pourra observer qu'elle est stockée de trois façons différentes :
Image
>> entier (soit 00000001 dans l'ordre normal) ;
>> caractère Unicode (soit 0 49 en décimal)
>> nombre à virgule flottante (pourquoi ne trouve-t-on aucun 1 dans ces quatre octets ?
quelques explications, apportées par Microsoft.

D} quatrième type d'éléments : les séquenceurs ; contrairement aux trois précédents, il n'y a pas traduction d'un format à l'autre, mais emploi de deux méthodes différentes :
>> dans le fichier UT, il s'agit des parenthèses, espaces, sauts de ligne, tabulations ; ainsi, au début de notre exemple en format UT, entre la valeur [color=#800000]10
de Tr_Watermark et le mot-clé suivant Static, on trouve successivement
Image
>> dans le fichier UB, il n'y a strictement rien entre le dernier octet de la valeur stockée sous la forme 0A 00 00 00 et le premier du mot-clé suivant 03 00 04 00 ; comment Train.exe peut-il s'y retrouver ? tout se passe entre chaque mot-clé et sa valeur, où se trouvent quatre octets (soulignés dans la figure <7>) indiquant le nombre d'octets occupés par cette valeur.
Image
NB- c'est le même exemple que précédemment, mais en redisposant les octets selon le plan du fichier UT et en gardant la même même couleur pour tous les éléments d'un même mot-clé :

1) l'exemple de la première ligne est simple : après la première valeur-clé [ 4C 00 04 00 ], on trouve quatre octets [ 05 00 00 00 ] indiquant que les données occupent cinq octets : le 00 (*) et les quatre octets de la valeur ; puis on passe directement aux octets de la valeur-clé suivante ;
(*) on trouvera ci-dessous, dans le message d'ActiveMaker daté du 25 février 2014, des précisions sur l'usage de cet octet apparemment superflu.

2) on retrouve le même principe pour les autres entrées, à deux exceptions près :
a} la chaîne de caractères ; la longueur enregistrée est [ 1B 00 00 00 ], soit 27 en décimal ; or la chaîne Spartacus1.s occupe 24 octets en Unicode, auxquels s'ajoute comme d'habitude le 00 qui suit la longueur ; les deux octets restants, [ OC OO ] (soulignés en gris), représentent la longueur de la chaîne au format Ascii (douze caractères, comme déjà vu) et font partie de la donnée elle-même ; on observera
> que cette longueur est codée exceptionnellement sur deux octets et non sur quatre (ce qui laisse quand même la porte ouverte à un nom de fichier de 65535 caractères...)
> que cette façon de faire rend également les guillemets inutiles : une fois que le nombre d'octets de la chaîne est fixé, la présence d'une espace à l'intérieur ne présente plus aucun risque de confusion avec la séparation entre deux valeurs (jusqu'à la décompilation suivante) ;

b} le cas de Static est le plus intéressant : le mot-clé [ 03 00 04 00 ] est suivi de la longueur [ 79 00 00 00 ], soit 121 en décimal ; quelle est donc la valeur de Static qui occupe 121 octets ? l'ensemble des mots-clés + valeurs qui s'étendent, dans le fichier UT, jusqu'à la parenthèse fermante et, dans UB, jusqu'au mot-clé Static suivant (ce mot-clé suivant immédiatement la dernière valeur incluse dans le premier Static, celle de VBdId) ; on voit donc comment cette imbrication des longueurs permet de recréer une hiérarchie correspondant à l'imbrication des parenthèses sans séquenceur explicite.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Troisième partie : FFEditc_Unicode et les transcodages
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Image
NB1- par la suite, le fichier ffeditc_unicode.exe sera désigné par FFEdit ;
NB2- le terme commutateur désigne le paramètre tel que / u ou / c modifiant le mode d'action du programme (il existe d'autres commutateurs, mais sans influence sur le format).

(5) les points gris indiquent un état intermédiaire ; le reste des trajets indiqué est tributaire de la distribution des quatre colonnes (qui est en partie arbitraire).
___A noter : en excluant le format CT du tableau, on arrive à un schéma nettement plus simple :
Image
mais pas vraiment satisfaisant pour l'esprit (voir (6)b}).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(6)Ce qui suit n'a guère d'utilité pour la connaissance ou la pratique de MSTS, mais peut éclairer sur certaines façons de faire à la charnière des XXème et XXIème siècles.
a} qui est censé utiliser FFEdit et pour quoi faire ?
>>> premiers éléments de réponse, logiques :
> d'une part, les créateurs de lignes ou d'objets, pour compresser les fichiers .s, .t et .w (UT --> CB) et en faciliter la diffusion,
> de l'autre, les utilisateurs débrouillards, pour décompresser ces mêmes fichiers (CB --> UT) et pouvoir les examiner ou les modifier ;
> ainsi se justifient les opérations FFEdit UT CB et FFEdit UT CB /c, FFEdit CB UT et FFEdit CB UT /u ;
>>> on peut aussi supposer que ceux qui mettaient au point Train.exe avaient besoin de passer du format UB (employé par le jeu) à UT, à des fins de vérification ; d'où FFEdit UB UT /u
et l'opération inverse : FFEdit UT UB /u - mais ici, comment expliquer l'emploi du commutateur / u ? pourquoi faut-il décompresser un fichier texte (donc par nature décompressé) pour le compiler (ce qui n'est après tout qu'une forme particulière de compression) ? une seule réponse plausible : le commutateur / c et {pas de commutateur} étaient déjà pris par UT --> CB...

b} et le reste ? posons le problème autrement.
>> D'un côté, douze opérations possibles :
_______-| UT > UB | UT > CT | UT > CB
UB > UT |________| UB > CT | UB > CB
CT > UT | CT > UB |________| CT > CB
CB > UT | CB > UB | CB > CT |
>> De l'autre, avec trois commutateurs, FFEdit offre douze choix :
FFEdit UT | FFEdit UT /c | FFEdit UT /u ________FFEdit UB | FFEdit UB /c | FFEdit UB /u
FFEdit CT | FFEdit CT /c | FFEdit CT /u ________FFEdit CB | FFEdit CB /c | FFEdit CB /u
>> On pourrait donc attendre une relation bi-univoque entre opération et commutateur ; or on a ceci :
Image

c} déjà, une constatation : sur les douze opérations possibles, aucune ne correspond à une simple compression ou décompression ; toutes passent par une compilation ou une décompilation ; ainsi, aucun commutateur ne permet de passer de CB à UB en une seule opération ; c'est pourtant ce que Train.exe fait des centaines de fois quand, chargeant une parcelle, il doit lire les différents fichiers .s des objets qui s'y trouvent et les décompresser pour les afficher ;

d} ensuite, le format CT. Sur les vingt-quatre occurrences de fichiers dans le tableau {8} (4 formats x 3 interrupteurs x 2 <source/cible>), ce format revient cinq fois - autant que UB (format le plus utile à Train.exe) ; or on peut s'interroger sur l'intérêt d'un format
+ inutilisable par l'être humain (vs UT) aussi bien que par Train.exe (vs UB),
+ plus encombrant que CB (d'environ 50%),
+ donc plus long à charger,
+ et, qui plus est, plus long à traiter : alors que Train.exe doit seulement décompresser un fichier CB en UB, un fichier CT doit être décompressé en UT puis compilé en UB.
___Alors, vestige d'une piste envisagée puis abandonnée (sans faire le ménage) ou couac d'un travail en équipes (mal coordonné) ?
> Pour en terminer avec CT, signalons qu'il est traité sans problème par Train.exe, aussi bien dans l'Editeur d'itinéraires que dans le jeu, mais que
Shape File Manager indique Unknown format,
Shape Viewer n'affiche que du vide,
Route Riter l'ignore ou renvoie un message d'erreur, selon les cas.
___Apparemment, on n'en trouve aucun exemple nulle part dans le MSTS d'origine (alors qu'il subsiste quelques fichiers UT et que tous les fichiers .t sont, d'origine, au format UB).

(7) Pour fonctionner, FFEdit utilise diverses tables ou annexes (ayant .tok, .bnf ou .hdr comme extension) ; les fichiers NewShape.bnf et WorldFile.bnf sont particulièrement instructifs, parce qu'il contiennent les définitions des différentes sections d'un fichier .s ou .w ; par exemple, le second renferme la structure de l'objet Hazard :

Code : Tout sélectionner

/* Hazard */
hazard_data     = :UiD|:TrItemId|:FileName|:Position|:QDirection|:VDbId .
Hazard          ==> {:hazard_data}
La dernière ligne correspond à Hazard ( ; la précédente aux différentes lignes du fichier UT avant la parenthèse fermante ; mais on peut également y trouver cette définition :

Code : Tout sélectionner

/* Wagon */
wagon_data     =   :UiD|:WagonData|:CoupledWith|:CollideFlags|:FileName|:StaticFlags|:Position|:QDirection|
                           :MaxVisDistance|:VDbId|:StaticDetailLevel|:NotCoupledToActiveTrain .
Wagon          ==>  {:wagon_data}
.
___Ainsi, il aurait dû être possible de placer dans un fichier .w du matériel roulant susceptible d'interagir avec la rame du joueur. Divers essais avec des variantes de

Code : Tout sélectionner

Wagon (
   UId ( 12 )
   WagonData ( Labor )
   CoupledWith ( 0 )
   CollideFlags ( 0 )
   FileName ( Labor.s )
   StaticFlags ( 00008000 )
   Position ( 75.427 0 -312.452 )
   QDirection ( 0 0 0 1 )
   MaxVisDistance ( 100 )
   VDbId ( 0 )
   NotCoupledToActiveTrain ( 0 )
)
n'ont pas donné de résultat mais
a} l'Editeur d'itinéraires n'indique aucune erreur au chargement ;
b} si l'on compile le fichier en UB, on obtient bien ce qui était attendu pour l'ensemble de la section Wagon ;
c} l'essentiel du problème peut résider dans
> le contenu de WagonData (annoncé comme une chaîne de caractères ; mais correspondant à quoi ?)
> la valeur de StaticFlags ; MSTS l'utilise pour répérer diverses particularités : sections de voie ou de route, objets animés, ombre dynamique ; il s'agit d'un double mot, offrant plus de 4 millards de possibilités ; trouver la bonne n'est pas évident - à supposer que la partie correspondante, dans Train.exe, ne se limite pas à une instruction RET.
___Pour être complet, ajoutons que, à côté de Wagon, on trouve une section Engine (avec une ligne EngineVariables) et même une section Train.

___Etrange patchwork que MSTS. Mais après tout, c'est aussi pour ça qu'on l'aime.
___Puisse-t-il vous offrir encore longtemps de beaux voyages.

Annexe 1 : comparaison des formats UB et UT d'un fichier .s complet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Il s'agit d'un objet basique créé avec TSM :
http://www.hostingpics.net/viewer.php?id=41395520UTUB0.jpg___0- Légende
http://www.hostingpics.net/viewer.php?id=92995921UTUB1.jpg___1- de l'en-tête à uv_points
http://www.hostingpics.net/viewer.php?id=27273122UTUB2.jpg___2- de normals à textures
http://www.hostingpics.net/viewer.php?id=42196123UTUB3.jpg___3- de light_materials à hierarchy
http://www.hostingpics.net/viewer.php?id=77175924UTUB4.jpg___4- de sub_objects à vertex_set
http://www.hostingpics.net/viewer.php?id=30408225UTUB5.jpg___5- de primitives à flags

Annexe 2 : récupération des valeurs-clés dans Train.exe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___Il n'existe pas de table donnant, pour chaque mot-clé, la valeur-clé ; on trouve seulement une liste des mots-clés, dans l'ordre inverse de leur numérotation (séparés par quatre ou six octets nuls) ; pour fixer la valeur-clé de chacun, il faut partir du dernier puis remonter jusqu'au premier.
S'agissant de mots-clés rencontrés dans des fichier .s, .t et .env (et peut-être quelque autre), on arrive à la liste suivante :

Code : Tout sélectionner

0001 - comment
0002 - point
0003 - vector
0004 - quat
0005 - normals
0006 - normal_idxs
0007 - points
0008 - uv_point
0009 - uv_points
000A - colour
000B - colours
000C - packed_colour
000D - image
000E - images
000F - texture
0010 - textures
0011 - light_material
0012 - light_materials
0013 - linear_key
0014 - tcb_key
0015 - linear_pos
0016 - tcb_pos
0017 - slerp_rot
0018 - tcb_rot
0019 - controllers
001A - anim_node
001B - anim_nodes
001C - animation
001D - animations
001E - anim
001F - lod_controls
0020 - lod_control
0021 - distance_levels_header
0022 - distance_level_header
0023 - dlevel_selection
0024 - distance_levels
0025 - distance_level
0026 - sub_objects
0027 - sub_object
0028 - sub_object_header
0029 - geometry_info
002A - geometry_nodes
002B - geometry_node
002C - geometry_node_map
002D - cullable_prims
002E - vtx_state
002F - vtx_states
0030 - vertex
0031 - vertex_uvs
0032 - vertices
0033 - vertex_set
0034 - vertex_sets
0035 - primitives
0036 - prim_state
0037 - prim_states
0038 - prim_state_idx
0039 - indexed_point_list
003A - point_list
003B - indexed_line_list
003C - indexed_trilist
003D - tex_idxs
003E - tri
003F - vertex_idxs
0040 - flags
0041 - matrix
0042 - matrices
0043 - hierarchy
0044 - volumes
0045 - vol_sphere
0046 - shape_header
0047 - shape
0048 - shader_names
0049 - shader_name
004A - texture_filter_names
004B - texture_filter_name
004C - sort_vectors
004D - uvop_arg_sets
004E - uvop_arg_set
004F - light_model_cfgs
0050 - light_model_cfg
0051 - uv_ops
0052 - uvop_copy
0053 - uv_op_share
0054 - uv_op_copy
0055 - uv_op_uniformscale
0056 - uv_op_user_uninformscale
0057 - uv_op_nonuniformscale
0058 - uv_op_user_nonuninformscale
0059 - uv_op_transform
005A - uv_op_user_transform
005B - uv_op_reflectxy
005C - uv_op_reflectmap
005D - uv_op_reflectmapfull
005E - uv_op_spheremap
005F - uv_op_spheremapfull
0060 - uv_op_specularmap
0061 - uv_op_embossbump
0062 - user_uv_args
0063 - io_dev
0064 - io_map
0065 - sguid
0066 - dlev_cfg_table
0067 - dlev_cfg
0068 - subobject_shaders
0069 - subobject_light_cfgs
006A - shape_named_data
006B - shape_named_data_header
006C - shape_named_geometry
006D - shape_geom_ref
006E - material_palette
006F - blend_config
0070 - blend_config_header
0071 - filtermode_cfgs
0072 - filter_mode_cfg
0073 - blend_mode_cfgs
0074 - blend_mode_cfg
0075 - texture_stage_progs
0076 - texture_stage_prog
0077 - blend_mode_cfg_refs
0078 - shader_cfgs
0079 - shader_cfg
007A - texture_slots
007B - texture_slot
007C - named_filter_modes
007D - named_filter_mode
007E - filtermode_cfg_refs
007F - filtermode_cfg_ref
0080 - named_shaders
0081 - named_shader
0082 - shader_cfg_refs
0083 - shader_cfg_ref
0084 - terrain_desc
0085 - terrain_desc_flags
0086 - terrain_desc_size
0087 - terrain_desc_tiles
0088 - terrain
0089 - terrain_errthreshold_scale
008A - terrain_alwaysselect_maxdist
008B - terrain_samples
008C - terrain_nsamples
008D - terrain_sample_rotation
008E - terrain_sample_floor
008F - terrain_sample_scale
0090 - terrain_sample_size
0091 - terrain_sample_fbuffer
0092 - terrain_sample_ybuffer
0093 - terrain_sample_ebuffer
0094 - terrain_sample_nbuffer
0095 - terrain_sample_cbuffer
0096 - terrain_sample_dbuffer
0097 - terrain_shaders
0098 - terrain_shader
0099 - terrain_texslots
009A - terrain_texslot
009B - terrain_uvcalcs
009C - terrain_uvcalc
009D - terrain_patches
009E - terrain_patchsets
009F - terrain_patchset
00A0 - terrain_patchset_distance
00A1 - terrain_patchset_npatches
00A2 - terrain_patchset_fbuffer
00A3 - terrain_patchset_patches
00A4 - terrain_patchset_patch
00A5 - terrain_transfers
00A6 - terrain_transfer
00A7 - terrain_shapes
00A8 - terrain_shape
00A9 - world
00AA - world_shader
00AB - world_anim_shader
00AC - world_anim_shader_framelen
00AD - world_anim_shader_frames
00AE - world_anim_shader_frame
00AF - world_anim_shader_frame_uvtiles
00B0 - world_anim_shader_frame_uvscroll
00B1 - world_anim_shader_frame_uvstamp
00B2 - world_fog_distance
00B3 - world_fog_day_colour
00B4 - world_fog_night_colour
00B5 - world_sky
00B6 - world_sky_layers
00B7 - world_sky_nlayers_behind_satellites
00B8 - world_sky_layer
00B9 - world_sky_layer_fadein
00BA - world_sky_layer_fadeout
00BB - world_sky_layer_top
00BC - world_sky_layer_top_nfaces
00BD - world_sky_layer_top_radius
00BE - world_sky_layer_top_height
00BF - world_sky_layer_edge
00C0 - world_sky_layer_edge_steps
00C1 - world_sky_layer_edge_step_height
00C2 - world_sky_layer_edge_step_radius
00C3 - world_sky_horizon
00C4 - world_sky_satellites
00C5 - world_sky_satellite
00C6 - world_sky_satellite_low_scale
00C7 - world_sky_satellite_high_scale
00C8 - world_sky_satellite_rise_time
00C9 - world_sky_satellite_dir_rise_colour
00CA - world_sky_satellite_dir_high_colour
00CB - world_sky_satellite_dir_set_colour
00CC - world_sky_satellite_amb_rise_colour
00CD - world_sky_satellite_amb_high_colour
00CE - world_sky_satellite_amb_set_colour
00CF - world_sky_satellite_rise_position
00D0 - world_sky_satellite_set_time
00D1 - world_sky_satellite_fade_time
00D2 - world_sky_satellite_light
00D3 - world_sky_satellite_fog
00D4 - world_water
00D5 - world_water_wave_height
00D6 - world_water_wave_speed
00D7 - world_water_layers
00D8 - world_water_layer
00D9 - world_water_layer_height
00DA - world_water_layer_sky_reflection
00DB - world_precipitation
00DC - world_precipitation_type
00DD - world_precipitation_type_rain
00DE - world_precipitation_type_snow
00DF - world_precipitation_density
00E0 - world_precipitation_radius
00E1 - world_precipitation_speed
00E2 - world_precipitation_near_z_bias
00E3 - world_precipitation_volume_radius
00E4 - world_precipitation_volume_rel_height
00E5 - world_wind
00E6 - world_wind_layers
00E7 - world_wind_layer
00E8 - world_wind_layer_maxheight
00E9 - world_wind_layer_direction
00EA - world_wind_layer_speed
00EB - world_wind_layer_turbulencep
00EC - world_sky_lensflares
00ED - world_sky_lensflare
00EE - world_simple_shaders
00EF - world_simple_shader
00F0 - world_sky_lens_beads
00F1 - world_sky_lens_bead
00F2 - world_glares
00F3 - world_glare
00F4 - world_blit3duvs
00F5 - max_data
00F6 - max_dlev_data
00F7 - max_smoothing_data
00F8 - max_sort_priorities
00F9 - uv_op_diffusemap
00FA - world_fog_start_distance
00FB - terrain_water_height_offset
00FC - distance_level_info
00FD - level_of_detail
00FE - texaddr
00FF - texture_material
0100 - texture_materials
0101 - packed_colours
0102 - volume_info
0103 - geom
0104 - material
0105 - materials
0106 - anim_children
0107 - corner
0108 - corners
0109 - u_tri
010A - u_quad
010B - quad
010C - u_strip
010D - strip
010E - u_fan
010F - fan
0110 - u_trilist
0111 - node
0112 - node_children
0113 - nodes
0114 - terrain_samples_rotation
0115 - terrain_npatches
0116 - terrain_patch_fbuffer
0117 - terrain_patch_map
0118 - terrain_npatchsets
0119 - terrain_sample_asbuffer
011A - terrain_sample_usbuffer

NB1- la méthode employée ici exploite les données figurant dans Train.exe ; on pourrait aussi partir des tables coreids.tok et newshape.bnf utilisées par FFEdit (voir la note (7) plus haut) ;
NB2- indépendamment de toute valeur-clé, cette liste peut être intéressante dans la mesure où elle recense les mots-clés pouvant apparaître dans un fichier .s décompressé ;
NB3- pour les fichiers .w, les choses sont un peu moins claires parce que
a} ces mots-clés sont beaucoup plus mélangés avec ceux d'autres fichiers (notamment .eng/.wag ou .dat) ;
b} les valeurs-clés présentent, à partir d'une certain seuil, un décalage de deux unités par rapport à ce que l'on peut observer dans les fichiers ;
c} il est impossible de récupérer un des fichiers autres que .w dans un format UB, pour situer l'endroit (et la cause) de ce décalage ; peut-être une comparaison avec les tables de FFEdit donnerait-elle la réponse.

Annexe 3 : un utilitaire en Visual Basic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___Il doit être composé de trois modules :
(1) Convertir un fichier d'un format dans n'importe lequel des trois autres ;
(2) Lister de les fichiers .s/.t/.w d'un répertoire selon leur format ;
(3) Afficher un fichier en mode texte (si UT) ou en hexadécimal (si UB, CT ou CB).
___Photos d'écran à venir.
Modifié en dernier par XylonAkau le 26 févr. 2014 1:16, modifié 1 fois.
Raison : Ajout d'un lien vers un complément d'information

Avatar du membre
Jimidi
Expert
Messages : 1920
Enregistré le : 02 nov. 2008 14:32
Localisation : Ille sur Têt (66)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar Jimidi » 26 août 2012 9:22

Bonjour,

Ouh la la! Ça Patrice, j'adore! ?+
Merci grandement pour ce travail colossal partagé.
Travail soigné, complet, clair et pédagogique... et en français! J'espère que nous serons le plus nombreux possible à déjà en admirer la démarche et prendre conscience de la valeur énorme de toutes tes publications récentes!
applaus001 applaus001 applaus001
Amicalement, Jean-Michel
"T'occup' nin des signaux garchon, mets du carbon !"
Image
facebook Jimidi

Avatar du membre
Théo
Messages : 250
Enregistré le : 27 sept. 2005 21:12
Localisation : la Sarthe

Re: Du format des fichiers .s, .w et .t

Messagepar Théo » 26 août 2012 11:21

Bonjour à Toutes & Tous,

Alors la, je suis admiratif - Tant de clarté, de précision dans les termes et d'esprit d'analyse - CHAPEAU MONSIEUR .:
J'ai relu 3 fois et bien des choses encore m'échappent ( la majeure partie d'ailleur ... confused19 )
C'est la ou on voit que l'informatique est une science et une connaissance à part entière.
Bon dimanche à tous et merci encore à XylonAkau de ses prestations géniales. .=

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 26 août 2012 20:07

___Ia ora na, et merci pour vos commentaires.
___Bien sûr, vous avez connu cela : on travaille sur x petites choses à droite et à gauche, et, un jour, elles semblent s'emboîter les unes dans les autres pour former un tout - un peu plus satisfaisant pour l'esprit.
___Un peu plus seulement (et c'est dans doute heureux pour notre modestie) ; ainsi, l'octet qui se trouve entre la longueur de la donnée et cette donnée reste (pour moi du moins) un mystère, tout comme le fait que certaines longueurs de chaînes soient stockées sur un octet, et non pas deux.
___Que ces incertitudes ne vous empêchent pas de passer une bonne semaine.

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

Re: Du format des fichiers .s, .w et .t

Messagepar BB25187 » 02 sept. 2012 12:31

Hello,

Ah ben tu n'as pas fait les choses à moitié dis-moi! applaus001 .=
Je mets ça de côté pour pouvoir le lire à tête reposée: ça le mérite!

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

Image

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 29 sept. 2012 0:47

___Ia ora na.
___Un volet (au moins...) manquait au premier message : une étude des différents outils permettant de passer d'un format à un autre. Une discussion récente sur Elvas Tower semble l'occasion de combler cet oubli.
___Nous laisserons de côté les fichiers .t, que l'on ne trouve nativement qu'en format compilé UB pour ne considérer que les fichiers .s et les fichiers .w - en décompression/décompilation (CB --> UT) ou en compilation (UT --> UB) et compression (UB --> CB).

A} Fichiers .s
~~~~~~~~~~~
___Il existe au moins quatre compacteurs/décompacteurs :
a} FFEditc_Unicode.exe / SFM
___Qu'il s'agisse de l'ancienne ou de la nouvelle version, SFM utilise FFEdit ; mais, lors de son installation, SFM modife l'un des fichiers utilisés (Newshape.bnf) pour corriger une erreur de FFEdit ; il est donc préférable d'installer SFM même si l'on veut employer ensuite FFEdit.
NB- les deux programmes ne traitent qu'un fichier à la fois, mais on peut envisager un fichier .bat pour l'utilisation de FFEdit .
b} Route Riter : selon la documentation, ce programme utilise les routines de Martyn T. Griffin (que l'on peut trouver sur UkTrainsim) ; il est prévu un traitement par lot ;
c} TK_Zipper / TK_Archibald : utilisent des routines créées par Okrasa Ghia ; TK_Zipper permet le traitement par lot ;
d} SimisEditor, de James Ross ; c'est un peu un équivalent de TK_Archibald (mais il permet de traiter quasiment tous les fichiers SIMIS de MSTS, quelle que soit leur extension).
___Pour Huecuvoe (l'auteur de la récente mise-à-jour de SFM), FFEdit et (par conséquent) SFM sont les plus sûrs :
I [...] came to the conclusion that FFEDITC_UNICODE was faster and more reliable in general.

1) CB -> UT
___Afin d'avoir un point de comparaison, le test a porté sur trois fichiers : crates.s (très simple), OESignal1.s (simple mais comportant une animation) et (pour gravir un sommet) JIM_PontFerTertre.s (nettement plus complexe ; j'espère que Jean-Michel me pardonnera le sacrilège) en comparant les quatre versions UT :
NB préalable : le fichier CB de départ est, pour crates.s et OESignal1.s, ce qu'installe MSTS ; pour JIM_PontFerTertre.s, ce que produit la décompression de l'archive zip ;
première observation >>> quel que soit le type de fichier .s (simple ou complexe), les différences entre versions restent les mêmes : si les versions X et Y diffèrent sur tel point pour crates.s, elles différeront sur le même point (et celui-là seulement) pour OESignal1.s et JIM_PontFerTertre.s ; on peut donc se limiter à une comparaison horizontale ;
observations suivantes >>>
a} les versions issues de FFEdit, TK_Zipper et SIMISEditor ne se différencient que par des détails de présentation (chiffres hexadécimaux en minuscules pour l'un, en majuscules pour les autres ; passage à la ligne versus valeurs sur une seule ligne) ;
b] celles de Route Riter présentent une seule différence, mais récurrente : alors que les nombres décompilés en décimaux sont, partout ailleurs, arrondis à six chiffres significatifs, ceux que produit RR sont arrondis à six chiffres bruts après la virgule ou le point. Deux exemples, dans la partie 1) du tableau :
Image

2) UT -> UB
a} Ni SFM ni Route Riter ne permettent cette conversion (il est clair que ces deux programmes passent par une version UB des fichiers qu'ils traitent, mais il n'est pas possible de récupérer cette version transitoire ; il en va d'ailleurs de même avec ShapeViewer s'agissant de la décompression et, primus inter pares, de Train.exe lui-même). Restent donc FFEdit, TK_Zipper et SimisEditor ;
b} pour ce test, on a pris comme version de départ d'un côté celle de crates.s produite par FFEdit (vu la nature de la compilation, les différences relevées entre FFEdit, TK_Zipper et SIMISEditor sont sans conséquence), de l'autre, celle de ce même fichier produite par RR ;
première observation >>> pour un fichier UT donné, la compilation donne des résultats rigoureusement identiques pour tous les programmes ;
observation suivante >>> la seule différence se situe entre les fichiers compilés à partir de la version FFEdit et ceux de la version RR, comme l'indique la partie 2) du tableau précédent.

3) UT -> CB
___Pour ne pas multiplier les cas de figure, le test n'a porté que sur la version de OESignal1.s décompressée à l'aide de FFEdit ; on retrouve ici l'ensemble des utilitaires mentionnés en A]. Mais, contrairement aux deux cas précédents, il n'est pas possible d'analyser les différences entre les différentes versions compressées ; on ne peut que constater les éventuelles différences.
a} fichier d'origine = fichier compressé par FFEdit___: 13114 octets
b} fichier compressé par TK_Zipper_______________: 13399 o (seuls les 18 premiers octets sont communs)
c} fichier compressé par Route Riter______________: 13404 o -- id --
d} fichier compressé par SimisEditor______________: 18066 o -- id --
___Pourtant, si on décompresse avec FFEdit les quatre fichiers obtenus ci-dessus, on peut constater que
les quatre fichiers UT résultants sont identiques.

B} Fichiers .w
~~~~~~~~~~~~
___Un outil en moins (SFM) et un en plus (l'Editeur d'itinéraires) ; on a donc :
a} FFEdit
b} Route Riter
c} TK_Zipper
d} SimisEditor
dans les mêmes conditions que précédemment, plus
e} l'éditeur d'itinéraires, qui enregistre les fichiers .w au format UT.

___Inutile de revenir sur les éléments déjà mentionnés dans la première partie à propos des quatre premiers outils (arrondi particulier à Route Riter en UB --> UT ; résultats identiques en UT --> UB, équivalents en UB --> CB) ; on se limitera donc à un cas particulier, mais de taille : quand il décompile un fichier .w, FFEdit traite les ViewDbSphere autrement que ne le font les trois autres programmes ; alors que ceux-ci hiérarchisent les ViewDbSphere en alternant emboîtement et juxtaposition, FFEdit les emboîte systématiquement les unes dans les autres, de la première à la dernière :
Image
___Dans le cas présent, la différence de présentation n'est pas anecdotique, elle traduit une organisation différente (que l'on retrouve dans les fichiers UB respectifs) ; dans le fichier sain, la VDbS 1 (en bleu foncé) contient deux VDbS : 68 (en vert) et 69 (en orange), et se trouve à côté de la VDbS 2 (en gris) et de la VDbS 3 (en violet) ; dans le fichier issu de FFEdit, la VDbS 1 contient la VDbS 68 (correct) qui contient la VDbS69 (faux) qui contient la VDbS 2 (archi-faux) qui contient la VDbS 3 (absurde : une sphère de 11 mètres de rayon (VDbS 2) censée contenir une sphère de 25 mètres de rayon (VDbS 3) !).
Pratiquement, comment réagir en présence d'un fichier décompressé à l'aide de FFEdit (facilement reconnaissable à son indentation en cascade et sa flopée de parenthèses fermantes) ?
1) ce qu'il ne faut pas faire :
a} l'utiliser dans le jeu ; ou alors, soyez prêts à traverser ce genre de choses :
Image
b} le recompresser (que ce soit avec FFEdit ou un autre programme) ; l'erreur demeure ;
2) ce que l'on peut faire :
___l'ouvrir avec l'éditeur d'itinéraires, modifier la parcelle puis la réenregistrer ; la nouvelle version sera saine et pourra être compressée (avec FFEdit ou un autre programme).
NB1- les bizarreries de la photo d'écran peuvent déborder dans les parcelles voisines ; vérifier que la parcelle fautive figure bien parmi les parcelles réenregistrées ;
NB2- les bizarreries en question sont visibles dans l'éditeur d'itinéraires quand on charge le fichier fautif et le restent durant toute la session ; ce n'est qu'après avoir enregistré la parcelle et rouvert la ligne que l'on obtiendra une image saine ; une variante consiste à supprimer tout ce qui concerne les ViewDbSpere avant de charger le fichier ; l'éditeur les recréera ;
NB3- on trouvera en addendum quelques éléments sur le problème quasiment existentiel posé par cette bizarrerie.
___C'est sans doute ce qui mène Huecuvoe à écrire :
1. ONLY the Route Editor correctly uncompresses WORLD files.
___L'exemple précédent conduit d'ailleurs à penser que, même si cela revient au même, les choses se passent un peu différemment dans l'éditeur : quand il doit enregistrer le fichier .w, l'éditeur reconstruit l'ensemble des ViewDbSpere sans s'occuper de l'état initial, ce qui revient à le corriger s'il était fautif ; ce n'est pas ainsi que procèdent les autres programmes, qui se contentent de traduire le fichier UB en UT.
___Un indice supplémentaire, avec ce même fichier (il s'agit de la parcelle w-006114+015082.w de la ligne Europe1) :
a} si on décompresse (ou décompile) le fichier d'origine (11 kO du 07/05/2001), avec FFEdit, RR, etc., on obtient 72 ViewDbSphere (de VDbId ( 0 ) à VDbId ( 71 )) ;
b} si, dans l'éditeur d'itinéraires, on modifie la parcelle au minimum (une fois en tournant légèrement un arbre, une autre fois en le supprimant), l'éditeur enregistre une 73ème ViewDbSphere ; c'est la seule différence avec les fichiers décompressés (en dehors de la modification de l'arbre), mais elle a des conséquences dans tout le fichier parce que la nouvelle ViewDbSphere décale les numéros de VDbId des autres, ce qui change aussi le numéro de VDbId des objets Static, TrackObj, etc. ;
c} fermons l'éditeur et rouvrons-le avec le nouveau fichier w-006114+015082.w (de 204 kO), puis tournons légèrement un arbre et enregistrons la parcelle : on est revenu à 72 ViewDbSphere mais qui ne sont pas totalement identiques à celles de l'original ;
d} quand on part du fichier corrompu de FFEdit (aussi bien en conservant la cataracte de VDbS qu'après l'avoir supprimée), l'éditeur enregistre le fichier avec 74 ViewDbSphere.

___Avant de terminer, un petit test pour avoir une idée de ce que représente la différence entre les valeurs enregistrées par Route Riter et les autres (on doit pouvoir faire un tel test pour les fichiers .s, mais j'ai trouvé celui-ci plus à ma portée) : deux formes identiques (une sorte de planche de 800 m de long), l'une rouge et l'autre bleue, placées avec les mêmes coordonnées (Position) et, d'abord, les mêmes valeurs de quaternion (QDirection) ; seule la planche bleue est visible, quel que soit le point-de-vue (mais seule la planche rouge peut être sélectionnée) ; ensuite, modifions les valeurs de QDirection :
pour la planche rouge, les valeurs de Route Riter : -0.000498 0 -0.000498 0.999999
pour l'autre, celles de FFEdit : -0.000498485 0 -0.000498485 0.999999
___Les planches se distinguent assez nettement sous certains angles (la route et l'arbre sont là pour donner une échelle).
Image
___Reste que sous d'autres angles, une seule des deux planches est visible, et que si l'on choisit deux objets de même texture et/ou moins longs, l'effet est quasiment indiscernable.

___Bien sûr, un travail mené sur quelques fichiers seulement ne permet pas de tirer des conclusions définitives. Cependant, il peut donner quelques jalons dont chacun pourra user ensuite selon ses besoins.

Addendum à propos de FFEdit et les ViewDbSphere :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___Les anomalies rencontrées jusqu'à présent étaient logiques : la transformation d'un fichier UT en UB ou vice-versa implique de nombreuses règles, il peut arriver d'en oublier ou mal utiliser une - un peu comme un étranger peut dire ou écrire "j'ai lu vos journals" ; mais, pour rester dans la métaphore, celle-ci s'apparenterait plutôt à un magnétophone qui, quand on enregistre "j'ai lu vos journaux" restituerait "j'ai lu vos romans" ; apparemment, l'erreur se produirait dans le passage de CB à UB - une décompression qui ne peut pas produire une erreur sensée comme celle-ci (de même que le magnétophone pourrait remplacer journaux par un silence, des crachotements, du larsen, mais pas par un mot différent).
___Reste donc une explication un peu alambiquée, mais la seule entrant dans la logique des opérations : FFEdit décompresse correctement le fichier CB en UB ; puis il décompile mal le fichier UB en UT ; après quoi, pour donner à l'utilisateur le fichier UB demandé, il recompile le fichier UT (fautif) en un fichier UB (lui aussi fautif). Ce serait une forme particulièrement aboutie du célèbre principe : pourquoi faire simple et exact quand on peut faire compliqué et faux ?
___Difficle à prouver, mais un indice va dans ce sens : si on décompresse le fichier CB d'origine avec TK_Zipper ou SimisEditor, on obtient un fichier UB sain ; si on décompile ce fichier sain à l'aide de FFEdit, on obtient un fichier fautif ; c'est donc bien là que se situe l'erreur.
___La vraie preuve serait de pouvoir corriger le fichier Wordfile.bnf pour obtenir un résultat correct, mais, comme Boris Vian le faisait dire à cet oncle aussi bricoleur qu'amateur
Y'a quelque chose qui cloche là-dedans
J'y retourne immédiatement.


___Alors, bonne fin de semaine à toutes et à tous.

Avatar du membre
Jimidi
Expert
Messages : 1920
Enregistré le : 02 nov. 2008 14:32
Localisation : Ille sur Têt (66)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar Jimidi » 29 sept. 2012 9:15

Bonjour,

Magistral et très instructif, comme à l'accoutumé désormais!
Merci Patrice et bravo. applaus001 applaus001 applaus001

Jean-Michel
"T'occup' nin des signaux garchon, mets du carbon !"
Image
facebook Jimidi

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

Re: Du format des fichiers .s, .w et .t

Messagepar BB25187 » 30 sept. 2012 18:13

Hello Patrice,

Merci pour ce nouveau traité détaillé. La comparaison des outils de compression va nous être bien utile, de même que les petits trucs pour contourner les défauts qu'ils présentent. J'ajoute à la liste des documents qu'il faut que je relise à tête reposé (comme disais Louis le seixième!).

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

Image

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 02 oct. 2012 3:25

___Ia ora na.
___Pour honorer cette montée, voici le fichier batch évoqué dans un des messages précédents et permettant de compresser ou décompresser plusieurs fichiers à la fois avec FFEdit (pour les utiliser ensuite ou après les avoir utilisés avec SFM, si on le souhaite).
NB1- Il existe un programme équivalent, écrit en Visual Basic - plus convivial et plus souple, plus intelligent aussi puisqu'il permet de s'affranchir de deux limites indiquées ci-dessous en NB2 ; mais son fonctionnement nécessite que soient installées les bibliothèques de VB6 ; si quelqu'un dispose déjà de ces bibliothèques, les liens pour un téléchargement peuvent être mis à sa disposition ; sinon, ce petit fichier de commandes devrait suffire.
NB2- Ce programme se heurte donc à deux limites :
a} il ne traite pas les fichiers dont le nom contient une (ou plusieurs) espace(s) ; il faudrait la (ou les) remplacer (par exemple) par _ ;
b} il fonctionne comme TK_Zipper avec le commutateur /t (toggle) : les fichiers compressés (CB) sont décompressés (UT) et inversement ; il n'est pas possible de ne compresser (ou décompresser) que les fichiers qui ne le sont pas.
NB3- On trouvera ci-dessous deux fois le contenu du fichier : une première fois dans une fenêtre Code, pour faciliter la copie dans le presse-papiers, une deuxième fois en texte simple, pour disposer de couleurs.

Code : Tout sélectionner

m:
cd "\train simulator\utils\ffedit"
FOR %%X IN (trav\*.s) DO ffeditc_unicode %%X /o:%%X >> log.txt
FOR %%X IN (trav\*.w) DO ffeditc_unicode %%X /o:%%X >> log.txt
pause
m:
cd "\train simulator\utils\ffedit"

FOR %%X IN (trav\*.s) DO ffeditc_unicode %%X /o:%%X >> log.txt
FOR %%X IN (trav\*.w) DO ffeditc_unicode %%X /o:%%X >> log.txt
pause

Mode d'emploi
~~~~~~~~~~~~~~
A} Installation de Formats.bat (à faire une seule fois)
1) Copier-coller le contenu du fichier dans une page du bloc-notes.
2) Modifier les deux premières lignes pour qu'elles correspondent à l'instance de MSTS. Par exemple, pour une installation par défaut sous XP :

Code : Tout sélectionner

c:
cd "\program files\train simulator\utils\ffedit"
3) choisir Enregister sous puis, dans la combo-liste Type (en bas), "Tous les fichiers" ; enregistrer le fichier sous le nom Formats.bat ;
4) créer dans le répertoire \utils\ffedit un sous-répertoire \Trav ;

B} Utilisation
1) copier dans le répertoire \Trav les fichiers .s et/ou .w à transformer ;
2) lancer Formats.bat .
On obtiendra donc le même résultat que si l'on avait traité ces fichiers à l'aide de TK_Zipper avec le commutateur /t.

NB1- Plusieurs éléments, dans le mode d'emploi ou le programme lui-même, sont le résultat d'un choix plus ou moins arbitraire ; on peut évidemment remplacer Formats ou Trav par d'autres noms ou bien placer les fichiers dans le répertoire \FFEdit lui-même, à la seule condition de respecter les règles de MS-Dos ; la solution retenue a été, à chaque fois, celle qui semblait la plus simple ou la plus sûre ; la discussion sur son bien-fondé reste évidemment ouverte et libre.
NB2- Voici quelques variantes possibles, qui portent sur le comportement du programme :
1) si on conserve la mention en fin de ligne, MS-Dos enregistre dans un fichier \utils\ffedit\log.txt le détail des opérations ;
a} ces opérations s'affichent par défaut dans la fenêtre de l'invite de commande, mais elles défilent très rapidement ;
b} pour ne plus créer ce fichier, il suffit de supprimer les deux mentions.
2) La ligne pause oblige MS-Dos à laisser la fenêtre MS-Dos ouverte jusqu'à ce qu'on appuie sur une touche ; si on supprime cette ligne, la fenêtre se refermera automatiquement à la fin du travail.
3) Dans cette version, le fichier d'origine est remplacé par le fichier au nouveau format (c'est pourquoi il est indiqué {aux deux sens du terme} de copier les fichiers, plutôt que de les déplacer) ; si l'on veut conserver intact l'ancien fichier et en créer un nouveau, deux solutions (parmi d'autres) :
a} la plus simple : remplacer les deux expressions /o:%%X par /o:%%XZ : le nouveau fichier aura le même nom que le précédent, mais avec une extension .sZ ou .wZ ;
b} plus élaborée : créer dans le répertoire \ffedit un sous-répertoire \Prov puis, dans \Prov, un sous-sous-répertoire \Trav (qui s'appellera donc utils\ffedit\Prov\Trav) et remplacer /o:%%X par /o:prov\%%X ; le nouveau fichier portera le même nom que l'ancien, mais sera placé dans un répertoire-neveu.

___Bon courage à toutes et à tous.

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

Re: Du format des fichiers .s, .w et .t

Messagepar BB25187 » 04 oct. 2012 19:16

Hello,

Merci à toi! .=

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

Image

retore
Messages : 3625
Enregistré le : 10 nov. 2007 15:20
Localisation : lesigny

Re: Du format des fichiers .s, .w et .t

Messagepar retore » 07 oct. 2012 6:08

Bonjour
Et énorme merci
Amitiés michel applaus001

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

Re: Du format des fichiers .s, .w et .t

Messagepar BB25187 » 04 mai 2013 10:48

Hello Patrice,

Souhaitant bidouiller un peu les fichiers world de PT3 (il s'agissait d'utiliser la correction apportée dans PT32 aux quais de la gare de Stuttgart et de la reporter dans PT3), j'ai pu juger sur un cas pratique de la grande utilité de ton article et l'utiliser à plein. Il m'aura évité de patauger trop longtemps dans les particularités de conversion de formats de FFEDIT, et de passer plus vite à RR dès le début de l'opération (conversion en UNICODE).
Libéré des soucis de "dé/compression", j'ai pu me concentrer sur le coeur de mon sujet. Ainsi, ma gare de Stuttgart PT3 a non seulement des abris de quai posés bien horizontalement, mais de surcroît j'ai pu aussi les prolonger en ajoutant les mêmes objets que ceux présents dans PT32 (à l'époque de PT3, on posait souvent les objets avec parcimonie!).
Et du coup je peux retourner à mes Vtu84 l'esprit apaisé! /nb

Un grand merci à toi pour cet "incontournable"! .=
A+
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 06 mai 2013 7:59

___Ia ora na, Vincent.
___C'est rassurant de savoir qu'un travail essentiellement théorique peut aussi avoir quelque utilité dans la pratique.
___Pour la pratique, je me contenterai d'admirer, en te souhaitant le meilleur dans la poursuite de tes projets. Bonne semaine à toi, et à tous.

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

Re: Du format des fichiers .s, .w et .t

Messagepar ActivMaker » 22 févr. 2014 19:27

Bonjour,

Je reviens vers cet article fort intéressant . Je cherche des infos sur le codage binaire . Je n'ai pas réussi à faire le lien un mot clé et sa valeur en binaire. Cas concret :
Mot clé Static représenté en binaire par 03 00 04 00. Comment avoir la liste des associations Mot<=>Valeur . J'ai cherché dans tous les fichiers de FFEDIT , on dans forms.hdr une ligne SIDDEF(FORM_STATIC, "Static") mais que vaut FORM_STATIC ?

J'ai cherché dans les source de OR. Notamment dans le fichier Tokenid.cs , on trouve
Static = 303 (Décimal) . Représenté donc en hexa par 12F

Static dans le .w est représenté par 0x403 => 1027 en décimal... Avec le commentaire
"These ones were made up by reading values in binary world files"
Static = 303,
TrackObj = 305,
Forest = 308,
CollideObject = 311,
Signal = 317,
Platform = 360,
LevelCr = 362,
Speedpost = 364,
Hazard=365,


De manière générale, pour un mot clé donné , quel valeur binaire doit on chercher dans le .W ?? <2<

Avatar du membre
XylonAkau
Messages : 1936
Enregistré le : 24 juil. 2010 8:49
Localisation : Taputapuatea (ISLV)
Contact :

Re: Du format des fichiers .s, .w et .t

Messagepar XylonAkau » 23 févr. 2014 0:10

___Ia ora na.
___Pas facile !
1) tes équivalences hexa <-> décimal ou vice-versa sont exactes quand elles portent sur un entier de deux octets : 303 déc et 12F hexa sont bien une seule et même valeur ;
2) mais
a} dans tous les fichiers binaires utilisés par les processeurs Intel, les valeurs sont rangées non pas dans l'ordre naturel mais dans l'ordre poids faible puis poids fort. Donc la valeur 12F est enregistrée sous forme de deux octets 2F 01 ; quand on a à manipuler un hexadécimal de deux (ou plusieurs) octets, il faut donc savoir s'il est resté au format Intel ou s'il a été remis sous sa forme naturelle ;
b} le token des mots-clés est un entier long (quatre octets) ; et là encore, les octets sont inversés ; ainsi, quand on lit dans un fichier binaire (comme les fichiers de MSTS compilés au format UB)
03 00 04 00
la valeur naturelle est 00 04 00 03, où 00 04 est le numéro de la classe de tokens (il n'existe, si je ne me trompe pas, que deux classes : 00 00 et 00 04) et 00 03 le numéro du token dans cette classe ; dans une liste dressée par James Ross pour SIMIS Editor, on trouve

Code : Tout sélectionner

0x0004,0x0003,Static
qui correspond bien à ce que tu indiques au début de ton message. Mais on ne peut pas chercher un équivalent décimal de 00 04 00 03 (qui vaudrait 262147) : c'est simplement le troisième token de la classe 04 ; quant à la distinction entre les deux classes, elle doit se faire par le contexte : les mots-clés de la classe 00 correspondent aux fichiers d'environnement et à l'extracteur de géométrique, ceux de la classe 04, aux autres fichiers ; si je me souviens bien, ces mots-clés figurent en liste dans Train.exe sans correspondant numérique ; c'est leur rang dans la liste qui le détermine.
3)
Static = 303,
TrackObj = 305,
Hazard=365
___A quoi correspondent ces valeurs ? Dans SIMIS Editor,

Code : Tout sélectionner

Static >>> 0x0004,0x0003  ( le troisième de la sous-liste),
TrackObj >>> 0x0004,0x0005 (le cinquième),
Hazard >>> 0x0004,0x0041 (le soixante-cinquième)
il semble donc que, dans la liste que tu cites, on ait (en décimal) 300 + le rang dans la sous-liste de la classe 04 ; pourquoi 300 ? dans le document de SIMIS Editor, les tokens de la classe 00 vont jusqu'à 282 ; peut-être la liste que tu cites saute-t-elle de 282 (0x0000,0x011A, terrain_sample_usbuffer) à 300.
___Donc, en théorie, pour convertir Signal = 317 il faut
a} enlever 300 >>> 17
b} le convertir en hexadécimal >>> 11
c} le placer dans la classe 04 >>> 00 04 00 11
d} s'il y a lieu, remettre au format Intel >>> 11 00 04 00.
___Pour les tokens inférieurs à 300, il devrait suffire de convertir le nombre en entier long.
___Tu peux trouver ci-dessous une archive contenant deux fichiers : une liste de la classe 00 et une de la classe 04 ; pour certains mots-clés de cette dernière, il y a deux valeurs différentes ; la liste de SIMIS Editor contient en effet deux mots-clés que je n'ai pas relevés dans Train.exe, et qui décalent la numérotation de deux unités (plus un troisième mot-clé qui n'est pas situé au même endroit dans les deux listes) ; il y a tout lieu de croire que la numérotation de James Ross est la bonne, mais j'ai dû repartir de la mienne pour la mise en forme.
___Bonnes recherches et bonne journée.

Tokens.rar
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.


Retourner vers « Les incontournables »