Stockage d'acteurs dans Minecraft: BedrockEdition

Minecraft a inspiré de nombreux tiers dans la création d'outils utiles de visualisation et d'édition de fichiers de monde qui existent en dehors du client. Des outils tels que l'éditeur universel Minecraft et MCEdit sont les favoris de la communauté et dépendent du fait de savoir où trouver chaque élément de données de niveau sur le disque dans les fichiers LevelDB. Avec l'amélioration du stockage d'acteurs d'origine vers le stockage d'acteurs récents dans la version 1.18.3, les emplacements dans les fichiers LevelDB où les données des acteurs sont stockées ont changé et ces développeurs tiers doivent en être conscients.

À quoi ressemblaient les données d'acteurs d'origine?

Avant la version 1.18.3, les données d'acteurs étaient stockées par tronçon sous la forme d'un blob de tous les acteurs de ce même tronçon. Cela signifiait que chaque fois qu'un seul acteur changeait, nous:

• collections les données de chaque acteur individuel dans le tronçon
• ajoutions les données de chaque acteur dans un seul tampon/blob
• écrivions ces données groupées dans le tronçon

Pourquoi transférons-nous les données des acteurs?

Le format de stockage des données d'acteur d'origine signifiait que si un acteur d'un tronçon était modifié, vous deviez tous les enregistrer, même si un seul avait réellement changé. Cela entraînait de nombreuses opérations inutiles et faisait de la gestion du transfert d'entités entre les tronçons un système coûteux et peu fiable.

Comment les données des acteurs récents sont-elles stockées sur disque?

Le stockage d'acteurs récents passe au stockage de chaque acteur sous une clé LevelDB individuelle et unique. Cela nous permet d'avoir des opérations de sauvegarde qui n'agissent que sur des acteurs individuels. Cela signifie également qu'il n'y a pas de paire de valeur clé pour tous les acteurs d'un tronçon. En fait, les clés d'acteur individuelles sont séparées dans leur propre espace du reste des données de tronçons et ces derniers n'ont pas de données sur disque faisant référence directement aux acteurs qu'ils contiennent.

Au lieu de cela, nous utilisons les données du tronçon pour générer de manière déterministe une clé unique au tronçon dans laquelle nous stockons un recueil des clés LevelDB pour les acteurs du tronçon. Ces entrées de recueil sont également séparées des données de tronçons non-acteur et de l'espace des clés d'acteur.

Examinons de plus près comment cela apparaît sur le disque:

Espace de clé de tronçons

Sur la gauche du diagramme, nous pouvons voir l'espace de clé de tronçons. Ces clés prennent la forme suivante de clé de tronçons d'origine: <Chunk Position><DimensionID>. Il existe un format de tronçons d'origine très ancien dans lequel il n'y a pas d'identifiant de dimension et il est donc possible de charger un monde très ancien dans lequel les clés de tronçons n'ont pas d'identifiant de dimension. Ils seront enregistrés sous une nouvelle clé avec identifiant de dimension. Il s'agit d'un vieux comportement qui existe toujours.

Ce sont les plus petites clés utilisées en les agençant ensemble de manière contiguë sur le disque. La clé de tronçon est utilisée comme préfixe pour les clés qui stockent toutes les données non-acteur du tronçon. Chaque type de données du tronçon possède son propre identifiant de clé qui est ajouté au préfixe de clé du tronçon.

Identifiants de clé de tronçons de données non acteur

enum class LevelChunkTag : char {
  Data3D = 43,
  Version, // This was moved to the front as needed for the extended heights feature. Old chunks will not have this data.
  Data2D,
  Data2DLegacy,
  SubChunkPrefix,
  LegacyTerrain,
  BlockEntity,
  Entity, // Legacy actor storage which will be deleted from LevelDB upon upgrading the chunk to use modern actor storage
  PendingTicks,
  LegacyBlockExtraData,
  BiomeState,
  FinalizedState,
  ConversionData, // Data that the converter provides that are used at runtime for things like blending
  BorderBlocks,
  HardcodedSpawners,
  RandomTicks,
  CheckSums,
  GenerationSeed,
  GeneratedPreCavesAndCliffsBlending,
  BlendingBiomeHeight,
  LegacyVersion = 118
};

Espace clé du recueil des acteurs

Au milieu, nous avons l'espace de clé de recueil. Chaque clé de recueil prend la forme suivante: dg<Chunk Key>.

• dg est un préfixe codé en dur pour toutes les clés de recueil. Cela force tous les recueils à être contigus sur le disque et augmente la taille de toutes les clés de recueils de sorte qu'elles soient placées avant les données de tronçons non acteur dans LevelDB.

• <Chunk Key> est la même chaîne de clé utilisée par le tronçon auquel les données sont associées.

Espace clé des acteurs

Sur la droite, nous avons l'espace clé des acteurs. Chaque acteur prend la forme suivante: actorpref<ActorUniqueID>.

• actorpref est un préfixe codé en dur utilisé pour toutes les clés d'acteurs. Cela force tous les données d'acteurs à être contigus sur le disque et augmente la taille de toutes les clés d'acteurs de sorte qu'elles soient placées avant les données de tronçons non acteur et les recueils dans LevelDB.

• <ActorUniqueID> est un identifiant unique qui est généré pour chaque acteur lorsqu'il est ajouté au niveau. Cet identifiant est cohérent entre les sessions de jeu et n'est unique que pour ce monde. D'autres acteurs dans d'autres mondes peuvent avoir le même identifiant, mais aucun acteur n'aura le même identifiant dans le même monde.