/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.@sbezieht 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
as @a— ein Durchlauf pro Spielerat @s— zum jeweiligen Spieler wechselnpositioned ^ ^ ^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:
resultversussuccess.resultist die Zahl, die der Befehl erzeugt;successist 1 oder 0, je nachdem, ob er ausgeführt wurde. Zum Zählen von Entitäten braucht manresult.storekommt vorrun, und es bezieht sich auf den Befehl nachrun, 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.