/execute: waarom de as/at-volgorde uitmaakt en hoe store echt werkt

De meeste kapotte execute-ketens ontstaan door verwarring over wie de opdracht uitvoert en waar deze wordt uitgevoerd. Dit is wat elke subopdracht verandert, en de volgorde die het oplost.

2026-07-20

/execute is one command pretending to be a scripting language. Almost every failure traces to two subcommands that sound like they do the same thing and do not.

as verandert WIE. at verandert WAAR.

• as <target> — wisselt de uitvoerder. @s now means that entity. **The position does

niet beweegt.**

• at <target> — wisselt de positie, rotatie en dimensie. **De uitvoerder verandert

niet.**

Dit doet dus niets nuttigs:

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

Het wordt eenmaal per zombie uitgevoerd, maar altijd bij jouw voeten, dus het plaatst steeds hetzelfde blok. De oplossing is beide:

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

at @s re-anchors to the zombie that as just selected. as … at @s is the single most common pairing in the whole command, en het vergeten van at @s is the single most common bug.

Volgorde is van links naar rechts, en stapelt zich op

Subopdrachten worden achter elkaar uitgevoerd, waarbij elk de context voor de volgende aanpast:

execute as @a at @s positioned ^ ^ ^3 run particle flame

1. as @a — one pass per player
2. at @s — move to that player
3. positioned ^ ^ ^3 — 3 blocks in front of where they are kijkend

Draai stap 2 en 3 om en de caret-verschuiving wordt gemeten vanaf jouw rotatie in plaats van die van hen.

Caret versus tilde

• ~ ~ ~ — relative to positie, uitgelijnd op de wereldassen
• ^ ^ ^ — relative to kijkrichting: links, omhoog, vooruit

Caret-coördinaten zijn de reden dat positioned ^ ^ ^3 means "in front of" and ~ ~ ~3 means "3 blocks south". Mixing the two notations in one coordinate triple is a syntax error.

store is een retourwaarde, geen variabele

store captures what the command retourneert — meestal een succesaantal of een resultaatwaarde:

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

Twee dingen die vaak fout gaan:

• result versus success. result is the number the command produces; success

is 1 of 0 voor of het is uitgevoerd. Entiteiten tellen vereist result.

• store goes before run, en het is van toepassing op de opdracht na run, not to the

subopdrachtenketen.

if versus unless breekt vroegtijdig af

if and unless filter — the chain stops there when the test fails. Multiple if clauses are an AND. There is no OR; that needs two separate commands or a predicate.

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

Bouw de keten subopdracht voor subopdracht, met de context bij elke stap weergegeven, in de Geavanceerde opdrachtbouwer — het ondersteunt ook data, item, loot, schedule, particle en playsound vanuit hetzelfde formulier.