Hey tout le monde !
Je créées aujourd'hui cette discussion pour parler voire débattre des nouveautés que la 1.12 apporte à Minecraft, et plus précisément au Map making et au Command Blocks.
Pour les quelques personnes qui ne sont pas trop au courant de ce qui se passe, voici un petit rappel :
- Déjà, l'un des ajouts les plus mineurs (et pourtant !), l'ajout du nouveau sélecteur @s (de "self", "sois" en anglais) qui permet de cibler la/les entité(s) exécutant la commande.
- Ensuite, la suppression des Achievements pour l'avènement des Advancements. En sois, pour des joueurs survie, il n'y a pas grande différence outre la réorganisation en diverses onglets (un par dimension) et l'ajout de nouveaux défis. Mais pour les Map Maker, c'est la possibilité de créer ces propres succès !
- Enfin, sans doute le plus gros ajout ou tout du moins celui qui aura le plus d'impact sur l'avenir du command block, la commande /function. Je vais m'attarder un peu vers cette dernière afin que ce soit claire pour tout le monde. Il s'agit, pour les Map Makers, de pouvoir créer ce que l'on appelle des "Fonctions" dans le répertoire
"nom de la map/data/function" sous forme de fichier .txt (et .mcfunction pour la version final). Les command blockers peuvent ainsi placer des commandes dans ce fichier et les exécuter en une commande !
Voici un petit exemple :
j'ai un fichier nommé "Zombie" dans le répertoire "ma map/data/functions/MaFonction" contenant ceci :
Et que j'exécute la commande
Alors toutes les commandes du fichier seront exécuter sur moi.
(Je ferai sans doute un petit tutoriel écrit sur cette commande)
Maintenant que j'ai fais un petit debriefing, voici mon avis !
Le @s est un merveilleux ajout ! Il permet enfin de pouvoir cibler SEULEMENT le joueur qui exécute la commande (fonctionne donc avec un /execute aussi) sans à avoir faire du "r=0" par exemple, ou à remettre le même sélecteur des tas de fois. De plus, si l'on fait cette commande :
Alors la commande sera exécuté individuellement chez chacun des joueurs ! Donc chacun d'entre-eux dira son nom
Pour les advancements, on peut apparenté un peu ça à de la programmation événementielle, c'est donc un moyen bien plus efficace et précis de réaliser une commande à la résolution d'un évènement (Je peux par exemple déclencher un système si le joueur possède dans son inventaire 3 pommes, deux fleurs, 32 slimeballs renommées "Blobs" et que le joueur se trouve dans une Mansion du biome Mushroom) donc je vous laisse imaginer les possibilités !
Derniers points, et sans doute celui qui va révolutionner le Map making tel qu'on le connais, le système de fonction.
Effectivement, cela permet de faire tout un système dans un seul fichier texte, donc sans command block ! Imaginez donc une map pvp sans un seul command block ! Cela ouvre donc de grandes possibilités d'optimisation et d'organisation (pas vraiment de créations car le fonctionnement reste le même), il nous est ainsi possible d'utiliser les Rechercher/Remplacer des logiciels d'édition pour changer un tout les "ArmorStand" par des "armor_stand" d'un fichier de 1500 lignes par exemple ! Donc vraiment utile pour les mise à jours des systèmes en peu de temps. De plus, nous pouvons faire des système de coloration syntaxique qui permette de mieux s'y retrouver, voici un petit exemple :
Avec une coloration que j'ai créés. Si elle vous intéresse, vous pouvez la retrouver à ce lien (Oui, je fais du placement de produit pour moi-même).
Mais il y a tout de même quelques points négatifs ! Déjà, il n'est pas vraiment possible, outre par des tags, de faire du conditionnel, ensuite, nous ne pouvons pas faire de smart clock non plus (Un système permettant de mettre en conditionnal tout un système sans pour autant tous les mettre un par un résultant de la superposition de deux command block repeat, celui à la base de la chain comportant la condition, et le second étant en conditional), de plus, il n'est pas réellement possible de faire une commande du style du /stat qui requiert un bloc de command pour y récupérer l'output. Dernier aspect négatif, c'est pour le débogage qui n'est pas des plus pratiques. Si vous exécuter le /function dans votre chat, alors vous aurez l'output de chacune des commandes; mais pour un système de 150 commandes, bah le chat n'est pas assez grand pour déboguer...
De par ces quelques aspects négatifs, les command blocks gardent tout de même un certain avantage dans des situations particulières, mais il est de mon avis que le fichier texte va vite prendre le relais et, peut-être au fil du temps, remplacer le command block...
Qu'en pensez-vous ?
Je créées aujourd'hui cette discussion pour parler voire débattre des nouveautés que la 1.12 apporte à Minecraft, et plus précisément au Map making et au Command Blocks.
Pour les quelques personnes qui ne sont pas trop au courant de ce qui se passe, voici un petit rappel :
- Déjà, l'un des ajouts les plus mineurs (et pourtant !), l'ajout du nouveau sélecteur @s (de "self", "sois" en anglais) qui permet de cibler la/les entité(s) exécutant la commande.
- Ensuite, la suppression des Achievements pour l'avènement des Advancements. En sois, pour des joueurs survie, il n'y a pas grande différence outre la réorganisation en diverses onglets (un par dimension) et l'ajout de nouveaux défis. Mais pour les Map Maker, c'est la possibilité de créer ces propres succès !
- Enfin, sans doute le plus gros ajout ou tout du moins celui qui aura le plus d'impact sur l'avenir du command block, la commande /function. Je vais m'attarder un peu vers cette dernière afin que ce soit claire pour tout le monde. Il s'agit, pour les Map Makers, de pouvoir créer ce que l'on appelle des "Fonctions" dans le répertoire
"nom de la map/data/function" sous forme de fichier .txt (et .mcfunction pour la version final). Les command blockers peuvent ainsi placer des commandes dans ce fichier et les exécuter en une commande !
Voici un petit exemple :
j'ai un fichier nommé "Zombie" dans le répertoire "ma map/data/functions/MaFonction" contenant ceci :
Code:
#Mes commandes:
summon Zombie ~ ~ ~ {CustomName:"1"}
summon Zombie ~ ~ ~ {CustomName:"2"}
summon Zombie ~ ~ ~ {CustomName:"3"}
summon Zombie ~ ~ ~ {CustomName:"4"}
summon Zombie ~ ~ ~ {CustomName:"5"}
summon Zombie ~ ~ ~ {CustomName:"6"}
summon Zombie ~ ~ ~ {CustomName:"7"}
summon Zombie ~ ~ ~ {CustomName:"8"}
summon Zombie ~ ~ ~ {CustomName:"9"}
summon Zombie ~ ~ ~ {CustomName:"10"}
Code:
/function maFonction:Zombie(Je ferai sans doute un petit tutoriel écrit sur cette commande)
Maintenant que j'ai fais un petit debriefing, voici mon avis !
Le @s est un merveilleux ajout ! Il permet enfin de pouvoir cibler SEULEMENT le joueur qui exécute la commande (fonctionne donc avec un /execute aussi) sans à avoir faire du "r=0" par exemple, ou à remettre le même sélecteur des tas de fois. De plus, si l'on fait cette commande :
Code:
execute @a ~ ~ ~ say @sPour les advancements, on peut apparenté un peu ça à de la programmation événementielle, c'est donc un moyen bien plus efficace et précis de réaliser une commande à la résolution d'un évènement (Je peux par exemple déclencher un système si le joueur possède dans son inventaire 3 pommes, deux fleurs, 32 slimeballs renommées "Blobs" et que le joueur se trouve dans une Mansion du biome Mushroom) donc je vous laisse imaginer les possibilités !
Derniers points, et sans doute celui qui va révolutionner le Map making tel qu'on le connais, le système de fonction.
Effectivement, cela permet de faire tout un système dans un seul fichier texte, donc sans command block ! Imaginez donc une map pvp sans un seul command block ! Cela ouvre donc de grandes possibilités d'optimisation et d'organisation (pas vraiment de créations car le fonctionnement reste le même), il nous est ainsi possible d'utiliser les Rechercher/Remplacer des logiciels d'édition pour changer un tout les "ArmorStand" par des "armor_stand" d'un fichier de 1500 lignes par exemple ! Donc vraiment utile pour les mise à jours des systèmes en peu de temps. De plus, nous pouvons faire des système de coloration syntaxique qui permette de mieux s'y retrouver, voici un petit exemple :
Avec une coloration que j'ai créés. Si elle vous intéresse, vous pouvez la retrouver à ce lien (Oui, je fais du placement de produit pour moi-même).
Mais il y a tout de même quelques points négatifs ! Déjà, il n'est pas vraiment possible, outre par des tags, de faire du conditionnel, ensuite, nous ne pouvons pas faire de smart clock non plus (Un système permettant de mettre en conditionnal tout un système sans pour autant tous les mettre un par un résultant de la superposition de deux command block repeat, celui à la base de la chain comportant la condition, et le second étant en conditional), de plus, il n'est pas réellement possible de faire une commande du style du /stat qui requiert un bloc de command pour y récupérer l'output. Dernier aspect négatif, c'est pour le débogage qui n'est pas des plus pratiques. Si vous exécuter le /function dans votre chat, alors vous aurez l'output de chacune des commandes; mais pour un système de 150 commandes, bah le chat n'est pas assez grand pour déboguer...
De par ces quelques aspects négatifs, les command blocks gardent tout de même un certain avantage dans des situations particulières, mais il est de mon avis que le fichier texte va vite prendre le relais et, peut-être au fil du temps, remplacer le command block...
Qu'en pensez-vous ?
Dernière édition:
