Chunkdaten

Neu mit Version 1.20.3: Datenbaum im NBT-Explorer: "Meine Testwelt" hat einen Ordner region für die Oberwelt, den Nether (in Dim-1) und das Ende (DIM1) mit den jeweiligen Regiondateien. Der Chunk [0,0] ist in Regiondatei r.0.0.mca enthalten. In der Oberwelt hat er 7 von 16 möglichen Chunk-Sektionen, die restlichen sind Luft. In den Chunk-Sektionen stehen die Blöcke in ihren Blockzuständen. Ansonsten enthält der Chunk auch Objekte (Entites), Blockobjekte (Tile Entities) und Blockticks (Tile Ticks).

Chunkdaten speichern die aus Blöcken bestehende Landschaft und die Objekte der Welt in kleinen Abschnitten. Ein solcher Abschnitt (Chunk) ist 16×16 Blöcke groß und 256 Blöcke hoch.

Datenquelle

• .minecraft: Der im Launcher-Profil eingestellte Spielordner (Standard: .minecraft).
  • saves: Alle mit dieser Minecraft-Version generierten Welten.
    • Name des Weltordners: Der Weltordner enthält alle Daten einer Welt. Der Name wird im Menü/Welt erstellen vergeben.
      • DIM1: Die Chunks der Überwelt liegen in der Dimension "Plus 1" (DIM1).
        • region: Alle Regionsdateien des Endes. Sie enthalten die Chunks.
          • r.X.Z.mca: Eine Region-Datei im Ende mit bis zu 1024 Chunks.
            • Chunk [X, Z]: Ein Chunk im Ende.
      • DIM-1: Die Chunks der Unterwelt liegen in der Dimension "Minus 1" (DIM-1).
        • region: Alle Regionsdateien des Nethers. Sie enthalten die Chunks.
          • r.X.Z.mca: Eine Region-Datei im Nether mit bis zu 1024 Chunks.
            • Chunk [X, Z]: Ein Chunk im Nether.
      • region: Alle Regionsdateien der Welt. Sie enthalten die Chunks.
        • r.X.Z.mca: Eine Region-Datei der Oberwelt mit bis zu 1024 Chunks.
          • Chunk [X, Z]: Ein Chunk in der Oberwelt.

Die Chunks sind in Regiondateien zusammengefasst. Eine Regiondatei kann bis zu 32×32 = 1024 Chunks enthalten. Da die Welt chunkweise generiert wird, kann eine Region auch weniger als 1024 Chunks enthalten. Ein Chunk enthält jedoch immer eine vollständige Fläche von 16×16 Blöcken. Zum internen Aufbau einer Regiondatei siehe Region Format#Interner Aufbau.

Jede Region enthält in ihrem Dateinamen einen X- und Z-Index innerhalb der Welt, z.B. "r.4.-1.mca". Das Zentrum der Welt ist der Block mit der Koordinate 0/0. Er liegt in der nordwestlichen Ecke des Chunks 0/0, welcher wiederum in der nordwestlichen Ecke der Region 0/0 liegt (Datei "r.0.0.mca"). Einen Regionindex berechnet man aus der X- bzw. Z-Koordinate wie folgt:

(positive Koordinate / 512) ohne Nachkommastellen
((negative Koordinate + 1) / 512 ) ohne Nachkommastellen - 1

Jeder Chunk enthält in seinem Namen wiederum einen X- und Z-Index innerhalb der Region (zwischen 0 und 31). Um den richtigen Chunk zu einem beliebigen Block zu ermitteln, ist jeweils getrennt für die X- und die Z-Koordinate des Blockes wie folgt zu rechnen:

(Koordinate - Regionindex×512) / 16 ohne Nachkommastellen

Beispiel:

• Koordinate X = 2083, Z = -177
  • X-Regionindex = (2083 / 512) ohne Nachkommastellen = 4
  • Z-Regionindex = ((-177 + 1) / 512) ohne Nachkommastellen - 1 = -1
  • X-Chunkindex = (2083 - 4×512) / 16 ohne Nachkommastellen = 2
  • Z-Chunkindex = (-177 - (-1)×512) / 16 ohne Nachkommastellen = 20
  • Der Dateiname der Region lautet: "r.4.-1.mca"
  • Der Chunkindex innerhalb der Region ist [2,20]

Änderbarkeit

Chunkdaten liegen im NBT-Format vor. Das heißt, diese Daten sind außerhalb des Spiels nur mit einem speziellen NBT-Editor einseh- und änderbar. Im Spiel können sie nicht mit Befehlen geändert werden, sondern sie ändern sich jedes Mal, wenn man einen Block verändert.

Einige Chunkdaten kann man im Spiel auch gar nicht ändern, z.B. das Biom.

Funktionsweise

Chunkdaten werden immer dann erzeugt, wenn sich ein Spieler diesem Teil der Welt zum ersten Mal nähert. Dadurch wächst die Welt, je mehr sie erforscht wird. Gleichzeitig sind aber nur die Chunks in Benutzung, die sich um einen Spieler herum befinden (je nach seiner eingestellten Sichtweite). Die anderen Chunks sind nicht geladen und ruhen. Sie sind in ihrem aktuellen Zustand zum Zeitpunkt des Speicherns eingefroren und werden wieder aufgetaut, wenn sie wieder geladen werden, was der Fall ist, wenn sich ihnen ein Spieler nähert.

Aus diesem Grund ist es zur Zeit nicht möglich, eine Güterlore auf eine lange Reise zu schicken. Denn wenn sie ohne Spielerbegleitung den Bereich der nicht geladenen Chunks erreicht, kann sie nicht weiter fahren.

Ein Chunk wird in zwei Stufen generiert. Zuerst nur grob, d.h. die Landschaft ohne Details. Der Aufwand für die Generierung von Details wird erst investiert, wenn ein Spieler wirklich näher kommt. Chunks hinter dem Horizont, die nie von einem Spieler betreten werden, bleiben undekoriert (siehe TerrainPopulated-Eigenschaft).

Datenstruktur

• Chunk [X, Z]: Ein Chunk. Der X- und Z-Index des Chunks innerhalb der Region ist Teil seines Namens.
  • Level: Alle Chunkdaten.
    • Biomes: Array aus 16×16 Bytes (Sortierung = XZ). Jedes Byte enthält die Biom-ID für einen Block der 16×16 Chunkfläche. Falls diese Eigenschaft nicht existiert, wird sie von Minecraft generiert, wenn der Chunk geladen und gespeichert wird. Wenn ein Wert in den Bytes -1 ist, setzt Minecraft die korrekte Biom-ID automatisch.
    • DataVersion: Die Version-ID der Minecraft-Version, mit der der Chunk zuletzt gespeichert wurde. Bei erneutem Laden des Chunks wird diese Version mit der Version-Eigenschaft der Weltdaten verglichen. Falls der Chunk mit veralteter oder fehlender DataVersion geladen wird, werden veraltete Eigenschaften, auch von Objekten und Blockobjekten, entfernt oder gegebenenfalls umgewandelt und ersetzt.
    • Entities: Liste aller Objekt- und Kreaturdaten des Chunks.
      • Siehe Objektdaten oder Kreaturdaten.
    • HeightMap: Array aus 16×16 Integerzahlen (Achtung: Sortierung = ZX). Jede Zahl gehört zu einer Blocksäule der 16×16 Chunkfläche. Sie speichert die unterste Höhe, auf die das Sonnenlicht mit voller Stärke trifft (also die Oberfläche, über der nur noch Luft ist). Das erhöht die Geschwindigkeit beim Berechnen des Lichts.
    • InhabitedTime: Die Summe aller Ticks, die Spieler in diesem Chunk verbracht haben. Wenn sich mehrere Spieler gleichzeitig in dem Chunk befinden, werden alle ihre Ticks addiert. Dies wird für den regionalen Schwierigkeitsgrad ausgewertet: es erhöht die Wahrscheinlichkeit, dass Monster mit Ausrüstung spawnen, dass diese Ausrüstung verzaubert ist, dass Spinnen Trankeffekte haben, dass Monster gedroppte Gegenstände aufheben können und dass Zombies weitere Zombies spawnen können, wenn sie angegriffen werden. Bei einem Wert ab 3600000 steigt der regionale Schwierigkeitsgrad nicht weiter an. Bei einem Wert von 0 oder kleiner wird die regionale Schwierigkeit auf ein Minimum gesenkt (d.h. wenn der Wert negativ ist, verhält er sich genauso, als ob er Null wäre, bildet jedoch einen entsprechenden Puffer, bis die Null tatsächlich erreicht wird).
    • LastUpdate: Der Tick, wann der Chunk zuletzt gespeichert wurde.
    • LightPopulated: 1 oder 0 (true/false). Wenn true, dann wurde die Beleuchtung schon generiert. Wenn false, muss dies noch durchgeführt werden.
    • Sections: Liste der Chunk-Sektionen (von der Community auch als Sub-Chunks bezeichnet). Eine Chunk-Sektion ist ein würfelförmiges Gebiet von 16×16×16 Block Größe. Chunk-Sektion 0 ist die unterste Sektion eines Chunks, während Chunk-Sektion 15 die oberste ist. Um Speicherplatz zu sparen, werden komplett leere (also mit Luft gefüllte Chunk-Sektionen) nicht gespeichert. Das kann auch ein großer Hohlraum unter der Erde sein.
      • Alle Daten einer Chunk-Sektion.
        • Add: Entfällt mit Version 1.20.3: Optional. Zusätzlichen Block-ID-Daten für Block-IDs, die größer als 255 sind. Pro Block werden nur 4 Bit gespeichert, daher ist der Array (16×16×16) / 2 Bytes groß (Sortierung = YZX). Dieser Wert wird mit der Blocks-Eigenschaft kombiniert, um die endgültige Block-ID zu erhalten, falls diese größer als 255 sein sollte. Die 4 Bit werden 8 Bit nach links verschoben und zum Blocks-Wert addiert. Mit 4 Bit können 16 verschiedene Zahlen dargestellt werden, wodurch die möglichen Block-IDs versechzehnfacht werden: statt 256 ergeben sich 16×256 = 4096 Block-IDs.
        • BlockLight: Array aus (16×16×16) / 2 Bytes (Sortierung = YZX). Die Zahlen speichern, wieviel Licht ein Block ausstrahlt. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des Lichts dargestellt werden. Diese Eigenschaft vermindert die Ladezeit, da das Licht nicht beim Laden neu berechnet werden muss.
        • Blocks: Entfällt mit Version 1.20.3: Array aus 16×16×16 Bytes (Sortierung = YZX). Jedes Byte ist die Block-ID eines Blockes in der Chunk-Sektion. Die endgültige Block-ID ergibt sich durch Kombination mit der Add-Eigenschaft.
        • BlockStates: Neu mit Version 1.20.3: Array aus Long-Zahlen. Eine einzelne Long-Zahl hat keine Bedeutung. Die Gesamtheit aller Long-Zahlen bilden eine Bit-Kette, die stets 16×16×16 Blockzustand-Indexen entspricht (Sortierung = YZX). Die Anzahl der Long-Zahlen im Array gibt vor, aus wievielen Bit ein einzelner Blockzustand-Index besteht: Indexlänge = Länge des BlockState-Arrays × 64 Bit / 4096 Blöcke. Beispiel: Sind 256 Long-Zahlen im Array enthalten, beträgt die Indexlänge 4 Bit. Sind 320 Long-Zahlen im Array enthalten, beträgt die Indexlänge 5 Bit. Bei 832 Long-Zahlen im Array beträgt die Indexlänge 13 Bit.
          Die Position eines Blockzustand-Indexes in der Bit-Kette entspricht genau der YZX-Position des Blockes in der Sektion. Ein Blockzustand-Index ist ein Index auf die Palette-Eigenschaft, also auf einen ganz bestimmten Blockzustand in der Palette (siehe Blockspeicherung im Anvil-Format).
          Maximal kann es 4096 unterschiedliche Blockzustände in einer Sektion geben (d. h. jeder Block der Sektion ist anders). Weil auf jeden Fall immer der Luft-Block in der Palette mit enthalten ist, kann es 4097 unterschiedliche Indexe auf die Palette geben. Zur Speicherung eines Blockzustand-Indexes werden daher maximal 13 Bit benötigt. Aber so viele unterschiedlichen Blockzustände werden extrem selten sein. Die Indexlänge für sämtliche Sektionen einer Welt auf 13 Bit festzulegen, würde viel Speicherplatz verbrauchen, der nur selten benötigt wird. Daher ist die Indexlänge flexibel gestaltet, wobei als Mindestgröße 4 Bit festgelegt sind (das entspricht bis zu 16 unterschiedlichen Blockzuständen in der Sektion).
        • Data: Entfällt mit Version 1.20.3: Array aus (16×16×16) / 2 Bytes (Sortierung = YZX). Jede Zahl speichert die Metadaten des zugehörigen Blockes. Mit 4 Bit können 16 Werte dargestellt werden.
        • SkyLight: Array aus (16×16×16) / 2 Bytes (Sortierung = YZX). Jede Zahl speichert die Menge an Sonnen- oder Mondlicht, das auf den Block trifft. Das macht den Tag/Nacht-Übergang weicher im Vergleich zum Neuberechnen bei jedem Laden. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des Lichts dargestellt werden.
        • Palette: Neu mit Version 1.20.3: Hier werden alle Blockzustand-Kombinationen, die in der Sektion vorkommen, gespeichert (siehe Blockspeicherung im Anvil-Format). Der erste Eintrag (Index 0) ist immer minecraft:air, selbst wenn es in der Sektion keinen Luftblock gibt.
          • Eine Blockzustand-Kombination besteht aus dem ID-Namen des Blockes und einem oder mehreren Blockzuständen, in denen sich dieser Block befindet, z.B. ein nach Norden ausgerichteter (facing:north), ausgefahrener (extended:true) Kolben (name:minecraft:piston):
            • name: ID-Name des Blockes.
            • Properties: Die Blockzustände (nur bei Blöcken, die unterschiedliche Blockzustände haben).
              • Name des Blockzustandes: Wert des Blockzustandes.
        • Y: Y-Index der Chunk-Sektion (Wertebereich: 0 bis 15 von unten nach oben). Nicht vorhandene Chunk-Sektionen sind komplett mit Luft gefüllt.
    • TerrainPopulated: 1 oder 0 (true/false). Wenn true, dann wurden spezielle Landschaftszusätze wie Bäume, Erze, Wasserfälle, Verliesen etc. schon generiert. Wenn false, muss dies noch durchgeführt werden.
    • TileEntities: Liste aller Blockobjekte des Chunks.
      • Siehe Blockobjektdaten.
    • TileTicks: Optional. Liste aller aktiven Blöcke des Chunks. Diese Blöcke warten darauf, ein Blockupdate zu erhalten. Sie werden z.B. für Redstone-Schaltkreise erzeugt, deren Signalverarbeitung weiter laufen soll, für Wasser und Lava die weiterfließen sollen, für gerade platzierten Sand oder Kies, der weiterhin fallen sollen und so weiter. Pflanzen nutzen die Ticks, um eine Uhr in ihren Metadaten hochzuzählen, die ihr Wachstum steuert. Interessant für Ersteller von Abenteuerwelten: Tile-Ticks können genutzt werden, um verschiedene Events nach einer bestimmten Zeit auszulösen. Mit dem Befehl /gamerule randomTickSpeed kann die Häufigkeit von zufälligen Ticks verändert werden (z.B. Pflanzenwachstum).
      • Alle Blocktick-Daten.
        • i: Der ID-Name des betroffenen Blockes.
        • p: Priorität. Wenn mehrere Ticks für einen Block zur selben Zeit fällig werden, wird der Tick mit dem niedrigeren Wert zuerst gestartet.
        • t: Zeit in Ticks, bis das Block Update gestartet werden soll. Kann negativ sein, wenn das Block Update bereits gestartet werden sollte.
        • x: X-Koordinate des betroffenen Blockes.
        • y: Y-Koordinate des betroffenen Blockes.
        • z: Z-Koordinate des betroffenen Blockes.
    • V: Version. Zurzeit immer 1.
    • xPos: X-Index des Chunks innerhalb der Region (Wertebereich: 0 bis 31 von Osten nach Westen).
    • zPos: Z-Index des Chunks innerhalb der Region (Wertebereich: 0 bis 31 von Norden nach Süden).