MC Toolkit

Anleitungen / Bauen & Ressourcen

Schwämme und Konstruktionsblöcke sind nicht dieselbe Datei

Eine .schem, eine .litematic und eine Bedrock-.mcstructure sehen austauschbar aus – bis man eine konvertiert und jede Truhe, jede Entität und jeder Blockzustand verschwunden ist.

Eine .schem und eine .litematic enthalten beide ein Bauwerk, und beim Konvertieren zwischen ihnen entdecken die meisten Spieler, dass sich die beiden Formate nie darüber einig waren, was ein Bauwerk ist. Das eine speichert eine einzelne Region aus Blöcken. Das andere kann mehrere benannte Regionen enthalten, jede mit ihrer eigenen Palette. Verschiebt man eine Stadt zwischen ihnen, überleben die Häuser, während der Inhalt nicht überlebt.

Was jedes Format tatsächlich mitführt

FormatWo es läuftBlockzuständeBlockentitätenEntitäten
.schemJava, WorldEdit/Spongejajaja
.litematicJava, Litematicajajaja
.nbt structureJava, Konstruktionsblöckejajaja
.mcstructureBedrockjajaja

Die Spalten sehen identisch aus, und genau das ist die Falle. Der Unterschied liegt in der Palettenverwaltung und im Koordinatenraum, nicht in der Funktionsliste.

Die Palette ist der zerbrechliche Teil

Jedes dieser Formate speichert Blöcke als Index in eine Palette – eine Liste der eindeutigen Blocktypen, die die Datei verwendet, wobei jede Position eine Zahl enthält, die in diese Liste zeigt. Ein Bauwerk mit ein paar hundert verschiedenen Blocktypen führt eine Palette dieser Größe mit, und die Positionen sind einfach nur ganze Zahlen.

Das bedeutet, die Datei ist nur lesbar, wenn der Leser jeden Paletteneintrag auflösen kann. Ein Block, der in einer neueren Java-Version hinzugefügt wurde, hat überhaupt kein Bedrock-Äquivalent, also muss eine Java-zu-Bedrock-Konvertierung ihn ersetzen oder weglassen. Luft ist der übliche Ersatz, und eine Wand mit rätselhaft fehlenden Blöcken ist fast immer genau das – keine Beschädigung.

Java und Bedrock benennen denselben Block unterschiedlich

Hier gehen Java und Bedrock wirklich auseinander. Bedrock schreibt Blockzustände als block_type plus eine Reihe von Schlüssel-Wert-Zuständen; Java schreibt eine namensraumbehaftete ID plus eine Zustandsmap. Derselbe physische Block kann auf der einen Seite minecraft:oak_stairs[facing=east,half=bottom] sein und auf der anderen weirdo_direction plus upside_down_bit – andere Zustandsnamen und -werte, nicht dieselben in anderer Reihenfolge.

Treppen, Stufen, Zäune, Mauern, Türen und Redstone-Komponenten sind die, die kippen. Eine Treppe, die nach der Konvertierung kopfüber dargestellt wird, ist ein Zustandszuordnungsfehler, keine kaputte Datei.

Konstruktionsblöcke speichern nicht, was du denkst

Ein Konstruktionsblock, der nach .nbt speichert, schreibt eine Begrenzungsbox, und diese Box ist auf 48 Blöcke pro Achse begrenzt. Das Spiel teilt ein größeres Bauwerk nicht auf – alles außerhalb der Box ist einfach nicht in der Datei. Wenn bei einem konvertierten Bauwerk das hintere Ende fehlt, prüfe die ursprüngliche Box, bevor du den Konverter verdächtigst.

Entitäten werden in jedem dieser Formate getrennt von Blöcken gespeichert. Rahmen, Rüstungsständer, Gemälde und Mobs sind keine Blöcke, und ein Konverter, der nur die Blockpalette durchläuft, lässt sie still und leise fallen.

Vorschau, bevor du es glaubst

Die Materialliste ist der schnellste Plausibilitätstest: Wenn die Blockzahlen der konvertierten Datei nicht mit denen des Originals übereinstimmen, wurde etwas ersetzt. Die Ebenenvorschau zeigt das sofort, eine horizontale Scheibe nach der anderen, ohne das Bauwerk in eine Welt zu laden.

Konvertiere zwischen .litematic, .schem, Java-structure-.nbt und Bedrock-.mcstructure, mit Ebenenvorschau und Materialliste, im Schematic Converter.

Schematic-Konverter →

Weitere Anleitungen

Alle ansehen →