/execute: Warum die Reihenfolge von as/at wichtig ist und wie store wirklich funktioniert
Die meisten kaputten execute-Ketten entstehen aus der Verwechslung davon, wer den Befehl ausführt und wo er ausgeführt wird. Hier steht, was jedes Subkommando ändert – und welche Reihenfolge das Problem löst.
/execute ist ein einziger Befehl, der vorgibt, eine Skriptsprache zu sein. Fast jeder Fehler lässt sich auf zwei Subkommandos zurückführen, die klingen, als würden sie dasselbe tun – und es nicht tun.
as ändert WER. at ändert WO.
as <target>— tauscht den Ausführenden aus.@sbedeutet jetzt diese Entität. Die Position bewegt sich nicht.at <target>— tauscht Position, Blickrichtung und Dimension aus. Der Ausführende ändert sich nicht.
Das hier bringt also nichts:
execute as @e[type=zombie] run setblock ~ ~ ~ stoneEs läuft einmal pro Zombie, aber immer an deinen Füßen, platziert also immer wieder denselben Block. Die Lösung ist beides:
execute as @e[type=zombie] at @s run setblock ~ ~ ~ stoneat @s verankert neu beim Zombie, den as gerade ausgewählt hat. as … at @s ist das mit Abstand häufigste Paar im ganzen Befehl, und at @s zu vergessen ist der häufigste Fehler überhaupt.
Die Reihenfolge geht von links nach rechts und summiert sich
Subkommandos laufen nacheinander ab, und jedes verändert den Kontext, den das nächste sieht:
execute as @a at @s positioned ^ ^ ^3 run particle flameas @a— ein Durchlauf pro Spielerat @s— zu diesem Spieler wechselnpositioned ^ ^ ^3— 3 Blöcke vor der Stelle, wohin er schaut
Vertausche Schritt 2 und 3, und positioned ^ ^ ^3 wird von deiner Position und Blickrichtung aus berechnet — dann wirft at @s das weg, indem es zum Spieler zurückspringt, sodass der Versatz komplett verloren geht.
Caret versus Tilde
~ ~ ~— relativ zur Position, an den Weltachsen ausgerichtet^ ^ ^— relativ zur Blickrichtung: links, oben, vorwärts
Caret-Koordinaten sind der Grund, warum positioned ^ ^ ^3 „vor" bedeutet und ~ ~ ~3 „3 Blöcke nach Süden". Die beiden Schreibweisen in einem Koordinatentripel zu mischen, ist ein Syntaxfehler.
store ist ein Rückgabewert, keine Variable
store fängt ab, was der Befehl zurückgibt — meist eine Erfolgsanzahl oder einen Ergebniswert:
execute store result score @s Count run data get entity @s InventoryZwei Dinge, die Leute falsch machen:
resultversussuccess.resultist die Zahl, die der Befehl produziert;successist 1 oder 0 dafür, ob er ausgeführt wurde. Zum Zählen von Entitäten braucht manresult.storesteht vorrun, und es gilt für den Befehl nachrun, nicht für die Subkommando-Kette.
if versus unless schalten früh ab
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 getrennte Befehle oder ein Prädikat.
execute as @a if entity @s[gamemode=survival] if score @s Lives matches 1.. run ...Baue die Kette Subkommando für Subkommando auf, mit dem jeweils angezeigten Kontext, im Advanced Command Builder — er deckt außerdem data, item, loot, schedule, particle und playsound im selben Formular ab.