Spielstand-Speicherung/Anvil Format

Dieser Artikel behandelt das Mapformat. Für den Amboss (engl. Anvil) siehe Amboss.

Das fünfte Datenformat zur Spielstand-Speicherung ist das Anvil Format, das notwendig wurde, um die Bauhöhe von 128 auf 256 Blöcke anzuheben. Außerdem wurde die Speichergeschwindigkeit beschleunigt, indem Luftbereiche nicht mehr gespeichert werden.

Das Anvil Format wurde mit der Vollversion 1.2 (12w07a) eingeführt und verbessert das bisherige Region Format. Das Regionenkonzept und die anderen Daten sind gleich geblieben, nur die Chunkdaten wurden verbessert. Die Chunkdaten im neuen Format können von alten Minecraft-Versionen nicht gelesen werden.

Entwicklung: Region Format Anvil Format

Änderungen

Wie schon im Region Format werden 32×32 Chunks zu einer Regiondatei zusammengefasst, die jetzt die Endung .mca ("Minecraft Anvil") trägt. An den Regiondateien, ihrer Benennung und ihrer internen Struktur hat sich nichts geändert, Details sind weiterhin dem Region Format zu entnehmen. Geändert hat sich dagegen die Struktur der Chunkdaten:

• Ein Chunk wird jetzt in 16 Sektionen geteilt, die jeweils 16×16×16 Blöcke enthalten.
• Alle Daten, die bisher chunkweise gespeichert wurden, werden jetzt sektionsweise gespeichert.
• Komplett mit Luft gefüllte Sektionen werden nicht gespeichert oder geladen. Dadurch können Chunks durchaus weniger als 16 Sektionen enthalten. Chunks in Ebenen, die ungefähr auf Meeresspiegelhöhe liegen, haben z.B. nur 5 oder 6 Sektionen, darüber ist Luft.
• Die Pakete zum Senden von Chunkdaten zwischen Server und Client wurden deutlich verkleinert, was die Datenübertragung beschleunigt.
• Die maximale Block-ID wurde von 256 auf 4096 erhöht durch Hinzufügen der Add-Eigenschaft. Allerdings verwendet das Spiel weiterhin die IDs ab 256 für die Gegenstände. Minecraft-Mods können jedoch in dem Bereich bis 4096 eigene Blöcke definieren.
• Für jede X/Z-Position wird jetzt das Biom gespeichert, sodass es mit Tools leicht und blockgenau verändert werden kann.
• Details zu den Änderungen der Chunkdaten siehe die Information im Mojang-Blog.

Konvertierung

Konvertieren einer Welt vom Region zum Anvil Format

Die einzigen Daten, die sich ändern, sind die Regiondateien. Minecraft Vollversion 1.2 konvertiert (ab 12w07a) alte Regiondateien automatisch in das Anvil Format. Der Weltgenerator wurde nicht geändert, d.h. die Landschaft wird nicht höher, es werden bei der Konvertierung lediglich 128 zusätzliche Blöcke Luft über das bisherige Terrain gelegt.

Konvertierte Dateien erhalten zur Kennzeichnung die neue Endung .mca ("Minecraft Anvil"). Die alten .mcr-Dateien ("Minecraft Region") bleiben zusätzlich erhalten, damit man diese Welt auch noch mit der Vollversion 1.1 (oder älteren Versionen) spielen kann. Wenn man das nicht möchte, kann man die .mcr-Dateien manuell löschen, sie werden ab Vollversion 1.2 nicht mehr benötigt.

Mojang hat auch einen separaten Konverter zur Verfügung gestellt, den man als .zip-Datei hier herunterladen kann. In der .zip-Datei ist auch der Quellcode zur Konvertierung enthalten.

Aufhebung der ID-Begrenzungen und Metadaten

Bereits seit dem Indev Level Format, noch vor Einführung der Chunks, gab es die Metadaten zur Speicherung von Blockzuständen. Der erste Block mit Metadaten war die Fackel, die es in fünf Ausrichtungen (Norden, Süden, Westen, Osten und stehend) gab. Von Anfang an waren die Metadaten auf 4 Bit Speichergröße festgelegt, was 16 verschiedenen Werten entspricht. Daher konnte es nur 16 Wollfarben geben und nicht mehr. Ebenso waren die Block-IDs auf 1 Byte Speichergröße festgelegt, was 256 verschiedenen Blöcken entspricht. Dies wurde auch in den darauf folgenden Speicherformaten bis hin zum aktuellen Anvil Format so beibehalten.

Im Laufe der Zeit zeigten sich aber immer öfter die Nachteile dieser Begrenzungen:

• Schon für den Hebel, der mit Alpha 1.0.1 ins Spiel kam, reichten die Metadaten nicht für alle Möglichkeiten aus: Auf dem Boden (und mit Vollversion 1.3 an der Decke) konnte er längs und quer platziert werden, nicht jedoch an den Wänden. Dafür hätte man 24 Metadaten benötigt (je zwei Ausrichtungen für Decke, Boden und vier Seiten, jeweils aktiviert und deaktiviert).
• Mit Vollversion 1.7 musste man dann erstmals Blöcke notgedrungen verdoppeln, weil die Metadaten für die Darstellung der neuen Holzarten nicht immer ausreichten. Zwar hätte man für die Holzbretter 16 verschiedene Holzarten einführen können, aber bei Stamm und Laub waren nur vier Holzarten möglich, denn sie hatten schon Metadaten für die Ausrichtung bzw. für den Zerfall. Deshalb wurden zu den vorhandenen Block-IDs log und leaves die neuen Blöcke log2 und leaves2 hinzugefügt, um die restlichen zwei Holzarten abbilden zu können.
• Obwohl es bereits zwei Blumen mit verschiedenen Block-IDs gab (37 yellow_flower, 38 red_flower), hat man in Vollversion 1.7, um Block-IDs zu sparen (ID 174 war bereits erreicht), keine neuen Block-IDs, sondern acht neue Metadaten für red_flower vergeben. Das führte allerdings zu Problemen beim Blumentopf: Bisher speicherte er seinen Inhalt in 11 Metadaten. Mit den neuen Blumen und Setzlingen hätte man 21 Metadaten benötigt. Daher wurden die Metadaten des Blumentopfes entfernt und sein Inhalt als Blockobjektdaten gespeichert. Um den in alten Welten eingesetzten Befehl /setblock flower_pot weiterhin funktionsfähig zu halten, wurden in allen 1.7-Versionen zusätzlich die Metadaten der bisherigen 11 Inhalte beibehalten und erst mit Vollversion 1.8 entfernt.
• Mit Vollversion 1.8 kam der rote Sand ins Spiel, aus dem roter Sandstein hergestellt werden konnte. Obwohl dieser bis auf die Farbe identisch zum bisherigen gelben Sandstein war, mussten vier neue Blöcke eingeführt werden (179 red_sandstone, 180 red_sandstone_stairs, 181 double_stone_slab2, 182 stone_slab2 ), weil die Metadaten der bisherigen Blöcke nicht ausreichten, um die neue Farbe mit abzubilden.
• In derselben Version kamen 15 neue Blöcke für Zauntore, Zäune und Türen in anderen Holzarten hinzu, weil die Metadaten der bisherigen Blöcke nicht ausreichten, um verschiedene Holzarten abzubilden.
• Spätestens mit der Vollversion 1.11 muss die Entscheidung gefallen sein, die Metadaten und ID-Begrenzungen aufzuheben, denn für die Shulkerkiste in 16 Farben und die glasierte Keramik in 16 Farben (Vollversion 1.12) wurden insgesamt 32 neue Block-IDs vergeben. Danach waren nur noch zwei Block-IDs frei (253 und 254). Die Vollversion 1.13 musste also etwas an diesem System ändern.

Das neue Speicherkonzept ab Vollversion 1.13 (17w47a) übernimmt aus den seit Vollversion 1.9 existierenden Konstruktionsvorlagen das Prinzip der Blockzustandspalette:

• Für jede Chunk-Sektion wird eine Blockzustandspalette als Liste gespeichert. Standardmäßig steht an erster Stelle der Liste (Index 0) immer Luft, auch wenn die Sektion gar keine Luft enthält. Dann folgen alle unterschiedlichen Blockzustände, die in dieser Sektion vorkommen. Enthält die Sektion z. B. Stein und zwei unterschiedlich ausgerichtete Kürbislaternen, dann stehen in der Palette Luft (Listenindex 0), Stein (Listenindex 1), Kürbislaterne mit Ausrichtung Norden (Listenindex 2) und Kürbislaterne mit Ausrichtung Osten (Listenindex 3).
• Die Palette kann für jede Sektion anders aussehen: Mal kann Stein bei Index 1 stehen, mal bei Index 27, mal kommt er gar nicht vor.
• Zusätzlich zur Palette gibt es einen Index-Array. Dieser enthält exakt 16×16×16 = 4096 Einträge für die 4096 Blöcke der Sektion. Jeder Eintrag ist ein Index auf die zugehörige Blockzustandspalette der Sektion.
• Wenn das Spiel den Block an Position (X, Y, Z) darstellen will, schaut es im Index-Array an die passende Position, erhält den Palettenindex und schaut mit diesem in die Blockzustandspalette. Dort steht die Block-ID und der genaue Zustand dieses Blockes.

Änderungen

• Numerische Block-IDs spielen keine Rolle mehr, sie werden nicht mehr gespeichert. Stattdessen wird der ID-Name in der Palette gespeichert. Die Begrenzung auf 256 Block-IDs entfällt, es kann jetzt beliebig viele Blöcke geben.
• Metadaten spielen keine Rolle mehr, die Blockzustände werden nicht mehr als Metadaten gespeichert. Stattdessen wird der Blockzustand-Name und -Wert in der Palette gespeichert. Es kann jetzt beliebig viele Blockzustände für einen Block geben.

Konvertierung

• Die Regiondateien von Welten, die vor Vollversion 1.13 (17w47a) erzeugt wurden, werden automatisch in das neue Blockspeicherformat konvertiert.