Änderungen: Chunkdaten

Version vom 19. Oktober 2021, 12:34 Uhr

Dieser Artikel behandelt den Inhalt der Chunks. Für die Information über ständig geladene Chunks siehe Chunkladedaten.

NBT-Chunkdaten — Datenbaum im NBT-Explorer: "Meine Testwelt" hat einen Ordner *region* für die Oberwelt, den Nether (*Dim-1*) und das Ende (*DIM1*) mit den jeweiligen Regiondateien. Der Chunk [0,0] ist in Regiondatei *r.0.0.mca* enthalten. In diesem Beispiel fließt Wasser, daher gibt es *Liquid Ticks*. Der Chunk hat nur zwei von 16 möglichen *Sections*, die restlichen sind Luft (Flachland). In den Chunk-Sektionen stehen die Blöcke in ihren Blockzuständen. Da es eine Komparator-Clock gibt, haben wir auch *Tile Ticks*. Ansonsten enthält der Chunk auch Objekte (*Entites*), Blockobjekte (*Tile Entities*) und Bauwerksdaten (*Structures*).

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

Mit dem Befehl /forceload kann man in jeder Dimension einzelne Chunks oder Chunkbereiche speziell markieren, um sie dauerhaft zu laden. Das wird in den Chunkladedaten gespeichert (siehe dort).

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 mehreren 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 Status-Eigenschaft).

Datenstruktur

Chunk [X, Z]: Ein Chunk. Der X- und Z-Index des Chunks innerhalb der Region ist Teil seines Namens.
- 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^[1].
- Level: Alle Chunkdaten.
  - Biomes: Array aus 16×16 Integer-Zahlen (Sortierung = XZ). Jede Zahl 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 -1 ist, setzt Minecraft die korrekte Biom-ID automatisch.
  - CarvingMasks: Optional: Informationen zur Landschaftsmodellierung für den Weltgenerator.
    - AIR: Luft.
    - LIQUID: Flüssigkeiten (Wasser, Lava).
  - Entities: Liste aller Objekt- und Kreaturdaten des Chunks.
    - Siehe Objektdaten oder Kreaturdaten.
  - Heightmaps: Optional: Verschiedene Höhenkarten, die - wenn sie vorhanden sind - das Rendern beschleunigen. Jede Höhenkarte enthält 36 Long-Zahlen, die aber als solche keine Bedeutung haben. Vielmehr geht es um die Bits. Da eine Long-Zahl durch 64 Bit dargestellt wird, enthält jede Höhenkarte 36×64=2304 Bit. Für jeden der 16×16=256 Blöcke einer Chunk-Grundfläche stehen also 9 Bit zur Verfügung.
    - LIGHT_BLOCKING: Höhenkarte für das Himmelslicht.
    - MOTION_BLOCKING: Höhenkarte für Bewegung.
    - MOTION_BLOCKING_NO_LEAVES: Höhenkarte für Bewegung ohne Beachtung der Blätter.
    - OCEAN_FLOOR: Höhenkarte für den Ozeanboden.
    - OCEAN_FLOOR_WG: Höhenkarte für den Ozeanboden bei der Weltgenerierung.
    - WORLD_SURFACE: Höhenkarte für die Landschaftsoberfläche.
    - WORLD_SURFACE_WG: Höhenkarte für die Landschaftsoberfläche bei der Weltgenerierung.
  - 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.
  - LiquidTicks: Optional: Wasser oder Lava haben einen Flüssigkeit-Tick angefordert, aber das Spiel wurde angehalten, bevor er erfolgen konnte. Sobald die Flüssigkeit ihren Tick bekommt, löst sie für sich ein Blockupdate aus, um zu fließen.
    - Alle angeforderten, aber noch nicht ausgeführten Flüssigkeit-Ticks.
      - i: Der ID-Name der betroffenen Flüssigkeit.
      - p: Priorität. Wenn mehrere Flüssigkeit-Ticks für eine Flüssigkeit zur selben Zeit fällig werden, wird der mit dem niedrigeren Wert zuerst gestartet.
      - t: Zeit in Ticks, bis wann der angeforderte Flüssigkeit-Tick erfolgen soll. Kann negativ sein, wenn er bereits erfolgt sein sollte.
      - x: X-Koordinate des betroffenen Blockes.
      - y: Y-Koordinate des betroffenen Blockes.
      - z: Z-Koordinate des betroffenen Blockes.
  - LiquidsToBeTicked: Liste von 16 Listen für die Tick-Berechnung von Flüssigkeiten. In den meisten Fällen sind alle 16 Listen leer. Wird das Spiel jedoch in der Tick-Berechnung unterbrochen, kann jede der 16 Listen Werte enthalten, um die Berechnung bei Fortführung des Spiels beenden zu können.
  - PostProcessing: Liste von 16 Listen für die Chunk-Generierung. Ist diese abgeschlossen (Status = "postprocessed"), sind alle 16 Listen leer. Wird das Spiel jedoch im Generierungsvorgang unterbrochen, kann jede Liste eine Reihe von Short-Werten enthalten, die eine Bedeutung für den jeweiligen Generierungsschritt (siehe Status) haben. Sobald das Spiel fortgesetzt wird, wird die Generierung des Chunks mit diesen Werten zu Ende geführt.
  - 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 das Speichern und Laden der Chunks zu beschleunigen, 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.
      - BlockLight: Array aus (16×16×16) / 2 Bytes (Sortierung = XZY). Die Zahlen speichern, wie viel Licht ein Block ausstrahlt. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des Lichts dargestellt werden.
      - BlockStates: 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 = XZY). 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 XZY-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).
      - SkyLight: Array aus (16×16×16) / 2 Bytes (Sortierung = XZY). Jede Zahl speichert die Menge an Sonnen- oder Mondlicht, das auf den Block trifft. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des Lichts dargestellt werden.
      - Palette: 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.
  - Status: Generierungsstatus des Chunks: empty, base, carved, liquid_carved, decorated, lighted, mobs_spawned, finalized, fullchunk, postprocessed.
  - Structures: Liste aller Bauwerke des Chunks
    - Siehe Bauwerksdaten.
  - TileEntities: Liste aller Blockobjekte des Chunks.
    - Siehe Blockobjektdaten.
  - TileTicks: Optional: Diese Blöcke haben einen Block-Tick angefordert, aber das Spiel wurde angehalten, bevor er erfolgen konnte. Sobald der Block seinen Tick bekommt, löst er für sich ein Blockupdate aus.
    - Alle angeforderten, aber noch nicht ausgeführten Block-Ticks.
      - i: Der ID-Name des betroffenen Blockes.
      - p: Priorität. Wenn mehrere Block-Ticks für einen Block zur selben Zeit fällig werden, wird das mit dem niedrigeren Wert zuerst gestartet.
      - t: Zeit in Ticks, bis wann der angeforderte Block-Tick erfolgen soll. Kann negativ sein, wenn er bereits erfolgt sein sollte.
      - x: X-Koordinate des betroffenen Blockes.
      - y: Y-Koordinate des betroffenen Blockes.
      - z: Z-Koordinate des betroffenen Blockes.
  - ToBeTicked: Liste von 16 Listen für die Tick-Berechnung. In den meisten Fällen sind alle 16 Listen leer. Wird das Spiel jedoch in der Tick-Berechnung unterbrochen, kann jede der 16 Listen Werte enthalten, um die Berechnung bei Fortführung des Spiels beenden zu können.
  - xPos: X-Index des Chunks innerhalb der Welt.
  - zPos: Z-Index des Chunks innerhalb der Welt.

Geschichte

Versionsgeschichte der Java Edition

Classic 0.0.11a

Erste Veröffentlichung des Spiels, es wird im kreativen Einzelspielermodus im Webbrowser gespielt.
Der Spielstand mit den Blockdaten kann aber noch nicht gespeichert werden.

Classic 0.0.13a_02

Die erste Datenspeicherung ist möglich, Spieler mit Account können den Spielstand nun online speichern.

Classic 0.0.14a

Kreaturdaten werden dem Spielstand als erste Objektdaten hinzugefügt.

Classic 0.0.16a

Veröffentlichung des Mehrspielermodus, der Spielstand wird als Datei server_level.dat gespeichert und enthält die Block- und Objektdaten.

Indev 22. Januar 2010

Der Spielstand wird jetzt unter Nutzung des NBT-Formates im Indev Level Format gespeichert.

Infdev

27. Februar 2010	Die Entwicklung grenzenloser Welten beginnt, die Welt wird in Chunks aufgeteilt. Die Blöcke und Objekte gehören nicht mehr zu den Weltdaten, sondern werden als Chunkdaten separat gespeichert (Alpha Level Format). Es gibt pro Welt maximal 64×64 Verzeichnisse für die Speicherung der einzelnen Chunkdateien.
24. Juni 2010	Weil die Speicherung der Chunkdateien zu langsam ist, wird ein neues Zonenformat veröffentlicht^[2].^[3].
25. Juni 2010	Das Zonenformat ist zu fehlerhaft und wird wieder entfernt^[4].

Beta 1.3

Das neue Region Format kann die Chunkdateien deutlich schneller speichern und löst das Alpha Level Format ab.
Bis zu 32×32 Chunks werden in einer Regiondatei zusammengefasst, alle Regiondateien stehen im /region-Ordner.

Vollversion 1.2 (12w07a)

Die Chunkdaten werden erweitert, das neue Speicherformat heißt Anvil Format.
Die Bauhöhe wird von 128 auf 256 erhöht.
Die Chunks werden in 16 Chunk-Sektionen eingeteilt, Luft-Sektionen werden nicht mehr gespeichert.
Es können 4096 statt 256 Block-IDs verwendet werden.

Vollversion 1.9 (15w32a)

Die Version-ID wird in den Weltdaten, Spielerdaten und Chunkdaten gespeichert, um einen Versionswechsel zu erkennen und die Datenkonvertierung leicht durchführen zu können.

Vollversion 1.13

17w47a	Numerische Block-IDs werden nicht mehr gespeichert, sondern die ID-Namen der Blöcke in einer Palette-Liste. Metadaten werden nicht mehr gespeichert, sondern die Blockzustände in der Palette-Liste. Für jede XYZ-Position eines Blocks wird ein Index auf die Palette-Liste gespeichert.
18w06a	Mit Umstellung der Weltgenerierung werden die Bauwerksdaten in die Chunkdaten integriert.
18w16a	Trennung zwischen Block-Ticks und Flüssigkeit-Ticks.

Vollversion 1.13.1

18w31a	Der neue Befehl `/chunk` kann dauerhafte Chunks einstellen, das wird in den Chunkladedaten gespeichert.
1.13.1-pre1	Der Befehl `/chunk` wird in `/forceload` umbenannt.

Vollversion 1.18

21w39a	Die interne Container-Struktur wird geändert und angepasst.
21w41a	Die Priorisierungsreihenfolge der Chunk-Render-Pipeline wird geändert.

Einzelnachweise

↑ All about the DataVersion tag: Genaue Beschreibung der DataVersion Eigenschaft.
↑ http://notch.tumblr.com/post/697022652/a-gentle-warning-about-infdev-saves-breaking
↑ http://notch.tumblr.com/post/722369319/your-saves-are-safe
↑ http://notch.tumblr.com/post/734055276/i-reverted-back-to-the-old-save-file-format

[DataVersionPlayer-1] All about the DataVersion tag: Genaue Beschreibung der DataVersion Eigenschaft.

[2] ttp://notch.tumblr.com/post/697022652/a-gentle-warning-about-infdev-saves-breaking

[3] ttp://notch.tumblr.com/post/722369319/your-saves-are-safe

[4] ttp://notch.tumblr.com/post/734055276/i-reverted-back-to-the-old-save-file-format

[1]

[2]

[3]

[4]

@@ Zeile 1: / Zeile 1: @@
+{{Diese Seite|den Inhalt der Chunks|die Information über ständig geladene Chunks|Chunkladedaten}}
-[[Datei:NBT-Chunkdaten.png|thumb|358px|right|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. Ansonsten enthält der Chunk auch Objekte (''Entites''), Blockobjekte (''Tile Entities'') und Blockticks (''Tile Ticks'').]]
+[[Datei:NBT-Chunkdaten.png|thumb|420px|right|Datenbaum im NBT-Explorer: "Meine Testwelt" hat einen Ordner ''region'' für die Oberwelt, den Nether (''Dim-1'') und das Ende (''DIM1'') mit den jeweiligen Regiondateien. Der Chunk [0,0] ist in Regiondatei ''r.0.0.mca'' enthalten. In diesem Beispiel fließt Wasser, daher gibt es ''Liquid Ticks''. Der Chunk hat nur zwei von 16 möglichen ''Sections'', die restlichen sind Luft ([[Flachland]]). In den Chunk-Sektionen stehen die Blöcke in ihren Blockzuständen. Da es eine [[Komparator]]-Clock gibt, haben wir auch ''Tile Ticks''. Ansonsten enthält der Chunk auch [[Objektdaten|Objekte]] (''Entites''), [[Blockobjektdaten|Blockobjekte]] (''Tile Entities'') und [[Bauwerksdaten]] (''Structures'').]]
-'''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.
+'''Chunkdaten''' speichern die aus Blöcken bestehende Landschaft und die Objekte der Welt in kleinen Abschnitten. Ein solcher Abschnitt wird [[Chunk]] genannt und ist 16×16 Blöcke groß und 256 Blöcke hoch.
+Mit dem {{b|/forceload}} kann man in jeder Dimension einzelne Chunks oder Chunkbereiche speziell markieren, um sie dauerhaft zu laden. Das wird in den [[Chunkladedaten]] gespeichert (siehe dort).
 == Datenquelle ==
@@ Zeile 39: / Zeile 42: @@
 == Änderbarkeit ==
-Chunkdaten liegen im [[NBT-Format]] vor. Das heißt, diese Daten sind außerhalb des Spiels nur mit einem speziellen [[Programme und Editoren/Spezielle Programme|NBT-Editor]] einseh- und änderbar. Im Spiel können sie nicht mit [[Befehl]]en geändert werden, sondern sie ändern sich jedes Mal, wenn man einen Block verändert.
+Chunkdaten liegen im [[NBT]]-Format vor. Das heißt, diese Daten sind außerhalb des Spiels nur mit einem speziellen [[Programme und Editoren/Spezielle Programme|NBT-Editor]] einseh- und änderbar. Im Spiel können sie nicht mit [[Befehl]]en 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.
@@ Zeile 48: / Zeile 51: @@
 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).
+Ein Chunk wird in mehreren 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 ''Status''-Eigenschaft).
 == Datenstruktur ==
 <div class="treeview">
 * {{NBT|compound|Chunk [''X, Z'']:}} Ein Chunk. Der X- und Z-Index des Chunks innerhalb der Region ist Teil seines Namens.
+** {{NBT|int|DataVersion:}} Die [[Versionen#Version-IDs|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<ref name="DataVersionPlayer">[https://www.reddit.com/r/MinecraftCommands/comments/3gsx1r/all_about_the_dataversion_tag All about the DataVersion tag]: Genaue Beschreibung der ''DataVersion'' Eigenschaft.</ref>.
 ** {{NBT|compound|Level:}} Alle Chunkdaten.
-*** {{NBT|byte-array|Biomes:}} Array aus 16×16 Bytes ([[NBT-Format#Array-Sortierung|Sortierung = XZ]]). Jedes Byte enthält die [[Datenwert#Biom-IDs|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.
+*** {{NBT|int-array|Biomes:}} Array aus 16×16 Integer-Zahlen ([[NBT#Array-Sortierung|Sortierung = XZ]]). Jede Zahl enthält die [[Biom#Biom-IDs|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 -1 ist, setzt Minecraft die korrekte Biom-ID automatisch.
+*** {{NBT|compound|CarvingMasks:}} Optional: Informationen zur Landschaftsmodellierung für den Weltgenerator.
-*** {{NBT|int|DataVersion:}} Die [[Datenwert#Version-ID|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<ref name="DataVersionPlayer">[https://www.reddit.com/r/MinecraftCommands/comments/3gsx1r/all_about_the_dataversion_tag All about the DataVersion tag]: Genaue Beschreibung der ''DataVersion'' Eigenschaft.</ref>.
+**** {{NBT|int-array|AIR:}} Luft.
+**** {{NBT|int-array|LIQUID:}} Flüssigkeiten (Wasser, Lava).
 *** {{NBT|list|Entities:}} Liste aller Objekt- und Kreaturdaten des Chunks.
 **** Siehe [[Objektdaten]] oder [[Kreaturdaten]].
+*** {{NBT|compound|Heightmaps:}} Optional: Verschiedene Höhenkarten, die - wenn sie vorhanden sind - das Rendern beschleunigen. Jede Höhenkarte enthält 36 Long-Zahlen, die aber als solche keine Bedeutung haben. Vielmehr geht es um die Bits. Da eine Long-Zahl durch 64 Bit dargestellt wird, enthält jede Höhenkarte 36×64=2304 Bit. Für jeden der 16×16=256 Blöcke einer Chunk-Grundfläche stehen also 9 Bit zur Verfügung.
-*** {{NBT|int-array|HeightMap:}} Array aus 16×16 Integerzahlen (Achtung: [[NBT-Format#Array-Sortierung|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.
+**** {{NBT|long-array|LIGHT_BLOCKING:}} Höhenkarte für das Himmelslicht.
+**** {{NBT|long-array|MOTION_BLOCKING:}} Höhenkarte für Bewegung.
+**** {{NBT|long-array|MOTION_BLOCKING_NO_LEAVES:}} Höhenkarte für Bewegung ohne Beachtung der Blätter.
+**** {{NBT|long-array|OCEAN_FLOOR:}} Höhenkarte für den Ozeanboden.
+**** {{NBT|long-array|OCEAN_FLOOR_WG:}} Höhenkarte für den Ozeanboden bei der Weltgenerierung.
+**** {{NBT|long-array|WORLD_SURFACE:}} Höhenkarte für die Landschaftsoberfläche.
+**** {{NBT|long-array|WORLD_SURFACE_WG:}} Höhenkarte für die Landschaftsoberfläche bei der Weltgenerierung.
 *** {{NBT|long|InhabitedTime:}} Die Summe aller [[Tick]]s, 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).
 *** {{NBT|long|LastUpdate:}} Der [[Tick]], wann der Chunk zuletzt gespeichert wurde.
+*** {{NBT|list|LiquidTicks:}} Optional: [[Wasser]] oder [[Lava]] haben einen [[Tick#Angeforderte Flüssigkeit-Ticks|Flüssigkeit-Tick angefordert]], aber das Spiel wurde angehalten, bevor er erfolgen konnte. Sobald die Flüssigkeit ihren Tick bekommt, löst sie für sich ein [[Blockupdate]] aus, um zu fließen.
-*** {{NBT|byte|LightPopulated:}} 1 oder 0 (true/false). Wenn true, dann wurde die Beleuchtung schon generiert. Wenn false, muss dies noch durchgeführt werden.
+**** {{NBT|compound}} Alle angeforderten, aber noch nicht ausgeführten Flüssigkeit-Ticks.
-*** {{NBT|list|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.
+***** {{NBT|string|i:}} Der [[Block#ID-Namen|ID-Name]] der betroffenen Flüssigkeit.
+***** {{NBT|int|p:}} Priorität. Wenn mehrere Flüssigkeit-Ticks für eine Flüssigkeit zur selben Zeit fällig werden, wird der mit dem niedrigeren Wert zuerst gestartet.
+***** {{NBT|int|t:}} Zeit in Ticks, bis wann der angeforderte Flüssigkeit-Tick erfolgen soll. Kann negativ sein, wenn er bereits erfolgt sein sollte.
+***** {{NBT|int|x:}} X-Koordinate des betroffenen Blockes.
+***** {{NBT|int|y:}} Y-Koordinate des betroffenen Blockes.
+***** {{NBT|int|z:}} Z-Koordinate des betroffenen Blockes.
+*** {{NBT|list|LiquidsToBeTicked:}} Liste von 16 Listen für die [[Tick]]-Berechnung von Flüssigkeiten. In den meisten Fällen sind alle 16 Listen leer. Wird das Spiel jedoch in der Tick-Berechnung unterbrochen, kann jede der 16 Listen Werte enthalten, um die Berechnung bei Fortführung des Spiels beenden zu können.
+*** {{NBT|list|PostProcessing:}} Liste von 16 Listen für die Chunk-Generierung. Ist diese abgeschlossen (''Status'' = "postprocessed"), sind alle 16 Listen leer. Wird das Spiel jedoch im Generierungsvorgang unterbrochen, kann jede Liste eine Reihe von Short-Werten enthalten, die eine Bedeutung für den jeweiligen Generierungsschritt (siehe ''Status'') haben. Sobald das Spiel fortgesetzt wird, wird die Generierung des Chunks mit diesen Werten zu Ende geführt.
+*** {{NBT|list|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 das Speichern und Laden der Chunks zu beschleunigen, werden komplett leere (also mit Luft gefüllte Chunk-Sektionen) nicht gespeichert. Das kann auch ein großer Hohlraum unter der Erde sein.
 **** {{NBT|compound}} Alle Daten einer Chunk-Sektion.
-***** {{NBT|byte-array|Add:}} {{ä|e}} 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ß ([[NBT-Format#Array-Sortierung|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.
+***** {{NBT|byte-array|BlockLight:}} Array aus (16×16×16) / 2 Bytes ([[NBT#Array-Sortierung|Sortierung = XZY]]). Die Zahlen speichern, wie viel Licht ein Block ausstrahlt. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des [[Licht]]s dargestellt werden.
+***** {{NBT|long-array|BlockStates:}} 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 ([[NBT#Array-Sortierung|Sortierung = XZY]]). 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.<br>Die Position eines Blockzustand-Indexes in der Bit-Kette entspricht genau der XZY-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 [[Spielstand-Speicherung/Anvil Format#Aufhebung der ID-Begrenzungen und Metadaten|Blockspeicherung im Anvil-Format]]).<br>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).
-***** {{NBT|byte-array|BlockLight:}} Array aus (16×16×16) / 2 Bytes ([[NBT-Format#Array-Sortierung|Sortierung = YZX]]). Die Zahlen speichern, wieviel Licht ein Block ausstrahlt. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des [[Licht]]s dargestellt werden. Diese Eigenschaft vermindert die Ladezeit, da das Licht nicht beim Laden neu berechnet werden muss.
-***** {{NBT|byte-array|Blocks:}} {{ä|e}} Array aus 16×16×16 Bytes ([[NBT-Format#Array-Sortierung|Sortierung = YZX]]). Jedes Byte ist die [[Datenwerte#Block-IDs|Block-ID]] eines Blockes in der Chunk-Sektion. Die endgültige Block-ID ergibt sich durch Kombination mit der ''Add''-Eigenschaft.
+***** {{NBT|byte-array|SkyLight:}} Array aus (16×16×16) / 2 Bytes ([[NBT#Array-Sortierung|Sortierung = XZY]]). Jede Zahl speichert die Menge an Sonnen- oder Mondlicht, das auf den Block trifft. Mit 4 Bit können die 16 verschiedenen Helligkeitswerte des [[Licht]]s dargestellt werden.
+***** {{NBT|list|Palette:}} Hier werden alle Blockzustand-Kombinationen, die in der Sektion vorkommen, gespeichert (siehe [[Spielstand-Speicherung/Anvil Format#Aufhebung der ID-Begrenzungen und Metadaten|Blockspeicherung im Anvil-Format]]). Der erste Eintrag (Index 0) ist immer ''minecraft:air'', selbst wenn es in der Sektion keinen Luftblock gibt.
-***** {{NBT|long-array|BlockStates:}} {{ä|n}} Array aus 16×16×16 Blockzustand-Indexen. Die Position im Array entspricht der XYZ-Position des Blockes in der Sektion. Ein einzelner Wert im Array ist ein Index auf die ''Palette''-Eigenschaft, also auf einen ganz bestimmten Blockzustand (siehe [[Spielstand-Speicherung/Anvil Format#Aufhebung der ID-Begrenzungen und Metadaten|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 Index werden daher maximal 13 Bit benötigt. Aber so viele unterschiedlichen Blockzustände werden extrem selten sein. Das Maximum von 13 Bit für jeden Index als Standard festzulegen, würde viel Speicherplatz verbrauchen, der nur selten benötigt wird. Daher ist die Bit-Länge flexibel gestaltet, wobei als Mindestgröße 4 Bit festgelegt sind (das entspricht bis zu 16 unterschiedlichen Blockzuständen in der Sektion). Gespeichert werden die Bits in einem Long-Array. Jede Long-Zahl besteht aus 64 Bit. Die Long-Zahlen selbst haben keine Bedeutung, nur ihre Bits sind wichtig. Die Bitgröße, die für die Indexe einer Sektion verwendet wird, berechnet sich wie folgt: 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.
-***** {{NBT|byte-array|Data:}} {{ä|e}} Array aus (16×16×16) / 2 Bytes ([[NBT-Format#Array-Sortierung|Sortierung = YZX]]). Jede Zahl speichert die [[Metadaten]] des zugehörigen Blockes. Mit 4 Bit können 16 Werte dargestellt werden.
-***** {{NBT|byte-array|SkyLight:}} Array aus (16×16×16) / 2 Bytes ([[NBT-Format#Array-Sortierung|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 [[Licht]]s dargestellt werden.
-***** {{NBT|list|Palette:}} {{ä|n}} Hier werden alle Blockzustand-Kombinationen, die in der Sektion vorkommen, gespeichert (siehe [[Spielstand-Speicherung/Anvil Format#Aufhebung der ID-Begrenzungen und Metadaten|Blockspeicherung im Anvil-Format]]). Der erste Eintrag ist immer ''minecraft:air'', selbst wenn es in der Sektion keinen Luftblock gibt.
 ****** {{NBT|compound}} 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''):
-******* {{NBT|string|name:}} [[Datenwert#Block-IDs|ID-Name]] des Blockes.
+******* {{NBT|string|Name:}} [[Block#ID-Namen|ID-Name]] des Blockes.
-******* {{NBT|compound|Properties:}} Die Blockzustände (nur bei Blöcken, die unterschiedliche Blockzustände haben).
+******* {{NBT|compound|Properties:}} Die [[Blockzustand|Blockzustände]] (nur bei Blöcken, die unterschiedliche Blockzustände haben).
 ******** {{NBT|string|''Name des Blockzustandes'':}} Wert des Blockzustandes.
 ***** {{NBT|byte|Y:}} Y-Index der Chunk-Sektion (Wertebereich: 0 bis 15 von unten nach oben). Nicht vorhandene Chunk-Sektionen sind komplett mit Luft gefüllt.
+*** {{NBT|string|Status:}} Generierungsstatus des Chunks: empty, base, carved, liquid_carved, decorated, lighted, mobs_spawned, finalized, fullchunk, postprocessed.
-*** {{NBT|byte|TerrainPopulated:}} 1 oder 0 (true/false). Wenn true, dann wurden spezielle Landschaftszusätze wie [[Baum|Bäume]], [[Erz]]e, [[Wasser]]fälle, [[Verlies]]en etc. schon generiert. Wenn false, muss dies noch durchgeführt werden.
+*** {{NBT|compound|Structures:}} Liste aller Bauwerke des Chunks
+**** Siehe [[Bauwerksdaten]].
 *** {{NBT|list|TileEntities:}} Liste aller Blockobjekte des Chunks.
 **** Siehe [[Blockobjektdaten]].
+*** {{NBT|list|TileTicks:}} Optional: Diese Blöcke haben einen [[Tick#Angeforderte Block-Ticks|Block-Tick angefordert]], aber das Spiel wurde angehalten, bevor er erfolgen konnte. Sobald der Block seinen Tick bekommt, löst er für sich ein [[Blockupdate]] aus.
-*** {{NBT|list|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 [[Abenteuerwelt]]en: Tile-Ticks können genutzt werden, um verschiedene Events nach einer bestimmten Zeit auszulösen. Mit dem {{b|/gamerule randomTickSpeed}} kann die Häufigkeit von zufälligen Ticks verändert werden (z.B. Pflanzenwachstum).
-**** {{NBT|compound}} Alle Blocktick-Daten.
+**** {{NBT|compound}} Alle angeforderten, aber noch nicht ausgeführten Block-Ticks.
-***** {{NBT|string|i:}} Der [[Datenwerte#Block-IDs|ID-Name]] des betroffenen Blockes.
+***** {{NBT|string|i:}} Der [[Block#ID-Namen|ID-Name]] des betroffenen Blockes.
-***** {{NBT|int|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.
+***** {{NBT|int|p:}} Priorität. Wenn mehrere Block-Ticks für einen Block zur selben Zeit fällig werden, wird das mit dem niedrigeren Wert zuerst gestartet.
-***** {{NBT|int|t:}} Zeit in Ticks, bis das Block Update gestartet werden soll. Kann negativ sein, wenn das Block Update bereits gestartet werden sollte.
+***** {{NBT|int|t:}} Zeit in Ticks, bis wann der angeforderte Block-Tick erfolgen soll. Kann negativ sein, wenn er bereits erfolgt sein sollte.
 ***** {{NBT|int|x:}} X-Koordinate des betroffenen Blockes.
 ***** {{NBT|int|y:}} Y-Koordinate des betroffenen Blockes.
 ***** {{NBT|int|z:}} Z-Koordinate des betroffenen Blockes.
+*** {{NBT|list|ToBeTicked:}} Liste von 16 Listen für die [[Tick]]-Berechnung. In den meisten Fällen sind alle 16 Listen leer. Wird das Spiel jedoch in der [[Tick]]-Berechnung unterbrochen, kann jede der 16 Listen Werte enthalten, um die Berechnung bei Fortführung des Spiels beenden zu können.
-*** {{NBT|byte|V:}} Version. Zurzeit immer 1.
-*** {{NBT|int|xPos:}} X-Index des Chunks innerhalb der Region (Wertebereich: 0 bis 31 von Osten nach Westen).
+*** {{NBT|int|xPos:}} X-Index des Chunks innerhalb der Welt.
-*** {{NBT|int|zPos:}} Z-Index des Chunks innerhalb der Region (Wertebereich: 0 bis 31 von Norden nach Süden).
+*** {{NBT|int|zPos:}} Z-Index des Chunks innerhalb der Welt.
 </div>
@@ Zeile 95: / Zeile 116: @@
 {{Geschichtlich
 |group1= {{ver|Classic|0.0.11a}}
-|list1= *Erste Veröffentlichung des Spiels, es wird im kreativen Einzelspielermodus im Webbrowser gespielt
+|list1= *Erste Veröffentlichung des Spiels, es wird im kreativen Einzelspielermodus im Webbrowser gespielt.
-*Der Spielstand mit den Blockdaten kann aber noch nicht gespeichert werden
+*Der Spielstand mit den Blockdaten kann aber noch nicht gespeichert werden.
 |group2= {{ver|Classic|0.0.13a_02}}
-|list2= *Die erste Datenspeicherung ist möglich, Spieler mit [[Account]] können den Spielstand nun online speichern
+|list2= *Die erste Datenspeicherung ist möglich, Spieler mit [[Account]] können den Spielstand nun online speichern.
 |group3= {{ver|Classic|0.0.14a}}
-|list3= *[[Kreaturdaten]] werden dem Spielstand als erste Objektdaten hinzugefügt
+|list3= *[[Kreaturdaten]] werden dem Spielstand als erste Objektdaten hinzugefügt.
 |group4= {{ver|Classic|0.0.16a}}
-|list4= *Veröffentlichung des Mehrspielermodus, der Spielstand wird als Datei ''server_level.dat'' gespeichert und enthält die Block- und Objektdaten
+|list4= *Veröffentlichung des Mehrspielermodus, der Spielstand wird als Datei ''server_level.dat'' gespeichert und enthält die Block- und Objektdaten.
-|group5= {{ver|Indev|0.31|22. Januar 2010}}
+|group5= {{ver|Indev|22. Januar 2010}}
-|list5= *Der Spielstand wird jetzt unter Nutzung des [[NBT-Format]]es im [[Indev Level Format]] gespeichert
+|list5= *Der Spielstand wird jetzt unter Nutzung des [[NBT]]-Formates im [[Indev Level Format]] gespeichert.
-|group6= {{ver|Infdev|0.33|27. Februar 2010}}
+|group6= {{ver|Infdev}}
+|list6=
-|list6= *Die Entwicklung grenzenloser Welten beginnt, die Welt wird in [[Chunk]]s aufgeteilt
+{{Geschichtlich
-*Die Blöcke und Objekte gehören nicht mehr zu den Weltdaten, sondern werden als [[Chunkdaten]] separat gespeichert ([[Alpha Level Format]])
+|untergruppe=1
-*Es gibt pro Welt maximal 64×64 Verzeichnisse für die Speicherung der einzelnen Chunkdateien
-|group7= {{ver|Infdev|0.33|21. Juni 2010}}
+|group1= {{ver|version|27. Februar 2010}}
+|list1= *Die Entwicklung grenzenloser Welten beginnt, die Welt wird in [[Chunk]]s aufgeteilt.
-|list7= *Weil die Speicherung der Chunkdateien zu langsam ist, wird ein neues Zonenformat veröffentlicht<ref>http://notch.tumblr.com/post/697022652/a-gentle-warning-about-infdev-saves-breaking</ref><ref>http://notch.tumblr.com/post/722369319/your-saves-are-safe</ref>
+*Die Blöcke und Objekte gehören nicht mehr zu den Weltdaten, sondern werden als [[Chunkdaten]] separat gespeichert ([[Alpha Level Format]]).
-|group8= {{ver|Infdev|0.33|22. Juni 2010}}
+*Es gibt pro Welt maximal 64×64 Verzeichnisse für die Speicherung der einzelnen Chunkdateien.
-|list8= *Das Zonenformat ist zu fehlerhaft und wird wieder entfernt<ref>http://notch.tumblr.com/post/734055276/i-reverted-back-to-the-old-save-file-format</ref>
+|group2= {{ver|version|24. Juni 2010}}
+|list2= *Weil die Speicherung der Chunkdateien zu langsam ist, wird ein neues Zonenformat veröffentlicht<ref>http://notch.tumblr.com/post/697022652/a-gentle-warning-about-infdev-saves-breaking</ref>.<ref>http://notch.tumblr.com/post/722369319/your-saves-are-safe</ref>.
+|group8= {{ver|version|25. Juni 2010}}
+|list8= *Das Zonenformat ist zu fehlerhaft und wird wieder entfernt<ref>http://notch.tumblr.com/post/734055276/i-reverted-back-to-the-old-save-file-format</ref>.
+}}
 |group9= {{ver|Beta|1.3}}
-|list9= *Das neue [[Region Format]] kann die Chunkdateien deutlich schneller speichern und löst das Alpha Level Format ab
+|list9= *Das neue [[Region Format]] kann die Chunkdateien deutlich schneller speichern und löst das Alpha Level Format ab.
-*Bis zu 32×32 Chunks werden in einer Regiondatei zusammengefasst, alle Regiondateien stehen im ''/region''-Ordner
+*Bis zu 32×32 Chunks werden in einer Regiondatei zusammengefasst, alle Regiondateien stehen im ''/region''-Ordner.
 |group10= {{ver|1.2|12w07a}}
-|list10= *Die Chunkdaten werden erweitert, das neue Speicherformat heißt [[Anvil Format]]
+|list10= *Die Chunkdaten werden erweitert, das neue Speicherformat heißt [[Anvil Format]].
-*Die Bauhöhe wird von 128 auf 256 erhöht
+*Die Bauhöhe wird von 128 auf 256 erhöht.
-*Die Chunks werden in 16 Chunk-Sektionen eingeteilt, Luft-Sektionen werden nicht mehr gespeichert
+*Die Chunks werden in 16 Chunk-Sektionen eingeteilt, Luft-Sektionen werden nicht mehr gespeichert.
-*Es können 4096 statt 256 Block-IDs verwendet werden
+*Es können 4096 statt 256 Block-IDs verwendet werden.
-|group11= {{ver|1.13|17w47a}}
+|group11= {{ver|1.9|15w32a}}
+|list11= *Die [[Version-ID]] wird in den [[Weltdaten]], [[Spielerdaten]] und Chunkdaten gespeichert, um einen Versionswechsel zu erkennen und die [[Datenkonvertierung]] leicht durchführen zu können.
-|list11= *„Add“, „Blocks“ und „Data“ entfallen, stattdessen gibt es „BlockStates“ und „Palette“
+|group12= {{ver|1.13}}
+|list12=
+{{Geschichtlich
+|untergruppe=1
+|group1= {{ver|version|17w47a}}
+|list1= *Numerische Block-IDs werden nicht mehr gespeichert, sondern die ID-Namen der Blöcke in einer Palette-Liste.
+*Metadaten werden nicht mehr gespeichert, sondern die Blockzustände in der Palette-Liste.
+*Für jede XYZ-Position eines Blocks wird ein Index auf die Palette-Liste gespeichert.
+|group2= {{ver|version|18w06a}}
+|list2= *Mit Umstellung der [[Weltgenerierung]] werden die [[Bauwerksdaten]] in die Chunkdaten integriert.
+|group3= {{ver|version|18w16a}}
+|list3= *Trennung zwischen Block-Ticks und Flüssigkeit-Ticks.
+}}
+|group13= {{ver|1.13.1}}
+|list13=
+{{Geschichtlich
+|untergruppe=1
+|group1= {{ver|version|18w31a}}
+|list1= *Der neue {{b|/chunk}} kann [[dauerhafte Chunks]] einstellen, das wird in den [[Chunkladedaten]] gespeichert.
+|group2= {{ver|version|1.13.1-pre1}}
+|list2= *Der {{b|/chunk}} wird in <code>/forceload</code> umbenannt.
+}}
+|group14= {{ver|1.18}}
+|list14=
+{{Geschichtlich
+|untergruppe=1
+|group1= {{ver|version|21w39a}}
+|list1= *Die interne Container-Struktur wird geändert und angepasst.
+|group2= {{ver|version|21w41a}}
+|list2= *Die Priorisierungsreihenfolge der Chunk-Render-Pipeline wird geändert.
+}}
 }}
@@ Zeile 131: / Zeile 188: @@
 [[en:Chunk format]]
-[[fr:Format de fichier de tronçon]]
+[[fr:Format de tronçon]]
+[[ja:Chunkフォーマット]]
 [[ko:청크 구성]]
 [[nl:Segment formaat]]
+[[ru:Формат чанка]]
+[[tr:Chunk Biçimi]]
+[[uk:Формат чанку]]
 [[zh:区块格式]]