Vous pouvez vous abonner à notre compte Twitter sur lequel sont postés les actualités autour de Minecraft et des liens rapides vers le Wiki 

Format de fichier Région

De Minecraft Wiki
Révision datée du 2 décembre 2014 à 22:06 par IdefixBot (discussion | contributions) (Bot: Ajout de de:Region Format, nl:Regio bestandsformaat, zh:区域文件格式.)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à : navigation, rechercher

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[modifier | modifier le wikicode]

Localisation des fichiers de région[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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 (timestamp)

Données de tronçon[modifier | modifier le wikicode]

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)

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[modifier | modifier le wikicode]

L'écran de conversion des tronçons 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[modifier | modifier le wikicode]