Minecraft Wiki
(→‎Ofen: 1.13)
(→‎Kopf: aktualisiert)
Zeile 186: Zeile 186:
 
***** {{NBT|list|textures:}} Texturen des Kopfes.
 
***** {{NBT|list|textures:}} Texturen des Kopfes.
 
****** {{NBT|compound}} Eine Textur.
 
****** {{NBT|compound}} Eine Textur.
  +
******* {{NBT|string|Signature}}: Optional eine Signatur.
******* {{NBT|string|Value:}} Die URL-Adresse von der die Grafik für den Kopf geladen wird. Diese ist [[de.wikipedia:UTF-8|UTF-8]] kodiert und als [[de.wikipedia:Base64|Base64]]-Zeichenkette angegeben.</div>
 
  +
******* {{NBT|string|Value:}} Ein [[JSON]]-Objekt als [[de.wikipedia:Base64|Base64]]-Zeichenkette. Für Base64 gibt es Online-Decodierungen, z.B. [https://www.base64decode.org/ diese].
  +
******** {{JSON|objekt}} Das namenlose Texturobjekt.
  +
********* {{JSON|text|profileId}}: Optional die [[UUID]] des Spielers ohne Bindestriche.
  +
********* {{JSON|text|profileName}}: Optional der Spielername.
  +
********* {{JSON|boolean|isPublic}}: ''true'' oder ''false''. Der Wert ''true'' ist Standard und kann weggelassen werden. ''false'' gibt an, dass die Textur-URL nicht öffentlich zugänglich ist.
  +
********* {{JSON|objekt|textures:}} Die Texturen.
  +
********** {{JSON|objekt|SKIN:}} [[Skin]]-Textur.
  +
*********** {{JSON|text|url:}} Die URL der Skin-Textur.
  +
********** {{JSON|objekt|CAPE:}} [[Umhang]]-Textur.
  +
*********** {{JSON|text|url:}} Die URL der Umhang-Textur. Ein Umhang wird bei Köpfen nicht angezeigt. Ansonsten wird ein Umhang nur angezeigt, wenn in den Account-Daten des Spielers ein Umhang durch Mojang eingetragen wurde.
  +
********* {{JSON|zahl|timestamp:}} Optional die [[de.wikipedia:Unixzeit|Unixzeit]] in Millisekunden des Zeitpunktes, wann die Texturdaten abgerufen wurden. Die Umrechnung von Unix-Sekunden in Realzeit ist z. B. [https://www.unixtime.de/ hier] möglich, man muss aber vorher die letzten drei Stellen vom ''timestamp'' entfernen, da es Millisekunden sind.
  +
</div>
   
 
=== Leuchtfeuer ===
 
=== Leuchtfeuer ===

Version vom 10. August 2018, 15:46 Uhr

NBT-Blockobjektdaten

Datenbaum im NBT-Explorer: "Meine Testwelt" hat dort in Region r.0.0.mca in Chunk [0,0] diverse Chunkdaten (Level) wozu auch eine Liste der Blockobjektdaten TileEntities gehört, die hier nur ein einziges Blockobjekt enthält (1 entry), das fünf Eigenschaften hat, unter anderem die Position (x, y, z) und vor allem die ID "jukebox", was dieses Blockobjekt als Plattenspieler identifiziert

Blockobjektdaten (engl. Block Entity Data) sind Zusatzdaten für einige Blöcke mit besonderer Funktion.

Arten

Die folgenden Blöcke benutzen Blockobjektdaten:

  • Banner speichern darin die Muster.
  • Befehlsblöcke speichern darin den Befehl, den sie ausführen, und ihren aktuellen Zustand (z. B. Wiederholen oder Immer aktiv; der Bedingt-Modus steht dagegen im Blockzustand).
  • Braustände speichern darin die enthaltenen Gegenstände und die Brauzeit.
  • Endtransitportale speichern darin die Koordinaten ihrer Zielpunkte.
  • Komparatoren speichern darin ihre Signalstärke.
  • Konstruktionsblöcke speichern darin die eingegebenen Daten.
  • Spielerköpfe speichern darin die Daten zum dargestellten Spieler.
  • Leuchtfeuer speichern darin, wie viele Etagen die Pyramide unter ihnen hat und die Effekte, die sie bewirken.
  • Öfen, Redstone-Truhen, Shulkerkisten, Spender, Trichter, Truhen und Werfer speichern darin ihr Inventar und einen evtl. Schlüsselnamen, mit dem sie verschlossen sind. Zusätzlich speichern Öfen, wie lange der Brennstoff noch ausreicht und die Zeit, bis der nächste Gegenstand fertig geschmolzen ist.
  • Plattenspieler speichern darin die enthaltene Schallplatte.
  • Schilder speichern darin ihren Text.
  • Spawner speichern darin die zu spawnende Kreatur, spezifische Eigenschaften der Kreatur, die Zeit, bis die nächste gespawnt wird, und die Anzahl der spawnenden Kreaturen.
  • Der Block, der von einem Kolben bewegt wird (bewegter Block) speichert in seinen Blockobjektdaten Informationen über den Block, den er verschiebt. Nach der Speicherung wird die Schub-Animation angezeigt. Wenn diese beendet ist, entsteht an der Zielposition der Block, der bewegt wurde. Seine Informationen erhält er aus den Blockobjektdaten des bewegten Blockes.

Aquisator, Bett, Endertruhe, Endportal, Köpfe, Tageslichtsensor und Zaubertisch besitzen auch Blockobjektdaten, speichern aber zur Zeit darin keine speziellen Eigenschaften (außer dem Spielerkopf).

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.
        • region: Alle Regionsdateien der Welt. Sie enthalten die Chunks.
          • r.X.Z.mca: Eine Region-Datei mit bis zu 1024 Chunks.
            • Chunk [X, Z]: Ein Chunk.
              • Level: Alle Chunkdaten.
                • TileEntities: Liste aller Blockobjektdaten des Chunks.

Änderbarkeit

Blockobjektdaten sind Teil der Chunkdaten, die im NBT-Format vorliegen. Das heißt, diese Daten sind außerhalb des Spiels nur mit einem speziellen NBT-Editor einseh- und änderbar. Im Spiel können sie mit dem Befehl /data geändert werden. Der Befehl kann z.B. im Chat eingegeben oder über einen Befehlsblock ausgelöst werden.

Für die Angabe von Blockobjektdaten in Befehlen wird JSON verwendet. Bei komplexeren Angaben ist es empfehlenswert, sie strukturiert aufzuschreiben, um den Überblick über Klammerung und Kommata zu behalten.

Beispiel für die Änderung des Wandschildes, an das man seine Nase drückt. (Die Position ~ ~1 ~ ist ein Block über den Füßen des Spielers, also der Block, in dem sich der Kopf und das Wandschild befinden):

/data merge block ~ ~1 ~ {Text1:"{\"text\":\"Das ist ein Text\"}"}
Weitere Beispiele mit Blockobjektdaten siehe: Anleitungen/Befehle mit NBT

Funktionsweise

Blöcke mit Blockobjektdaten haben die Besonderheit, dass sie nicht mit einem Kolben verschoben werden können. Ein Kolben kann sich nämlich nur den ID-Namen und den Blockzustand eines Blockes merken, nicht jedoch eventuelle Blockobjektdaten. Das gilt auch, wenn die Blockobjektdaten leer sind (leeres Schild, leere Truhe) oder wenn der Block zwar Blockobjektdaten hat, aber keine weiteren Eigenschaften (Aquisator, Endertruhe, Endportal, Tageslichtsensor, Zaubertisch).

Die Blockobjektdaten werden zusammen mit dem Block erzeugt und sind dann Teil des Blockes. Wird er zerstört, gehen die Blockobjektdaten mit verloren. Truhen droppen dann ihren Inhalt und müssen neu gefüllt werden, Schilder müssen neu beschriftet werden, etc.

Datenstruktur

Mit dem Befehl /data kann man sich alle Blockobjektdaten eines Blockes anzeigen lassen. Als Positionsangabe im Beispiel ist es der Block unter dem Spieler:

/data get block ~ ~-1 ~

Blockobjektbasisdaten

  • Allgemeine Blockobjekt-Eigenschaften.
    • id: Blockobjekt-ID (siehe Liste)
    • keepPacked: Unbekannt. Die Eigenschaft wird über den Befehl /data nicht angezeigt.
    • x: X-Koordinate des Blockes mit Blockobjektdaten.
    • y: Y-Koordinate des Blockes mit Blockobjektdaten.
    • z: Z-Koordinate des Blockes mit Blockobjektdaten.

Aquisator

  • Banner hat die Blockobjekt-ID "banner"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Name des Banners als JSON-Text (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Der Name kann als Kartenmarkierung eingesetzt werden.
    • Patterns: Optional die Liste der verwendeten Muster. Sie liegen in der Reihenfolge übereinander, in der sie in der Liste aufgeführt werden.
      • Ein Muster des Banners.
        • Color: Die Farb-ID für die Farbe des Musters. Wertebereich: 0 bis 15.
        • Pattern: Art des Musters. Für die verfügbaren Kürzel siehe Banner/Muster.

Befehlsblock

Hinweis: Der Modus (Impuls, Wiederholen, Verketten) ergibt sich aus dem ID-Namen des Blockes an der entsprechenden Position. Der Bedingt-Zustand ergibt sich aus dem Blockzustand.

  • Befehlsblock hat die Blockobjekt-ID "command_block"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Befehlsblöcke geben bei Meldungen im Chat diesen Namen an, der standardmäßig "@" lautet, aber mit einem Amboss auch geändert werden kann. Optional können Namen als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}").
    • auto: 1 oder 0 (true/false) - true, wenn der Befehlsblock immer aktiv ist, auch wenn er kein Redstone-Signal erhält.
    • Command: Der Befehl im Befehlsblock.
    • conditionMet: 1 oder 0 (true/false) - Standardmäßig true, und nur false, wenn es ein Befehlsblock im Bedingt-Modus ist, der nicht ausgeführt wurde.
    • LastExecution: Im Verketten-Modus der Tick, in dem der Ketten-Befehlsblock zuletzt ausgeführt wurde. Wenn UpdateLastExecution false ist, ändert sich dieser Wert nicht. Bei true wird der Wert bei der ersten Ausführung in einem Tick gesetzt und verhindert, dass der Ketten-Befehlsblock im selben Tick erneut ausgeführt werden kann.
    • LastOutput: Die Ausgabe des letzten Befehls in Form eines JSON-Textes inklusive eines Zeitstempels. Diese Eigenschaft wird nach einem Befehl immer gefüllt, aber es wird nur im Befehlsblock angezeigt, wenn TrackOutput true ist.
    • powered: 1 oder 0 (true/false) - true, wenn der Befehlsblock durch ein Redstone-Signal aktiviert ist.
    • SuccessCount: Stärke des Signals, das ein Komparator, der direkt neben dem Befehlsblock platziert ist, ausgibt, wenn der Befehlsblock seinen Befehl erfolgreich ausführt und der Befehlsblock mit einem Eingangssignal aktiviert wurde.
    • TrackOutput: 1 oder 0 (true/false) - true, wenn die Ausgabe des letzten Befehls (siehe LastOutput) im Befehlsblock angezeigt wird.
    • UpdateLastExecution: Im Verketten-Modus: 1 oder 0 (true/false) - Standardwert ist true, wenn false kann der Ketten-Befehlsblock mehr als einmal pro Tick ausgeführt werden.

Bett

Bewegter Block

  • Bewegter Block hat die Blockobjekt-ID "piston"
    • Allgemeine Blockobjekteigenschaften
    • blockState: Der vom Kolben bewegte Block.
      • Name: ID-Name des Blockes.
      • Properties: Die Blockzustände (nur bei Blöcken, die unterschiedliche Blockzustände haben).
        • Name des Blockzustandes: Wert des Blockzustandes.
    • extending: 1 oder 0 (true/false) - true, wenn der Block gerade bewegt wird.
    • facing: Richtung in die der Block bewegt wird: 2 = nach Norden, 3 = nach Süden, 4 = nach Westen, 5 = nach Osten.
    • progress: Fortschritt, wie weit die Verschiebung des Blockes erfolgt ist (zwischen 0.0 und 1.0).
    • source: 1 oder 0 (true/false) - true, wenn der Block der Kolbenkopf ist. Beim Verschieben von Blöcken gehört auch der Kolbenkopf zu den bewegten Blöcken.

Braustand

  • Braustand hat die Blockobjekt-ID "brewing_stand"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • BrewTime: Zeit in Ticks, welche die Tränke schon gebraut wurden.
    • Fuel: Anzahl wie oft gebraut werden kann. Dabei wird der Wert pro Brauvorgang um 1 verringert. Ist der Wert <= 0 kann nicht gebraut werden.
    • Items: Liste der Gegenstandsdaten im Braustand mit Slot (von 0 bis 4): 0 = linker Slot (östliche Flasche), 1 = mittlerer Slot (nördliche Flasche), 2 = rechter Slot (südliche Flasche), 3 = oberer Slot (Zutat), 4 = Lohenstaub-Slot.

Endertruhe

Die Gegenstände der Endertruhe werden pro Spieler gespeichert, d. h. in den Spielerdaten.

Endportal

Endtransitportal

  • Endtransitportal hat die Blockobjekt-ID "end_gateway"
    • Allgemeine Blockobjekteigenschaften
    • Age: Alter des Transitportals in Ticks. Wenn dieser Wert kleiner als 200 ist, sendet das Transitportal einen lila Strahl aus
    • ExactTeleport: Optional. 1 oder 0 (true/false) - true, wenn der Ausgang genau bei ExitPortal sein soll. Ansonsten landet man an einem Punkt mit ­einem gewissen Abstand zu den Koordinaten. Zudem können ohne diese Eigenschaft nur Koordinaten über einem soliden Block angesteuert werden.
    • ExitPortal: Optional. Die Koordinaten, die beim Durchgehen angesteuert werden. Bei keiner Angabe wird man entweder nicht teleportiert oder ein natürlich entstandenes Portal teleportiert einen zu einem vom Spiel festgelegten Ort
      • X: Die X-Koordinate des Zielpunktes.
      • Y: Die Y-Koordinate des Zielpunktes.
      • Z: Die Z-Koordinate des Zielpunktes.

Konstruktionsblock

  • Konstruktionsblock hat die Blockobjekt-ID "structure_block"
    • Allgemeine Blockobjekteigenschaften
    • author: Im SAVE-Modus der Name der Person, die den Blockbereich konstruiert hat. Im LOAD-Modus der Name der Person, die die Konstruktionsvorlage erstellt hat.
    • ignoreEntities: 1 oder 0 (true/false) - true, wenn im SAVE- und LOAD-Modus die im Blockbereich möglicherweise enthaltenen Objekte ignoriert werden sollen.
    • integrity: Im LOAD-Modus kann eine Konstruktion auch unvollständig geladen werden. Bei 0.0 wird kein Block geladen, bei 1.0 werden alle Blöcke geladen. Standard ist 1.
    • metadata: Im DATA-Modus wird hier ein Objektname oder ein Blockobjektname eingetragen. Der Konstruktionsblock steht dann für dieses Objekt oder Blockobjekt.
    • mirror: Im LOAD-Modus kann der Blockbereich gespiegelt werden. Standard = NONE.
    • mode: Modus: SAVE, LOAD, CORNER oder DATA.
    • name: Im SAVE- und LOAD-Modus der Name, unter dem der Blockbereich als Datei gespeichert wird.
    • posX: Im SAVE- und LOAD-Modus die X-Position des Blockbereiches relativ zum Konstruktionsblock.
    • posY: Im SAVE- und LOAD-Modus die Y-Position des Blockbereiches relativ zum Konstruktionsblock.
    • posZ: Im SAVE- und LOAD-Modus die Z-Position des Blockbereiches relativ zum Konstruktionsblock.
    • powered: 1 oder 0 (true/false) - true, wenn der Konstruktionsblock durch ein Redstone-Signal aktiviert ist.
    • rotation: Im LOAD-Modus kann der Blockbereich gedreht werden. Standard = NONE.
    • seed: Wenn im LOAD-Modus eine Konstruktion unvollständig geladen wird (integrity ist nicht 1), gibt der Startwert seed an, welche Blöcke weggelassen werden. Standrad ist 0.
    • showair: 1 oder 0 (true/false) - true, wenn im SAVE-Modus unsichtbare Blöcke angezeigt werden sollen.
    • showboundingbox: 1 oder 0 (true/false) - true, wenn im LOAD-Modus ein Begrenzungsrahmen angezeigt wird.
    • sizeX: Im SAVE- und LOAD-Modus die Größe des Blockbereiches in X-Richtung.
    • sizeY: Im SAVE- und LOAD-Modus die Größe des Blockbereiches in Y-Richtung.
    • sizeZ: Im SAVE- und LOAD-Modus die Größe des Blockbereiches in Z-Richtung.

Kopf

  • Kopf hat die Blockobjekt-ID "skull"
    • Allgemeine Blockobjekteigenschaften
    • ExtraType: Nur bei der Block-ID player_head: der Name des Spielers, dem der Kopf gehört[1]. Wenn der Spielername nicht bei Mojang registriert oder der Skin-Server von Mojang offline ist, wird der Standardkopf angezeigt. Die Eigenschaft wird gelöscht, sobald der Spielerkopf generiert wurde. Das Ergebnis wird unter Owner gespeichert.
    • Owner: Daten des Spielers, zu dem der Kopf gehört.
        • Id: Spieler-UUID.
        • Name: Spielername.
        • Properties: Eigenschaften des Kopfes.
          • textures: Texturen des Kopfes.
            • Eine Textur.
              • Signature: Optional eine Signatur.
              • Value: Ein JSON-Objekt als Base64-Zeichenkette. Für Base64 gibt es Online-Decodierungen, z.B. diese.
                • Das namenlose Texturobjekt.
                  • profileId: Optional die UUID des Spielers ohne Bindestriche.
                  • profileName: Optional der Spielername.
                  • isPublic: true oder false. Der Wert true ist Standard und kann weggelassen werden. false gibt an, dass die Textur-URL nicht öffentlich zugänglich ist.
                  • textures: Die Texturen.
                    • SKIN: Skin-Textur.
                      • url: Die URL der Skin-Textur.
                    • CAPE: Umhang-Textur.
                      • url: Die URL der Umhang-Textur. Ein Umhang wird bei Köpfen nicht angezeigt. Ansonsten wird ein Umhang nur angezeigt, wenn in den Account-Daten des Spielers ein Umhang durch Mojang eingetragen wurde.
                  • timestamp: Optional die Unixzeit in Millisekunden des Zeitpunktes, wann die Texturdaten abgerufen wurden. Die Umrechnung von Unix-Sekunden in Realzeit ist z. B. hier möglich, man muss aber vorher die letzten drei Stellen vom timestamp entfernen, da es Millisekunden sind.

Leuchtfeuer

  • Leuchtfeuer hat die Blockobjekt-ID "beacon"
    • Allgemeine Blockobjekteigenschaften
    • Levels: Die Anzahl der Stufen der Pyramide, auf der das Leuchtfeuer steht. Eine Änderung dieses Wertes über Befehle ist nicht möglich, das Spiel aktualisiert diese Eigenschaft immer anhand der existierenden Pyramide.
    • Primary: Die Statuseffekt-ID der primären Auswahl. 0 bedeutet keine Auswahl. Das Setzen eines Statuseffektes über Befehle ist nicht möglich, das Spiel aktualisiert diese Eigenschaft immer anhand der im Leuchtfeuer vorgenommenen Einstellung.
    • Secondary: Die Statuseffekt-ID der sekundären Auswahl. 0 bedeutet keine Auswahl. Auch hier aktualisiert das Spiel diese Eigenschaft immer anhand der im Leuchtfeuer vorgenommenen Einstellung.

Ofen

  • Ofen hat die Blockobjekt-ID "furnace"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • BurnTime: Zeit in Ticks die verbleiben, bis der Ofen keinen Brennstoff mehr hat.
    • CookTime: Zeit in Ticks, die der aktuelle Gegenstand schon der Ofenhitze ausgesetzt war. Steigt bis 200 (10 Sekunden), dann ist der Gegenstand geschmolzen bzw. gebraten. Sobald der Ofen keinen Brennstoff mehr hat (BurnTime erreicht 0), bleibt die CookTime erhalten. Wenn Brennstoff nachgelegt wird, läuft sie weiter.
    • CookTimeTotal: Zeit in Ticks die der Gegenstand benötigt, um geschmolzen bzw. gebraten zu werden.
    • Items: Liste der Gegenstandsdaten im Ofen mit Slot (von 0 bis 2). Slot 0 enthält die Gegenstände, die der Hitze ausgesetzt werden, Slot 1 enthält das Brennmaterial, Slot 2 enthält das Ergebnis.
    • RecipesUsedSize: Anzahl der zuletzt angewendeten Rezepte mit gleichem Endprodukt. Üblicherweise ist das 1. Aber mit einem Datenpaket kann man weitere Ofenrezepte für dasselbe Endprodukt mit unterschiedlichen Erfahrungspunkten hinzufügen. Wendet man diese Rezepte abwechselnd an, stapeln sich dieselben Endprodukte. Damit das Spiel beim Herausnehmen der Endprodukte die korrekte Anzahl an Erfahrungspunkten vergeben kann, merkt es sich die Anzahl der Endprodukte für jedes unterschiedliche Ofenrezept, bis das Endprodukt entnommen ist. Beispiel: Es gibt das Original-Ofenrezept minecraft.jar/data/minecraft/recipes/cactus_green.json für das Kochen von Kakteen zu Kaktusgrün, das 1 Erfahrungspunkt bringt. Ein eigenes Ofenrezept .minecraft/saves/eigener-weltordner/datapacks/eigenes-datenpaket/data/eigener-namensraum/recipes/laub_zu_kaktusgruen.json für das Kochen von Laub zu Kaktusgrün könnte 2 Erfahrungspunkte bringen. Kocht man dreimal Laub und einen Kaktus, kann das Spiel trotz Wechsel des Rohstoffes die 7 Erfahrungspunkte korrekt vergeben.
    • RecipeLocation0: Üblicherweise der Name des zuletzt angewendeten Ofenrezepts. Hat man jedoch zuletzt abwechselnd unterschiedliche Ofenrezepte für dasselbe Endprodukt angewendet, werden diese mit fortlaufender Nummer gemerkt. Im Beispiel wäre das RecipeLocation0:"eigener-namensraum:laub_zu_kaktusgruen" und RecipeLocation1:"minecraft:cactus_green".
    • RecipeAmount0: Die Anzahl der Endprodukte, die mit dem Ofenrezept dieser fortlaufenden Nummer zuletzt hergestellt wurden. Im Beispiel wäre das RecipeAmount0:3 (3 mal RecipeLocation0 = Laubrezept) und RecipeAmount1:1 (1 mal RecipeLocation1 = Kaktusrezept).

Plattenspieler

Redstone-Komparator

Schild

Die Anzahl der dargestellten Zeichen hängt von der Zeichenbreite ab. Beispielsweise passen 15 "m" in eine Zeile oder 45 Punkte. Was nicht dargestellt werden kann, wird verworfen.

Shulkerkiste

  • Shulkerkiste hat die Blockobjekt-ID "shulker_box"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • Items: Liste der Gegenstandsdaten in der Kiste mit Slot (von 0 bis 26, wobei sich Slot 0 in der oberen linken Ecke befindet).
    • LootTable: Optional. Die Beutetabelle, die verwendet wird, um den Inhalt der Kiste zu generieren, sobald sie das nächste Mal geöffnet wird. [Anmerkung 1]
    • LootTableSeed: Optional. Startwert, der beim Generieren des Kisteninhalts verwendet wird. Wenn diese Eigenschaft fehlt oder 0 ist, wird ein zufälliger Startwert verwendet.[Anmerkung 1]
  1. a b Die beiden Eigenschaften LootTable und LootTableSeed werden gelöscht, sobald die Gegenstände generiert wurden.

Spawner

  • Spawner hat die Blockobjekt-ID "mob_spawner"
    • Allgemeine Blockobjekteigenschaften
    • Delay: Zeit in Ticks, bis zum nächsten Spawn-Ereignis. Der Wert wird automatisch mit einem zufälligen Wert im Bereich MinSpawnDelay bis MaxSpawnDelay belegt und bis 0 herunter gezählt, solange sich ein Spieler im mit RequiredPlayerRange festgelegten Umkreis des Spawners befindet. Je näher der Wert an 0 kommt, desto schneller dreht sich die kleine Figur im Spawner. Bei 0 werden die Spawner-Flammen kurzzeitig zahlreicher und das Objekt wird gespawnt, falls alle Spawn-Bedingungen erfüllt sind. Der Wert -1, der vom Spiel selber nicht gesetzt wird, bewirkt einen Abbruch des aktuellen Spawn-Vorgangs und startet einen neuen Spawn-Vorgang mit dem nächsten zufälligen Objekt aus SpawnPotentials.
    • MaxNearbyEntities: Eine der Spawn-Bedingungen: Wenn die Anzahl der Objekte mit der aktuellen Spawn-ID in dem mit RequiredPlayerRange festgelegten Umkreis des Spawners diesen Wert erreicht hat, wird kein neues Objekt mit dieser ID gespawnt. Es wird nur die ID verglichen, nicht die Ausstattung des Objektes.
    • MaxSpawnDelay: Maximalwert für die zufällige Berechnung von Delay. Der Wert muss mindestens 1 betragen.
    • MinSpawnDelay: Minimalwert für die zufällig Berechnung von Delay. Der Wert darf höchstens MaxSpawnDelay betragen.
    • RequiredPlayerRange: Der Radius in Blöcken (und somit ein würfelförmiger Bereich) um den Spawner. Sobald ein Spieler diesen Umkreis betritt, wird der Spawner aktiviert, was an den züngelnden Flammen erkennbar ist. Bei einem inaktiven Spawner sind keine Flammen zu sehen. Dazu muss auch MaxNearbyEntities belegt sein.
    • SpawnCount: Anzahl der Objekte, die mit jedem Spawn erzeugt werden sollen, wobei insgesamt MaxNearbyEntities nicht überschritten wird.
    • SpawnData: Die Eigenschaften des nächsten Spawn-Objektes. Wenn nur eine ID angegeben ist, wird dieses Objekt mit seinen Standard-Eigenschaften gespawnt, falls das möglich ist. Wenn SpawnData fehlt oder leer ist, wird es automatisch mit der ID des Schweins belegt. Das Spiel generiert aus SpawnData eine verkleinerte Figur inklusive festgelegter Rüstung und Gegenstände in den Händen und lässt sie im Spawner kreisen. Nach einem erfolgreichen Spawn-Ereignis wird das nächste zufällige Spawn-Objekt aus SpawnPotentials gewählt und die Daten nach SpawnData übertragen.
    • SpawnPotentials: Optional eine Liste von Objekten. Das Spiel wählt nach jedem erfolgreichen Spawn-Ereignis per Zufall eins davon aus und kopiert die Daten nach SpawnData für den nächsten Spawn-Vorgang. Wenn SpawnPotentials nicht belegt ist, wird automatisch aus SpawnData ein Eintrag generiert, wodurch immer dasselbe Objekt gespawnt wird.
      • Ein mögliches Spawn-Objekt.
        • Entity: Das zu spawnende Objekt.
        • Weight: Auswahl-Wahrscheinlichkeit für dieses Objekt im Vergleich zu den anderen hinterlegten Auswahl-Wahrscheinlichkeiten. Der Wert muss mindestens 1 sein.
    • SpawnRange: Blockradius für das Quadrat um den Spawner, in dem die Objekte zufällig gespawnt werden. Der Spawnbereich ist 2 Blöcke hoch gemessen vom Fuß des Spawners.

Das Spawnen unterliegt außerdem den Spawn-Bedingungen für das entsprechende Objekt, was für Monster meist ein Lichtlevel unter 8 bedeutet, für Landtiere einen Grasboden, etc. Auch sollte der Spawner auf dem Boden stehen, damit die Kreaturen nicht in der Luft gespawnt werden.

Spender

  • Spender hat die Blockobjekt-ID "dropper"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • Items: Liste der Gegenstandsdaten im Spender mit Slot (von 0 bis 8, wobei sich Slot 0 in der oberen linken Ecke befindet).
    • LootTable: Optional. Die Beutetabelle, die verwendet wird, um den Inhalt des Spenders zu generieren, sobald er das nächste Mal geöffnet wird.[Anmerkung 1]
    • LootTableSeed: Optional. Startwert, der beim Generieren des Spenderinhalts verwendet wird. Wenn diese Eigenschaft fehlt oder 0 ist, wird ein zufälliger Startwert verwendet.[Anmerkung 1]
  1. a b Die beiden Eigenschaften LootTable und LootTableSeed werden gelöscht, sobald die Gegenstände generiert wurden.

Tageslichtsensor

Trichter

  • Trichter hat die Blockobjekt-ID "hopper"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • Items: Liste der Gegenstandsdaten im Trichter mit Slot (von 0 bis 4).
    • TransferCooldown: Zeit in Ticks bis zum nächsten Transportvorgang. Von 8 runterzählend auf 1. 0 wenn kein Transportvorgang.
    • LootTable: Optional. Die Beutetabelle, die verwendet wird, um den Inhalt der Truhe zu generieren, sobald sie das nächste Mal geöffnet wird.[Anmerkung 1]
    • LootTableSeed: Optional. Startwert, der beim Generieren des Truheninhalts verwendet wird. Wenn diese Eigenschaft fehlt oder 0 ist, wird ein zufälliger Startwert verwendet.[Anmerkung 1]
  1. a b Die beiden Eigenschaften LootTable und LootTableSeed werden gelöscht, sobald die Gegenstände generiert wurden.

Truhe

  • Truhe und Redstone-Truhe haben die Blockobjekt-ID "chest" und "trapped_chest"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • Items: Liste der Gegenstandsdaten in der Truhe mit Slot (von 0 bis 26, wobei sich Slot 0 in der oberen linken Ecke befindet).
    • LootTable: Optional. Die Beutetabelle, die verwendet wird, um den Inhalt der Truhe zu generieren, sobald sie das nächste Mal geöffnet wird.[Anmerkung 1]
    • LootTableSeed: Optional. Startwert, der beim Generieren des Truheninhalts verwendet wird. Wenn diese Eigenschaft fehlt oder 0 ist, wird ein zufälliger Startwert verwendet.[Anmerkung 1]
  1. a b Die beiden Eigenschaften LootTable und LootTableSeed werden gelöscht, sobald die Gegenstände generiert wurden.

Doppeltruhen sind zwei nebeneinander platzierte Truhen-Blöcke mit jeweils eigenen Blockobjektdaten.

Werfer

  • Werfer hat die Blockobjekt-ID "dispenser"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.
    • Lock: Optional: der Name des Schlüssels, um diesen Behälter zu öffnen bzw. an das Inventar zu gelangen. Ist dieser Wert belegt, lässt sich der Behälter nur öffnen, wenn der Spieler einen Gegenstand in der Hand hält, dessen Name (siehe Gegenstandsdaten) mit dem Wert dieser Eigenschaft identisch ist. Dabei ist auf Groß- und Kleinschreibung zu achten. Der Behälter wird entsperrt, indem der Wert mit dem Befehl /data merge block x y z {Lock:""} geleert wird.
    • Items: Liste der Gegenstandsdaten im Werfer mit Slot (von 0 bis 8, wobei sich Slot 0 in der oberen linken Ecke befindet).
    • LootTable: Optional. Die Beutetabelle, die verwendet wird, um den Inhalt des Werfers zu generieren, sobald er das nächste Mal geöffnet wird.[Anmerkung 1]
    • LootTableSeed: Optional. Startwert, der beim Generieren des Werferinhalts verwendet wird. Wenn diese Eigenschaft fehlt oder 0 ist, wird ein zufälliger Startwert verwendet.[Anmerkung 1]
  1. a b Die beiden Eigenschaften LootTable und LootTableSeed werden gelöscht, sobald die Gegenstände generiert wurden.

Zaubertisch

  • Zaubertisch hat die Blockobjekt-ID "enchanting_table"
    • Allgemeine Blockobjekteigenschaften
    • CustomName: Optional können Namen per Amboss oder als JSON-Text vergeben werden (Beispiel: CustomName:"{\"text\":\"Wiki\"}"). Der Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten. Zusätzlich wird er auch im Inventar angezeigt.

Einzelnachweise

Geschichte

Versionsgeschichte der Java Edition
Indev 24. Januar 2010
  • Das erste Blockobjekt ist die Truhe mit ihrem Inventar
  • Die Blockobjektdaten werden in den Weltdaten als "TileEntities" im Indev Level Format gespeichert
Infdev 27. Februar 2010
  • Die Entwicklung grenzenloser Welten beginnt, die Welt wird in Chunks aufgeteilt
  • Die Blockobjekte gehören nicht mehr zu den Weltdaten, sondern werden in den Chunkdaten gespeichert (Alpha Level Format)
Beta 1.7
  • Der Kolben wird hinzugefügt, er kann nur Blöcke verschieben, die keine Blockobjektdaten haben
Vollversion 1.8 (14w02a)
Vollversion 1.11
16w32a
  • Die Blockobjekt-IDs haben sich geändert. Beispiel: „Control” zu „command_block”
16w35a
  • Ein benutzerdefinierter Name bleibt beim Abbauen/Setzen oder beim Droppen erhalten
Vollversion 1.13 (17w45b)