Guides / Commands & Data

/execute: Warum die Reihenfolge von as/at wichtig ist und wie store wirklich funktioniert

Die meisten fehlerhaften Execute-Ketten entstehen durch die Verwechslung, wer den Befehl ausführt und wo er ausgeführt wird. Hier erfährst du, was jeder Unterbefehl ändert und welche Reihenfolge das Problem behebt.

/execute ist ein Befehl, der sich als Skriptsprache ausgibt. Fast jeder Fehler lässt sich auf zwei Unterbefehle zurückführen, die gleich klingen, es aber nicht sind.

as ändert WER. at ändert WO.

  • as <target> — tauscht den Ausführenden. @s bezieht sich nun auf diese Entität. Die Position ändert sich nicht.
  • at <target> — tauscht die Position, Rotation und Dimension. Der Ausführende ändert sich nicht.

Das hier ist also nutzlos:

execute as @e[type=zombie] run setblock ~ ~ ~ stone

Es wird einmal pro Zombie ausgeführt, aber immer an deinen Füßen, sodass immer wieder derselbe Block gesetzt wird. Die Lösung ist beides:

execute as @e[type=zombie] at @s run setblock ~ ~ ~ stone

at @s verankert sich am Zombie, den as gerade ausgewählt hat. as … at @s ist die häufigste Kombination im gesamten Befehl, und das Vergessen von at @s ist der häufigste Fehler.

Die Reihenfolge ist von links nach rechts und sie summiert sich

Unterbefehle werden nacheinander ausgeführt, wobei jeder den Kontext für den nächsten ändert:

execute as @a at @s positioned ^ ^ ^3 run particle flame
  1. as @a — ein Durchlauf pro Spieler
  2. at @s — zum jeweiligen Spieler wechseln
  3. positioned ^ ^ ^3 — 3 Blöcke vor der Blickrichtung des Spielers

Tauscht man Schritt 2 und 3, wird der Caret-Offset von deiner Rotation statt von ihrer gemessen.

Caret versus Tilde

  • ~ ~ ~ — relativ zur Position, ausgerichtet an den Weltachsen
  • ^ ^ ^ — relativ zur Blickrichtung: links, oben, vorne

Caret-Koordinaten sind der Grund, warum positioned ^ ^ ^3 „vorne“ und ~ ~ ~3 „3 Blöcke südlich“ bedeutet. Das Mischen der beiden Notationen in einem Koordinatentripel ist ein Syntaxfehler.

store ist ein Rückgabewert, keine Variable

store erfasst, was der Befehl zurückgibt — normalerweise eine Erfolgsanzahl oder einen Ergebniswert:

execute store result score @s Count run data get entity @s Inventory

Zwei Dinge, die Leute falsch verstehen:

  • result versus success. result ist die Zahl, die der Befehl erzeugt; success ist 1 oder 0, je nachdem, ob er ausgeführt wurde. Zum Zählen von Entitäten braucht man result.
  • store kommt vor run, und es bezieht sich auf den Befehl nach run, nicht auf die Unterbefehlskette.

if versus unless Kurzschlüsse

if und unless filtern — die Kette stoppt dort, wenn der Test fehlschlägt. Mehrere if-Klauseln sind ein UND. Es gibt kein ODER; dafür braucht man zwei separate Befehle oder ein Prädikat.

execute as @a if entity @s[gamemode=survival] if score @s Lives matches 1.. run ...

Baue die Kette Unterbefehl für Unterbefehl auf, wobei der Kontext bei jedem Schritt angezeigt wird, im Advanced Command Builder — dieser deckt auch Daten, Gegenstände, Beute, Zeitpläne, Partikel und Sounds aus demselben Formular ab.

Erweiterte Befehle — Execute und Data →

More guides

Browse all →

Suchst du weitere Minecraft-Werkzeuge?

Eine Sammlung von Generatoren, Betrachtern und Konvertern direkt im Browser — alle kostenlos.