Minecraft 1.12: Ajout du selecteur @s

C'est une nouveauté que personne n'avait découvert dans la dernière snapshot, et pourtant elle était belle et bien présent, et elle risque d'être très utile pour tous les redstoneurs: le nouveau sélecteur @s permet de selectionner l'entité qui tape la commande.

Les sélecteurs permettent, dans les commandes, de remplacer le nom d'un joueur par un code dynamique, permettant de filtrer une recherche. La syntaxe peut vite devenir complexe, il existe même des générateurs de sélecteurs en ligne.

Il existait jusqu'à présent 4 sélecteurs:

• @p qui cibler le joueur le plus proche de l'entité qui executé la commande
• @r qui cibler un joueur au hasard
• @a qui cibler tous les joueurs
• @e qui cibler toutes les entités (joueurs et mobs)

Mais tous ces sélecteurs avaient un gros défaut: pour cibler l'entité (ou le joueur), le jeu devait faire la liste de toutes les entités, puisque de rechercher celle qui correspondait le mieux au critère demandé, un fonctionnement particulièrement gourmande en ressource, ce qui a conduit les développeurs de Minecraft PE a créer un nouveau sélecteur, beaucoup plus rapide, le sélecteur @s.

Le nouveau sélecteur @s est extrêmement simple: il cycle l'entité qui exécute la commande, par exemple:

Ici c'est moi qui tape la commande, donc c'est mon nom qui apparaît. Dans ce cas de figure, le résultat est donc rigoureusement identique au sélecteur @p, mais en beaucoup plus rapide.

Allons plus loin avec l'exemple suivant:

Ici la commande /execute cible tous les mobs de la map, en leur demandant d'executer la commande précédente. le selecteur @s de la commande cible donc, tour a tour, chacun des mobs ! Ce comportement aurait était très difficile a reproduire dans le selecteur @s. Il aurait fallu filtrer les entités sur différent critère, un filtrage pas toujours simple a faire suivant les cas, et surtout gourmand en ressource pour l'ordinateur.

Un dernier exemple qui montre que ce sélecteur est vraiment différent:

Il s'agit toujours de la même commande, mais cette fois dans un bloc de commande. Qu'elle est l'entité qui execute la commande ? Aucune, ce n'est pas une entité, c'est un bloc, donc la commande tombe en erreur, le selecteur @s n'a rien trouvé.

Le gain en performance pourra être encore meilleur sur des commandes récursive, lorsqu'un /execute execute un autre /execute, etc., par exemple:
/execute @s ~ ~ ~ /execute @s ~ ~ ~ /execute @s ~ ~ ~ /say hi
Ici la commande est rapide, @s ne cible qu'une entité, pas de recherche a faire. Pour faire la même chose avant, il aurait fallu faire:
/execute @e[r=0,c=1] ~ ~ ~ /execute @e[r=0,c=1] ~ ~ ~ /execute @e[r=0,c=1] ~ ~ ~ /say hi
Hors dans cet exemple le nombre d'entité a recherche est exponentiel, les performances du jeu chute rapidement.
L'exemple peut paraitre bete, pourquoi faire ça ? Dans certain cas on a pas le choix, par exemple si on veux selectionner plusieurs tag, il n'est possible d'en donnée qu'une seul dans le selecteur, donc il faut multiplier les /execute:
/execute @e[tag=tag1] /execute @s[tag=tag2] /execute @s[tag=tag3 /say hi

Et c'est sans parler de cas où le selecteur "@e[r=0,c=1]" ne fonctionnait même pas, par exemple dans le cas d'une map ou plusieurs armor stand serait superposés.

Il est d'ore est déjà possible de tester ce sélecteur puisqu'il est disponible dans la snapshot 17w16b !