Die Minecraft Bedrock Edition nutzt ein von der Java Edition abweichendes Format zur Speicherung der Spielwelten. Dieses Format ist weitgehend unbekannt. Mit der Einführung der Version 0.9.0 nutzt die Bedrock Edition eine modifizierte Version von Google's LevelDB, wo eine Zlib compression benutzt wird um die Level zu speichern. In der Version 0.8.1 und darunter wird mit einem modifizierten NBT-Format gearbeitet wird, welches mit Little-Endian-Byte-Reihenfolge arbeitet.
LevelDB Format[]
Mit der Version 0.9.0 wurde ein neues Format zum Speichern der Welten eingeführt, basierend auf LevelDB 1.17 mit zusätzlicher Zlib Kompression. Alte Welten werden automatisch in das neue Format konvertiert wenn sie geladen werden.
Die offizielle LevelDB Seite ist hier verfügbar: https://code.google.com/p/leveldb/. Mojang's modifiziertes LevelDB ist verfügbar unter https://github.com/Mojang/leveldb-mcpe und die benötigten Build Parameter sind dort von Tommaso dokumentiert[1]. Um ein Bedrock Edition Level zu lesen, schaue hier: https://github.com/tinfoiled/leveldb
Die Datenbank ist gespeichert unter dem db/ Unterverzeichnis einer Bedrock Edition Welt. Es scheint so, als ob da auch die Terrain Generation gespeichert wird. Das ist so, damit man eine alte Welt in eine unendliche Welt umwandeln kann, indem man den db-Ordner mit einer unendlichen Welt ersetzt.
Es gibt drei Arten von gespeicherten Daten in der Datenbank: Terrain Daten, Entity Daten und Blockobjektdaten.
Schlüsselformat: 9 Byte Schlüssel, welcher aus folgendem bestehen zu scheint:
- x Koordinate des Chunks als little-endian Integer
- z Koordinate des Chunks als little-endian Integer
- Ein zusätzliches Byte, welches den Datentyp angibt:
- 0x30 (48 in Dezimal-Schreibweise, '0' ASCII) für die Terrain-Daten
- 0x31 (49 in Dezimal-Schreibweise, '1' ASCII) für Tile Eintity-Daten
- 0x32 (50 in Dezimal-Schreibweise, '2' ASCII) für Entity-Daten
- 0x76 (118 in Dezimal-Schreibweise, 'v' ASCII) für 1 Byte Daten
Der 0x30 Terrain-Daten Eingang enthält Block-Daten für einen x*z*y = 16*16*128 Block großen Chunk. Der mit dem 0x30 Terrain-Daten verbundene Schlüssel hat immer eine Länge von 83200 und scheint aus den folgenden Daten zu bestehen:
- 32768 Bytes Blockdaten, welche als x*z*y = 16*16*128 Block großer Chunk erscheinen.
- 16384 Bytes regulärer Daten (ein Halb-Byte für jedes Byte der oben erwähnten Block-Daten).
- 16384 Bytes Himmelslicht-Daten (ein Halb-Byte für jeden Byte der oben genannten Blockdaten).
- 16384 Bytes Blocklicht-Daten (ein Halb-Byte für jeden Byte der oben genannten Block-Daten).
- 256 Bytes zusätzlicher Daten welche als z*x=16*16 Byte Datenbereich erscheinen (ein Byte für jede vertikale y Spalte von 128 Bytes der oben genannten Block-Daten).
- 1024 Bytes zusätzlicher Daten, welche als 16*16*4 Datenbereich erscheinen (vier Bytes für jede vertikale y Spalte von 128 Bytes der oben genannten Blockdaten), welcher Informationen über die Grasfarbe enthält.
Die folgenden Definitionen sind dazu gedacht, das Mapping zwischen der Position eines Blocks in einem LevelDB Eingang, welcher einen Chunk von 32768 Blöcken enthält, und der dazugehörigen Position in der Welt zu klassifizieren.
- Angenommen, X und Z sind die Werte, welche im LevelCB Schlüssel enthalten sind.
- Angenommen, C [] ist ein dreidimensionaler Bereich des Chunks, welcher aus 32768 Blöcken besteht und Teil des LevelDB Eingangs ist.
- Angenommen, W [] ist ein dreidimensionaler Bereich, der Blöcke welche in der ganzen Welt enthalten sind.
- Für alte Welten reichen die ersten beiden Angaben, X und Z von 0 bis 255. Für unendliche Welten reichen X und Y über die Werte eines 4 Byte Integers hinaus, und können sowohl positiv als auch negativ sein.
- Der dritte Index Y reicht von 0 bis 127 für alte, sowie unendliche Welten.
Die oberen Definitionen angenommen, wird der Ort eines Blocks mit einem LevelDB Eingang mit den Werten X und Z zu dem entsprechenden Ort in der Welt wie folgt entschlüsselt:
- C [i, j, y] <-> W [x, z, y] wobei x = 16*X + i und z = 16*Z + j
Der Index X spezifiziert den Nord-Süd Ort, wobei gilt, dass je kleiner der Wert x ist, desto weiter nördlich befindet sich der Block. Der Index z spezifiziert den Ost-West Ort des Blocks, wobei gilt, dass je kleiner der Wert z ist, desto weiter befindet sich der Block im Osten. Der Index y spezifiert den vertikalen Ort des Blocks, wobei gilt, dass je kleiner der Wert y ist, desto tiefer befindet sich der Block. Für eine alte Welt, gilt, dass der tiefste Block in der Nord-Ost Ecke W [0, 0, 0] ist.
Die oben genannten 0x31 Tile Entity und 0x32 Entity Daten sind NBT enkodiert und können 0, 1, oder mehrfach verknüpfte Komponente auf dem Wurzel-Level enthalten. Im Falle von 0 Komponenten zeigt der LevelDB 0 als Länge des mit dem Wert assoziierten Schlüssels. Mehrfach verknüpfte Kennzeichnungen werden unterstützt, da es mehrere Entities pro Chunk geben kann. Jede 0x31 tile entity und jeder 0x32 entity Eingang hat einen mit ihm assoziierten 0x30 Terrain Eingang, aber nicht jeder 0x30 Terrain Eingang hat auch einen mit ihm assoziierten 0x31 tile entity oder 0x32 entity Eingang.
Die Anzahl an 0x30 Terrain Eingängen und 0x76 1-Byte Daten Eingängen ist immer die gleiche, außerdem gibt es eine eins-zu-eins Verbindung zwischen diesen Eingängen, bei denen die dazugehörigen Eingänge beide die gleichen x und z Werte heben. Drei Werte sind für die 1-Byte Daten bekannt, inklusive der binären Werte 0, 1 und 2. Der Wert 0 wurde bei alten Welten beobachtet, die Werte 1 und 2 bei unendlichen Welten.
Es gibt auch den speziellen Schlüssel ~local_player für einen Entity Daten-Eingang, der für die lokale Spieler-Entity zuständig ist. Wenn hier bereits Entity-Daten existieren, überschreiben sie die Daten des Spielers, welche in der level.dat gespeichert sind. Der mit dem ~local_player-Schlüssel verbundene Wert ist NBT-enkodiert und hat nur einen einzigen verbundenen Wert auf Grund-Niveau.
Ebenso gibt es einen bestimmten Schlüssel entfernte Spieler, welcher aus zwei Teilen besteht. Der erste Teil besteht aus dem Präfix player_, der zweite Teil besteht aus der Client-ID, welche in der clientid.txt-Textdatei zu finden ist. player_-12345678 wäre zum Beispiel ein Beispiel für den Schlüssel eines Spielers mit der Client-ID -12345678. Der mit dem Schlüssel mit dem Präfix player_ verbundene Schlüssel ist NBT-enkodiert und hat nur einen einzigen verbundenen Wert auf Grund-Niveau.
Es gibt auch einen speziellen game_flatworldlayers-Schlüssel mit einer Länge von 20 für Flache Welten. Der mit diesem Schlüssel verbundene Wert ist eine Gruppe von Zahlen im ASCII-Textformat. Ein Beispiel für einen mit dem game_flatworldlayers-Schlüssel verbundenen Wert wäre [7,3,3,2], dessem Länge in diesem Fall 9 beträgt.
level.dat[]
Die level.dat Struktur ist ähnlich wie die in der 0.8.1 und darunter.
Struktur[]
- Welt-Daten
- Dimension: Dimension, in der sich der Spieler befindet. Die Oberwelt hat den Wert 0
- GameType: Spielmodus, 0 für Uberlebensmodus, 1 für Kreativmodus
- Generator: Welt Typ: Old, Infinite oder Flat
- LastPlayed: Zeitpunkt der letzten Speicherung des Spiels als Zeitstempel in Sekunden seit dem 1.1.1970
- LevelName: Name des Levels
- LimitedWorldOrigin. (Wird nur angezeigt beim Welt Typ Alt)
- LimitedWorldOriginX: X-Koordinate wo die begrenzte Welt Generation startete
- LimitedWorldOriginY: Y-Koordinate wo die begrenzte Welt Generation startete
- LimitedWorldOriginZ: Z-Koordinate wo die begrenzte Welt Generation startete
- Platform: Anscheinend genutzt, um die Plattform zu speichern, auf der die Welt erzeugt wurde. Aktuell bekannt ist hier nur der Wert 2
- RandomSeed: Zufallszahl, die den Startwert des Weltgenerators liefert
- SizeOnDisk: Geschätze Weltgröße in Byte
- Spawn Coordinates of world
- SpawnX: X-Koordinate des Spawnpunkts des Spielers, normalerweise 0
- SpawnY: Y-Koordinate des Spawnpunkts, normalerweise 64
- SpawnZ: Z-Koordinate des Spawnpunkts, normalerweise 0
- StorageVersion: verwendete Version des Bedrock-Edition-NBT-Formats. Aktuell 4
- Time: Anzahl der Ticks seit Start der Welt, und modulo 14400 genommen die aktuelle Tageszeit
- dayCycleStopTime: In der 0.8.0 hinzugefügt. Standardwert ist 18446744073709552000
- spawnMobs: Schaltet Mob-Spawning aus(0) oder ein(1)
LOG[]
Die LOG Datei ist gespeichert in dem /db Verzeichnis in einem Level, und ist Teil von dem LevelDB Format, benutzt als zwischen Verdichtung von den LDB Dateien. Es ist ähnlich wie eine Log Datei von einem Programm. Das Format ist:
YYYY /MM/DD-Hour/Minute/Second.StepName "Info"
Beispiel:
2014/07/24-22:20:08.400488 4a3638 Recovering log #3
Altes Level Format[]
Dieses Level Format wurde bis einschließlich Alpha 0.8.1 verwendet.
level.dat[]
Seit der Alpha 0.2.0 werden Weltdaten als NBT-formatierte Datei gespeichert, ähnlich des Formats der Datei in der Java Edition. In dieser unkomprinierten Little-Endian - nutzenden NBT-Datei werden Daten wie die Tageszeit, Spielerposition, Geschwindigkeit und Richtung, das Inventar und die Gesundheit gespeichert.
Die Datei beginnt mit einem 8 Byte langen "Kopfeintrag" bestehend aus einer 4 Byte langen Typdefinition der Datei (die aktuell für level.dat den Wert 3 hat) sowie einem 4 Byte langen Integer für die Länge der Datei (abzüglich der 8 Byte Kopf).[2]
NBT-Struktur[]
- Welt-Daten
- GameType: Spielmodus, 0 für Uberlebensmodus, 1 für Kreativmodus
- LastPlayed: Zeitpunkt der letzten Speicherung des Spiels als Zeitstempel in Sekunden seit dem 1.1.1970
- LevelName: Name der gespeicherten Welt
- Platform: Anscheinend genutzt, um die Plattform zu speichern, auf der die Welt erzeugt wurde. Aktuell bekannt ist hier nur der Wert 2
- Player: Spieler-Entity-Informationen, siehe Entity-Format und Wesen-Entity-Format für die Basis-Angaben. Den Spieler-Entity-Informationen fehlt das ID-Tag, dafür existieren noch folgende Zusatz-Informationen:
- Armor: 4 Elemente lange Liste von TAG_Compound-Werten für die getragene Rüstung (Helm, Brustpanzer, Hose, Stiefel)
- Rüstungsdaten
- id: Gegenstand- oder Block-ID.
- Count: Anzahl von Gegenständen, die in diesem Slot gestapelt sind.
- Damage: Menge des Schadens, den die Rüstung noch einstecken kann. Erreicht der Wert 0, zerbricht und verschwindet die Rüstung
- Rüstungsdaten
- Dimension: Dimension, in der sich der Spieler befindet. Die Oberwelt hat den Wert 0
- Inventory: Liste von TAG_Compound-Werten, die das Inventar des Spielers definieren
- Inventar
- Slot: Definiert den Inventar-Platz, in welchem sich der Gegenstand befindet
- id: Gegenstand- oder Block-ID
- Count:Anzahl von Gegenständen, die in diesem Slot gestapelt sind. Jeder Gegenstand kann gestapelt werden, auch Werkzeuge. Gültige Werte liegen zwischen 1 und 255, größere Werte werden nicht angezeigt
- Damage: Bei Werkzeugen: Verbleibende Stabilität. Der Maximalwert wird initial eingetragen (zum Beispiel 33 für goldenes Werkzeug). Wenn der Wert 0 erreicht, zerbricht und verschwindet das Werkzeug.
- Inventar
- Score: Die Punktewertung des Spielers
- Sleeping: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler in einem Bett war als dieser Tag gespeichert wurde; hat keinen Effekt ob der Spieler in einem Bett ist wenn die einloggen
- SleepTimer: Die Nummer von den Ticks als der Spieler in einem Bett war als dieser Tag gespeicher wurde. Kein Effekt
- SpawnX: X-Koordinate des Spawnpunkts des Spielers, normalerweise 0
- SpawnY: Y-Koordinate des Spawnpunkts, normalerweise 64
- SpawnZ: Z-Koordinate des Spawnpunkts, normalerweise 0
- abilities: Die Fähigkeiten die der Spieler hat
- mayfly: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler fliegen kann
- flying: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler grad am fliegen ist
- invulnerable: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler immun gegen alles ist ausser gegen Die Leere
- mayBuild: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler Blöcke platzieren und zerstören kann
- instabuild: 1 oder 0 (richtig/falsch) - richtig wenn der Spieler sofort Blöcke zerstören
- Armor: 4 Elemente lange Liste von TAG_Compound-Werten für die getragene Rüstung (Helm, Brustpanzer, Hose, Stiefel)
- RandomSeed: Zufallszahl, die den Startwert des Weltgenerators liefert
- SizeOnDisk: Geschätze Weltgröße in Byte
- SpawnX: X-Koordinate des Spawnpunkts des Spielers, normalerweise 0
- SpawnY: Y-Koordinate des Spawnpunkts, normalerweise 64
- SpawnZ: Z-Koordinate des Spawnpunkts, normalerweise 0
- StorageVersion: verwendete Version des Bedrock-Edition-NBT-Formats. Aktuell 3.
- Time: Anzahl der Ticks seit Start der Welt, und modulo 14400 genommen die aktuelle Tageszeit
- dayCycleStopTime: In der 0.8.0 hinzugefügt. Standardwert ist 18446744073709552000
- spawnMobs: Schaltet Mob-Spawning aus(0) oder ein(1)
chunks.dat[]
In dieser Datei werden die 16 x 16 (256) Chunks gespeichert, die alle 256 x 256 x 128 Blöcke der jeder Standard-Karte beschreiben. Alle 4.096 Byte (oder 4 Kilobyte) liegt eine Sektorgrenze, und eine Standard-Karte hat 5.377 Sektoren. Die Dateigröße ist maximal 32 x 32 (1024) Chunks und somit 512 x 512 x 128 (33.554.432) Blöcke, aber die Standard-Karten, die das Spiel erzeugt, sind immer nur 16 x 16 Chunks groß. Die meisten Werte in dieser Datei (mit einigen wenigen Ausnahmen) sind in 32-Bit Little-Endian gespeichert.
Aufbau der Datei[]
Der erste Sektor der Datei dient als "Datenkarte", die auf die verfügbaren Chunks und ihre Position in der Datei verweist. Jeweils 128 Byte dieses ersten Sektors verweist auf eine Reihe von Chunks in der Karte, auch wenn üblicherweise nur 64 Byte davon genutzt werden, da nur 16 Chunks in jeder Reihe liegen.
Das Format der Angabe für einen Chunk in der Datenkarte ist 15 XX ZZ 00
. Hierbei steht die 15 (21dec) für die Anzahl von Sektoren in diesem Abschnitt. XX steht für die X-Koordinate im Bezug auf die obere linke Ecke des Chunks (in hexadezimaler Schreibweise), und ZZ speichert die Z-Koordinate. Die letzte Zahl wird erst in zukünftigen Versionen benötigt, falls die Karte vergrößert würde. Man kann sich die X-Koordinate auch als den Startpunkt des Chunks auf der Karte vorstellen.
Um anhand der Datenkarte den Abschnitt eines Chunks in der Datei zu finden, müssen nur X und Z in den Term 4096+(x*21*4096)+(z*21*16*4096)
eingesetzt werden. Die Datenkarte selbst enthält keine Chunks, deshalb wird erst bei 4096
gestartet. Jeder Chunk ist insgesamt 21*4096=86016
Bytes groß, deshalb müssen für die Position eines Chunks in der Datei X Vielfache von 86016 hinzuaddiert werden. Mit der Z-Koordinate verhält es sich genauso, alle 16 Chunks beginnt eine neue Reihe, deshalb werden Z Vielfache vom 16-fachen der Größe eines Chunks, also von 16*21*4096=1376256
, hinzuaddiert.
Beispiel: Wir haben drei Zahlen in der Datenkarte, 15 4d 02 00
. Die erste Zahl sagt aus, wie viele Sektoren sich in dem Chunk befinden, in diesem Fall 21. Die zweite Zahl, 4dhex, ist die X-Koordinate, die dritte, 02hex, die Z-Koordinate. Die vierte Zahl wird nur bei größeren Karten nötig und hat bisher keine Bedeutung. Jetzt addieren wir zu 4096
(Größe der Datenkarte) 77*21*4096
(ergibt sich aus der X-Koordinate) und erhalten 6627328
. Dazu wird noch 2*21*4096*16
(aufgrund der Z-Koordinate) addiert, und wir erhalten als Endergebnis 9379840dec
. Diese Zahl gibt das Byte der Datei an, an dem die Informationen des Chunks mit X=4d und Z=2 beginnen.
Aufbau eines Chunks[]
Ab Byte 1000hex (4096dec) beginnt die Auflistung der Blöcke. Die ersten vier Bytes eines jeden Chunks bilden dessen Kopfzeile, die den Anfang des neuen Chunks markiert. Dieser Kopf hat immer den Wert 04 41 01 00hex
. Auf die Kopfzeile folgen Blöcke, wobei immer 128 Köpfe eine Spalte bilden und alle 16 Spalten eine neue Reihe beginnt. Die Spalten können als Arrays vom Typ Short (short[]
) gespeichert werden.
Nach den ersten acht Sektoren an Blockdaten folgen vier Sektoren im regulären Big-Endian-Format, in denen Informationen über bestimmte Blöcke gespeichert sind. Da dieser Abschnitt nur vier Sektoren lang ist, repräsentiert jedes Byte zwei Blöcke zugleich.
Beispiel: Angenommen, man platziert etwas blaue und rote Wolle in einer Spalte bei [4, 76, 14]
in einem Chunk. Indem man X-, Y- und Z-Koordinaten der Wolle innerhalb des Chunks halbiert, erhält man die Information, dass die Informationen zu dem Block sich bei [2, 38, 7]
befinden. Dadurch kann man das betroffene Byte finden, indem man zum Beginn des Sektors springt, und dann um (x*64)+y+(z*64*16)
Bytes weitergeht. In diesem Beispiel enthielte dann das Byte, an dem man sich nun befindet, den Wert EBhex
. Da durch das Big-Endian-Format die Ziffernfolge umgekehrt wird, muss man diesen Wert als BEhex
lesen. Da jedes Byte zwei Blöcke gleichzeitig darstellt, enthält B die Daten für die blaue und E die Daten für die rote Wolle; Man muss das Byte also aufteilen, um die Daten der einzelnen Blöcke zu erhalten.
Auf die vier Sektoren mit allgemeinen Daten folgen nochmals vier mit Daten zum Tageslicht. Auch hier enthält ein Byte wieder Informationen zu zwei Blöcken gleichzeitig und ist im Big-Endian-Format angegeben. Der maximale Wert (Fhex
) bedeutet absolute Dunkelheit, während 0
die maximale Helligkeit bedeutet. Da das Spiel das Lichtlevel allerdings automatisch generiert, bringt es nichts, hier Teile der Datei zu manipulieren.
Die letzten vier Sektoren sind exakt so aufgebaut wie die des Tageslichts, allerdings enthalten sie stattdessen Daten über die Helligkeit des Blockes selbst. Wie auch bei den anderen enthält jedes Byte im Big-Endian-Format Informationen zu je zwei Blöcken, auch die Helligkeitswerte sind wie beim Tageslicht (dunkel=F
, hell=0
). Auch hier zeigt sich durch Abändern der Daten keine Änderung.
player.dat[]
Eine veraltete Datei, die in Versionen vor Alpha 0.2.0 im Einsatz war und die Spieler-Informationen bereit hielt, die seitdem in level.dat gespeichert werden.
entities.dat[]
Diese Datei wurde mit der Alpha 0.2.0 eingeführt und speichert anscheinend die Entity-Informationen, im Aufbau basierend auf dem Alpha-Level Chunk Format.
Mit der Alpha 0.3.2 wurde die Datei um die Speicherung von Blockobjektdaten erweitert.
Die Datei beginnt mit einem 12-Byte langen Kopf-Element, bestehend aus den Buchstaben ENT, einem Null-Byte, gefolgt von einem Integer-Wert '1' und der Länge der restlichen Datei abzüglich der 12 Byte Kopfdaten, ebenfalls gespeichert als Integer-Wert.[2]
NBT-Struktur[]
- Das Haupt-Tag
- Entities: Jeder TAG_Compound-Eintrag dieser Liste definiert eine Entität in der Welt, wie im Abschnitt Entity-Format unten beschrieben
- TileEntities: Jeder TAG_Compound-Eintrag dieser Liste definiert die Blockobjektdaten der Welt, zum Beispiel einen Ofen
Entity-Format[]
Jede Entity wird gespeichert als ein unbenanntes TAG_Compound-Objekt in der Liste aller Entities innerhalb eines Chunks. Die einzige Ausnahme ist das Spieler-Objekt, welches in der Datei level.dat gespeichert wird.
Alle Entities teilen sich die folgende Basis-Struktur:
- Entity-Daten
- id: Objekt-ID
- Pos: Liste mit 3 TAG_Float-Werten, die die aktuelle X,Y,Z-Position des Spielers bestimmen
- Motion: Liste mit 3 TAG_Float-Werten, die die aktuelle Geschwindigkeit des Spieler in X, Y und Z-Richtung bestimmen, gemessen in Blöcken bzw. Meter pro Tick
- Rotation: Liste mit 2 TAG_Float-Werten, die die Rotation des Spieler in Grad bestimmen (Rotation um die Y-Achse, Blick nach Westen = 0, sowie Neigung gegen den Horizont. Genau horizontal ist gleich 0, nach unten ist die Neigung positiv, nach oben negativ)
- FallDistance: Distanz, die das Objekt schon gefallen ist. Größere Werte fügen mehr Schaden zu, wenn das Objekt landet.
- Fire:Zeit in Ticks, bis das Feuer des brennenden Objekts gelöscht wird. Negative Werte sagen aus, wie lange das Objekt im Feuer stehen kann, ohne zu brennen. Standard ist -1 wenn er nicht brennt.
- Air: Zeit in Ticks, wieviel Luft das Objekt noch zur Verfügung hat. Unter Wasser sinkt der Wert innerhalb von 15 Sekunden auf 0.
- OnGround: 1 oder 0 (true/false) - true, wenn das Objekt den Boden berührt.
Wesen-Entities[]
- Zusätzliche Felder für Kreaturen:
- AttackTime: Zeit in Ticks, die das Wesen unverwundbar bleibt, bis es zum nächsten Mal Schaden nimmt. 0, wenn es nicht kürzlich getroffen wurde.
- DeathTime: Zeit in Ticks, die seit dem Tod des Wesens vergangen ist. Kontrolliert Sterbe-Animation. 0 wenn es lebt.
- Health: Angabe für die Gesundheit des Wesens (in halben Herzen). Spieler und Monster haben bis zu 20 Leben, Tiere bis zu 10.
- HurtTime: Unklar, eventuell Zeit in Ticks, die das Wesen rot gezeichnet wird, nachdem es getroffen wurde. 0, wenn es nicht kürzlich getroffen wurde.
- Zusätzliches Feld für Tiere:
- Age: Alter des Tieres
Schafe nutzen zwei weitere Zusatzfelder:
- Sheared: 1 oder 0 (wahr/falsch) - Wahr, wenn das Schaf geschoren wurde.
- Color: 0 - 15 - Farbe der Schafs-Wolle, siehe Farbwerte für gefärbte Blöcke. Es gibt Hinweise darauf, dass dieser Wert nicht die Darstellung des Schafs, wohl aber die Farbe der beim Scheren oder Töten erzeugten Wolle beeinflusst.[3]
- Zusätzliche Felder für Drops:
- Health: Lebenspunkte des Drops, beginnend mit 5, und aktuell nur reduziert, wenn ein Drop Feuerschaden nimmt. Fällt der Wert auf 0, so wird der Drop zerstört.
- Age: Die verstrichene Zeit, die ein Drop unangerührt auf dem Boden liegt. Nach 2400 'Ticks' (oder 2 Minuten) wird der Drop zerstört.
- Item: Gegenstand-Daten
- id: Gegenstand-ID
- Damage: Die Abnutzung bzw. der Schaden, den ein Gegenstand erlitten hat; 0 bedeutet neuwertig. Wenn die Abnutzung die Haltbarkeit des Gegenstands übersteigt, zerbricht er und wird zerstört. Üblicherweise nutzen sich nur Werkzeuge und Rüstung ab.
- Count: Anzahl von gleichartigen Gegenständen in diesem Datenblock. Jeder Gegenstand ist stapelbar, die gültigen Werte liegen zwischen 1 und 255.
Quellen[]
Bedrock Edition level format (englische Wiki)
Einzelnachweise[]
Editionen | |||||||
---|---|---|---|---|---|---|---|
Entwicklung | |||||||
Überblick | |||||||
Blöcke |
| ||||||
Welttypen | |||||||
Gameplay | |||||||
Technisches | |||||||
Education Edition |
Standard-Ressourcen |
| ||||
---|---|---|---|---|---|
Standard-Weltdaten |
| ||||
Spielwelt | |||||
Software | |||||
Speicherformate | |||||
Einstellungen | |||||
Mehrspieler | |||||
Historisch |