Modifications : Format de fichier Région

Version du 16 mai 2011 à 16:04

Le contenu ou la traduction de cette page est à vérifier.

La version Bêta 1.3 de Minecraft ajoute une nouvelle façon de stocker les tronçons. Depuis cette version, chaque groupe de 32x32 tronçons est stocké dans un fichier de région plutôt qu'individuellement. On peut dire qu'une région est une partie d'un système de fichiers où l'en-tête est la position de chaque fichier et où le secteur est la taille d'allocation. Ce système est basé sur McRegion, un mod créé par Scaevolus, qui a également développé Optimine. Le format McRegion a été adopté sans modifications majeures, à part l'addition d'une table de date et heure de mise à jour des tronçons. JahKob déclare que ce format est jusqu'à 7 fois plus rapide que le précédent.

Fichiers de région

Localisation des fichiers de région

Les fichiers de région sont localisés dans un sous-dossier du répertoire des mondes appelé "region", et sont nommés selon le format r.x.z.mcr, où x et z sont les coordonnées de la région. Les coordonnées de la région à laquelle appartient un tronçon peuvent être trouvées en prenant les valeurs tronquées des coordonnées du tronçon divisées par 32.

En Java:

int localX = (int)Math.floor((double)chunkX / 32);
int localZ = (int)Math.floor((double)chunkZ / 32);

Par exemple, un tronçon de coordonnées (30, -3) serait dans la région (0, -1), et un tronçon de coordonnées (70, -30) serait dans la région (2, -1).

Structure

Les fichiers de région commencent avec un en-tête de 8 kibioctets contenant des informations sur les tronçons présents dans le fichier de région, la date de leur dernière mise à jour, et leur emplacement. La localisation d'un tronçon de coordonnées (x, z) (en coordonnées de tronçon) dans le fichier de région est stockée à l'octet d'offset 4 * ((x modulo 32) + (z modulo 32) * 32) dans son fichier de région. La date et l'heure de sa dernière mise à jour se trouvent 4096 octets plus loin dans le fichier. Le reste du fichier est constitué de données concernant jusqu'à 1024 tronçons, entrecoupées d'un montant arbitraire d'espace inutilisé.

Octet	0 - 4095	4096 - 8191	8192...
Description	Emplacements (1024 entrées)	Dates/Heures (1024 entrées)	Tronçons et espace non utilisé

Emplacement des tronçons

Les informations d'emplacement sont réparties sur 4 octets, séparés en deux champs : les trois premiers octets sont des offset (de mot de poids fort en tête) dans des secteurs de 4 kibioctets à partir du début du fichier, l'octet restant donnant la longueur du tronçon (également dans des secteurs de 4 kibioctets, arrondis). Les tronçons pèseront toujours moins de 1 mébioctet. Si un tronçon n'est pas présent dans le fichier de région (par exemple, car il n'a pas encore été généré ou migré), les deux champs auront pour valeur 0.

Octet	0	1	2	3
Description	offset			Comptage de secteur

Un tronçon avec un offset de 2 commencera juste après la table des dates et heures.

Date et heure des tronçons

Les entrées dans cette table sont des entiers de mot de poids fort en tête de 4 octets individuels, représentant la date et l'heure de la dernière modification du tronçon.

Octet	0	1	2	3
Description	Date et heure

Données de tronçon

Les données de tronçon commencent avec un champ de mot de poids fort en tête de 4 octets qui indique la longueur exacte des données de tronçon restantes en octets. Les octets suivants indiquent le schéma de compression utilisé pour les données de tronçon et les (longueur - 1) octets restants comprennent les données de tronçon compressées.

Octet	0	1	2	3	4	5...
Description	Longueur (en octets)				Type de compression	Données compressées (longueur - 1 octets)

Il y a actuellement deux schémas de compression définis :

Valeur	Méthode
1	GZip (RFC1952) (inutilisé)
2	Zlib (RFC1950)

Si vous préférez lire les données de tronçon compressée en Zlib avec Deflate (RFC1951), sautez les deux premiers octets et arrêtez les 4 derniers octets avant de décompresser.

Les données décompressées sont au format NBT avec la même structure qu'en version Alpha ; si elles sont compressées avec le schéma de compression 1, les données compressées seraient les mêmes que le contenu d'un fichier de tronçon Alpha présent sur le disque. Notez que les tronçons seront toujours sauvegardés par le client officiel en utilisant le schéma de compression 2.

Migration et level.dat

Convertion — Voilà à quoi ressemble la conversion vers le nouveau format

La version Bêta 1.3 convertit tous les "vieux" tronçons en fichiers de région avant le chargement du monde, plutôt que dynamiquement, au fur et à mesure de leur apparition dans le jeu. Faisant partie de la conversion, le fichier level.dat est également mis à jour, sa propriété TAG_Int("version") (notez la casse) passant à 19132. Cette version introduit également un nouveau champ pour les noms de niveaux, appelé TAG_String("LevelName") ainsi qu'une nouvelle propriété Tag_Byte("Sleeping") dans les TAG_Compounds des joueurs - du fichier level.dat pour les parties en solo ou du fichier [nom du joueur].dat pour les parties en multijoueurs - qui indique si le joueur est couché dans un lit. Sa valeur vaut 1 (vrai) ou 0 (faux).

À part ça, le format du fichier level.dat est identique à son format en version Alpha.

Voir aussi

@@ Ligne 1 : / Ligne 1 : @@
-{{Traduire}}
+{{À vérifier}}
-Minecraft Beta 1.3 introduces a new variation on chunk storage: as of Beta 1.3, each 32x32 group of chunks will be stored in a region file, rather than individually. It could be said that a region is a part of a file system where the header is positions for each file and sector is the allocation size. The system is based on McRegion, a mod by [http://www.minecraftforum.net/memberlist.php?mode=viewprofile&u=60394 Scaevolus], the maker of Optimine. The McRegion format was adopted nearly unchanged, except for the addition of a table of chunk update timestamps. JahKob claims that this format is up to 7 times faster than the previous system.
+La version Bêta 1.3 de Minecraft ajoute une nouvelle façon de stocker les tronçons. Depuis cette version, chaque groupe de 32x32 tronçons est stocké dans un fichier de région plutôt qu'individuellement. On peut dire qu'une région est une partie d'un système de fichiers où l'en-tête est la position de chaque fichier et où le secteur est la taille d'allocation. Ce système est basé sur McRegion, un mod créé par [http://www.minecraftforum.net/memberlist.php?mode=viewprofile&u=60394 Scaevolus], qui a également développé Optimine. Le format McRegion a été adopté sans modifications majeures, à part l'addition d'une table de date et heure de mise à jour des tronçons. JahKob déclare que ce format est jusqu'à 7 fois plus rapide que le précédent.
-== Region Files ==
+== Fichiers de région ==
-=== Region File Location ===
+=== Localisation des fichiers de région ===
-Region files are located in a subfolder of the world directory called "region", and have names in the form <tt>r.''x''.''z''.mcr</tt>, where x and z are the region's coordinates. The coordinates for the region a chunk belongs to can be found by taking the floor of the chunk coordinates divided by 32.
+Les fichiers de région sont localisés dans un sous-dossier du répertoire des mondes appelé "region", et sont nommés selon le format <tt>r.''x''.''z''.mcr</tt>, où x et z sont les coordonnées de la région. Les coordonnées de la région à laquelle  appartient un tronçon peuvent être trouvées en prenant les valeurs tronquées des coordonnées du tronçon divisées par 32.
-In Java:
+En Java:
  int localX = (int)Math.floor((double)chunkX / 32);
  int localZ = (int)Math.floor((double)chunkZ / 32);
-For example, a chunk at (30, -3) would be in region (0, -1), and one at (70, -30) would be at (2, -1).
+Par exemple, un tronçon de coordonnées (30, -3) serait dans la région (0, -1), et un tronçon de coordonnées (70, -30) serait dans la région (2, -1).
 == Structure ==
+Les fichiers de région commencent avec un en-tête de 8 kibioctets contenant des informations sur les tronçons présents dans le fichier de région, la date de leur dernière mise à jour, et leur emplacement.  La localisation d'un tronçon de coordonnées (x, z) (en coordonnées de tronçon) dans le fichier de région est stockée à l'octet d'offset 4 * ((x modulo 32) + (z modulo 32) * 32) dans son fichier de région. La date et l'heure de sa dernière mise à jour se trouvent 4096 octets plus loin dans le fichier. Le reste du fichier est constitué de données concernant jusqu'à 1024 tronçons, entrecoupées d'un montant arbitraire d'espace inutilisé.
-Region files begin with an 8kiB header containing information about which chunks are present in the region file, when they were last updated, and where they can be found. The location in the region file of a chunk at (x, z) (in chunk coordinates) can be found at byte offset 4 * ((x mod 32) + (z mod 32) * 32) in its region file. Its timestamp can be found 4096 bytes later in the file. The remainder of the file consists of data for up to 1024 chunks, interspersed with an arbitrary amount of unused space.
 {|class="wikitable"
-! byte
+! Octet
 ! 0 - 4095
 ! 4096 - 8191
 ! 8192...
 |-
+! Description
-! description
-| locations (1024 entries)
+| Emplacements (1024 entrées)
-| timestamps (1024 entries)
+| Dates/Heures (1024 entrées)
+| Tronçons et espace non utilisé
-| chunks and unused space
 |}
-=== Chunk Location ===
+=== Emplacement des tronçons ===
+Les informations d'emplacement sont réparties sur 4 octets, séparés en deux champs : les trois premiers octets sont des offset (de mot de poids fort en tête) dans des secteurs de 4 kibioctets à partir du début du fichier, l'octet restant donnant la longueur du tronçon (également dans des secteurs de 4 kibioctets, arrondis). Les tronçons pèseront toujours moins de 1 mébioctet. Si un tronçon n'est pas présent dans le fichier de région (par exemple, car il n'a pas encore été généré ou migré), les deux champs auront pour valeur 0.
-Location information for a chunk consists of four bytes split into two fields: the first three bytes are a (big-endian) offset in 4KiB sectors from the start of the file, and a remaining byte which gives the length of the chunk (also in 4KiB sectors, rounded up). Chunks will always be less than 1MiB in size. If a chunk isn't present in the region file (e.g. because it hasn't been generated or migrated yet), both fields will be zero.
 {|class="wikitable"
-! byte
+! Octet
 ! 0
 ! 1
@@ Ligne 38 : / Ligne 38 : @@
 ! 3
 |-
+! Description
-! description
 | colspan="3" | offset
+| Comptage de secteur
-| sector count
 |}
-A chunk with an offset of 2 will begin right after the timestamps table.
+Un tronçon avec un offset de 2 commencera juste après la table des dates et heures.
-=== Chunk Timestamps ===
+=== Date et heure des tronçons ===
+Les entrées dans cette table sont des entiers de mot de poids fort en tête de 4 octets individuels, représentant la date et l'heure de la dernière modification du tronçon.
-The entries in the timestamp table are individual four-byte big-endian integers, representing the last modification time of a chunk.
 {|class="wikitable"
-! byte
+! Octet
 ! 0
 ! 1
@@ Ligne 55 : / Ligne 55 : @@
 ! 3
 |-
+! Description
-! description
-| colspan="4" | timestamp
+| colspan="4" | Date et heure
 |}
-=== Chunk Data ===
+=== Données de tronçon ===
+Les données de tronçon commencent avec un champ de mot de poids fort en tête de 4 octets qui indique la longueur exacte des données de tronçon restantes en octets. Les octets suivants indiquent le schéma de compression utilisé pour les données de tronçon et les (longueur - 1) octets restants comprennent les données de tronçon compressées.
-Chunk data begins with a (big-endian) four-byte length field which indicates the exact length of the remaining chunk data in bytes. The following byte indicates the compression scheme used for chunk data, and the remaining (length-1) bytes are the compressed chunk data.
 {|class="wikitable"
-! byte
+! Octet
 ! 0
 ! 1
@@ Ligne 71 : / Ligne 71 : @@
 ! 5...
 |-
+! Description
-! description
-| colspan="4" | length (in bytes)
+| colspan="4" | Longueur (en octets)
+| Type de compression
-| compression type
+| Données compressées (longueur - 1 octets)
-| compressed data (length-1 bytes)
 |}
-There are currently two defined compression schemes:
+Il y a actuellement deux schémas de compression définis :
 {|class="wikitable"
-! value
+! Valeur
+! Méthode
-! method
 |-
 | 1
-| GZip (RFC1952) (unused in practice)
+| GZip (RFC1952) (inutilisé)
 |-
 | 2
@@ Ligne 90 : / Ligne 90 : @@
 |}
-If you prefer to read Zlib-compressed chunk data with Deflate (RFC1951), just skip the first two bytes and leave off the last 4 bytes before decompressing.
+Si vous préférez lire les données de tronçon compressée en Zlib avec Deflate (RFC1951), sautez les deux premiers octets et arrêtez les 4 derniers octets avant de décompresser.
+Les données décompressées sont au format NBT avec la même structure qu'en [[Format de carte Alpha/Format de fichier de tronçon|version Alpha]] ; si elles sont compressées avec le schéma de compression 1, les données compressées seraient les mêmes que le contenu d'un fichier de tronçon Alpha présent sur le disque.  Notez que les tronçons seront toujours sauvegardés par le client officiel en utilisant le schéma de compression 2.
-The uncompressed data is in NBT format with the same structure [[Alpha Level Format/Chunk File Format|as in alpha]]; if compressed with compression scheme 1, the compressed data would be the same as the on-disk content of an Alpha chunk file. Note that chunks will always be saved using compression scheme 2 by the official client.
-== Migration and level.dat ==
+== Migration et level.dat ==
-[[Fichier:Convertion.png|vignette|What it looks like when converting to the new format.]]
+[[Fichier:Convertion.png|vignette|Voilà à quoi ressemble la conversion vers le nouveau format]]
-Beta 1.3 will convert any "old" chunks into region files before loading the world, rather than incrementally as they are loaded during play. As part of the conversion, <tt>level.dat</tt> will be updated with TAG_Int("version") (note case) set to 19132. Beta 1.3 also introduces a new level name field, TAG_String("LevelName"). There's also introduced new TAG_Byte("Sleeping") in player TAG_Compounds - level.dat in single player, [player name].dat in multiplayer which indicates whether is player in the bed. It has value 1(true) or 0(false).
+La version Bêta 1.3 convertit tous les "vieux" tronçons en fichiers de région avant le chargement du monde, plutôt que dynamiquement, au fur et à mesure de leur apparition dans le jeu. Faisant partie de la conversion, le fichier <tt>level.dat</tt> est également mis à jour, sa propriété TAG_Int("version") (notez la casse) passant à 19132. Cette version introduit également un nouveau champ pour les noms de niveaux, appelé TAG_String("LevelName") ainsi qu'une nouvelle propriété Tag_Byte("Sleeping") dans les TAG_Compounds des joueurs - du fichier level.dat pour les parties en solo ou du fichier [nom du joueur].dat pour les parties en multijoueurs - qui indique si le joueur est couché dans un lit. Sa valeur vaut 1 (vrai) ou 0 (faux).
-The format of <tt>level.dat</tt> is otherwise unchanged from [[Alpha Level Format|alpha]].
+À part ça, le format du fichier <tt>level.dat</tt> est identique à son format en [[Format de carte Alpha|version Alpha]].
 == Voir aussi ==
 * [[Format de carte Alpha]]
 * [[Format de carte Alpha/Format de fichier de tronçon|Format de fichier de tronçon]]
-* [http://mojang.com/2011/02/16/minecraft-save-file-format-in-beta-1-3/ Mojang announcement of new region format]
+* [http://mojang.com/2011/02/16/minecraft-save-file-format-in-beta-1-3/ L'annonce de Mojang sur le nouveau format de région]
-* [http://www.pcgamer.com/2011/02/09/minecraft-dev-diary-new-block-magic-fiddles/ JahKob writing about the speed]
+* [http://www.pcgamer.com/2011/02/09/minecraft-dev-diary-new-block-magic-fiddles/ Précisions de JahKob sur la vitesse]
-* [http://www.minecraftforum.net/viewtopic.php?f=25&t=120160&sid=0d9b129eb5a7a9c81837bf71a7f4b9f9&start=510#p2619453 Jeb_ announcing McRegion being used with minor modifications]
+* [http://www.minecraftforum.net/viewtopic.php?f=25&t=120160&sid=0d9b129eb5a7a9c81837bf71a7f4b9f9&start=510#p2619453 Annonce de Jeb concernant l'utilisation de McRegion après des modifications mineures]
 * [http://www.minecraftforum.net/viewtopic.php?f=25&t=120160 McRegion]
-* [http://www.minecraftforum.net/viewtopic.php?f=25&t=120160&p=1803041#p1803041 Scaevolus according McRegion]
+* [http://www.minecraftforum.net/viewtopic.php?f=25&t=120160&p=1803041#p1803041 Explications de Scaevolus sur McRegion]
-* [http://mojang.com/2011/02/16/minecraft-save-file-format-in-beta-1-3/ Jeb_ helping tool-makers]
+* [http://mojang.com/2011/02/16/minecraft-save-file-format-in-beta-1-3/ Aide de Jeb pour les développeurs de mods]
-* [http://pastebin.com/niWTqLvk RegionFile in Java]
+* [http://pastebin.com/niWTqLvk RegionFile en Java]
-* [http://pastebin.com/jvZ1yhAd RegionFileCache in Java]
+* [http://pastebin.com/jvZ1yhAd RegionFileCache en Java]
 [[Catégorie:Développement]]