Guides / Commandes et données

/execute : pourquoi l'ordre as/at est important et comment store fonctionne réellement

La plupart des chaînes execute cassées viennent de la confusion entre qui exécute la commande et où elle s'exécute. Voici ce que chaque sous-commande change, et l'ordre qui corrige tout.

2026-07-20

/execute est une commande qui se fait passer pour un langage de script. Presque chaque échec remonte à deux sous-commandes qui semblent faire la même chose et qui ne la font pas.

as change QUI. at change OÙ.

• as <target> — échange l'exécutant. @s désigne désormais cette entité. La position ne bouge pas.
• at <target> — échange la position, la rotation et la dimension. L'exécutant ne change pas.

Donc ceci ne fait rien d'utile :

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

Elle s'exécute une fois par zombie, mais toujours à vos pieds, donc elle place un bloc encore et encore. La correction, c'est les deux :

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

at @s se réancre sur le zombie que as vient de sélectionner. as … at @s est l'association la plus courante de toute la commande, et oublier at @s est le bug le plus fréquent.

L'ordre va de gauche à droite, et il se cumule

Les sous-commandes s'exécutent en séquence, chacune modifiant le contexte que voit la suivante :

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

1. as @a — une passe par joueur
2. at @s — se déplacer vers ce joueur
3. positioned ^ ^ ^3 — 3 blocs devant l'endroit où il regarde

Intervertissez les étapes 2 et 3 et positioned ^ ^ ^3 est calculé à partir de votre position et orientation — puis at @s le jette en se recalant sur le joueur, donc le décalage est entièrement perdu.

Caret contre tilde

• ~ ~ ~ — relatif à la position, aligné sur les axes du monde
• ^ ^ ^ — relatif à l'orientation : gauche, haut, avant

Les coordonnées caret sont la raison pour laquelle positioned ^ ^ ^3 signifie « devant » et ~ ~ ~3 signifie « 3 blocs au sud ». Mélanger les deux notations dans un même triplet de coordonnées est une erreur de syntaxe.

store est une valeur de retour, pas une variable

store capture ce que la commande renvoie — généralement un nombre de succès ou une valeur de résultat :

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

Deux choses que les gens ratent :

• result contre success. result est le nombre que produit la commande ; success vaut 1 ou 0 selon qu'elle s'est exécutée. Compter des entités nécessite result.
• store se place avant run, et il s'applique à la commande qui suit run, pas à la chaîne de sous-commandes.

if contre unless court-circuite

if et unless filtrent — la chaîne s'arrête là quand le test échoue. Plusieurs clauses if forment un ET. Il n'y a pas de OU ; cela nécessite deux commandes séparées ou un prédicat.

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

Construisez la chaîne une sous-commande à la fois, avec le contexte affiché à chaque étape, dans le Advanced Command Builder — il couvre aussi data, item, loot, schedule, particle et playsound depuis le même formulaire.

Commandes avancées — Execute et Data →