État des services Mojang : Plus d'infos
La recherche se fait sur tous les élements du jeu. Rechercher un membre

[MàJ] Minecraft 1.13: Les commandes, /execute, sélecteurs, etc.

Le 10/08/2017 à 4h13

La version 1.13 sera définitivement la version qui casse tous, en particulier toutes les commandes. Mais c'est une décision assumée par Mojang, et Dinnerbone explique très bien ce choix: La version Minecraft 1.13 sera la version ou les ID seront supprimer. Dès lors de nombreuses commandes seront, de fait, cassé (suppression des datavalue, donc changement dans les paramètres). Donc quoi qu'il arrive la 1.13 devait casser de nombreuses commandes. C'est pourquoi Dinnerbone a choisit d'en profiter pour revoir toutes les commandes et les améliorer: Oui ça va tout casser, mais normalement plus rien ne sera cassé dans les futures versions de Minecraft ! Ça sera un moment difficile pour les mapmakers, mais normalement c'est a dernière fois qu'il devront tout refaire.


Si ce n'est pas déjà je vous invite a voir (ou revoir) nos précédents articles concernant les changements apportés aux commandes:

Suppression des DataValues, la suite
Les DataValues étant désormais supprimé, Dinnerbone a continué de modifier les commandes prenant en paramètre des DataValues ou des tag NBT:

/clear
Ancienne syntaxe:
/clear [<target>] [<item>] [<data>] [<count>] [<nbt>]
Suppression des paramètres data et nbt:
/clear [<target>] [<item>] [<count>]

/give
Ancienne syntaxe:
/give <players> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/give <players> <item> [<count>]

/replaceitem
Ancienne syntaxe:
/replaceitem block <pos> <slot> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/replaceitem block <pos> <slot> <item> [<count>]

Ancienne syntaxe:
/replaceitem entity <target> <slot> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/replaceitem entity <target> <slot> <item> [<count>]



Suppression de /toggledownfall
La commande /toggledownfall n'a plus vraiment d’intérêt sachant qu'il existe depuis un moment maintenant la commande /weather qui fait la même chose (en mieux).



Fusion des commandes /tp et /teleport
Dans la version 1.12 /tp et /teleport sont 2 commandes distinct. Certes elles ont un fonctionnement similaires, mais la syntaxe est légèrement différent, ainsi que leur éxécution.
Je ne peux que vous invité a lire les fiches de ces 2 commandes pour mieux comprendre leur fonctionnement respectif: Prenons l'exemple suivant (pris sur les fiches ci-dessus), que fait cette commande ?
/tp Notch ~ ~10 ~
/teleport Notch ~ ~10 ~
Les 2 commandes sont correcte, elles fonctionneront, mais ne feront pas la même chose.

/tp Notch ~ ~10 ~ ==> Téléporte le joueur 'Notch' 10 blocs plus haut.
/teleport Notch ~ ~10 ~ ==> Téléporte le joueur 'Notch' 10 blocs au dessus de la personne qui tape la commande.

Autrement dit, le tilde de la commande /tp est relatif à l'entité de destination, alors que pour la commande /teleport (comme dans toutes les autres commandes du jeu), le tilde est relatif au l'entité qui tape la commande.
C'est pourquoi Dinnerbone a supprimer la commande /tp, elle est remplacé par la commande /teleport (le /tp fonctionnera toujours, mais il sera un simple alias de /teleport).

Pour avoir a nouveau l'ancien comportement il faudra utiliser la commande /execute:
/execute as Notch then teleport @s ~ ~10 ~
Certe la commande est beaucoup plus longue que l'ancienne commande /tp, mais selon Dinnerbone celle-ci est beaucoup plus logique, et donc plus simple a comprendre.



Les sélecteurs:
Les sélecteurs ont déjà était grandement améliorés (ajout des paramètres multiples, des sélection par tag nbt, etc.). Mais ce n'est pas fini, Dinnerbone a encore annoncé de nouveau changement.
  • Les intervales:
Le premier est une nouvelle révolution pour les sélecteurs, une nouvelle syntaxe permettant d'indiquer des intervalles.
Si on souhaite sélectionner tous les joueurs avec un niveau d'XP entre 5 et 10 ?
Avant il fallait faire :
@p[lm=5,l=10]

Désormais un seul paramètre permet de le faire simplement:
@p[level=5..10]

Si on ne souhaite pas de min ou de max, c'est le même principe:
@p[level=..10]
@p[level=5..]


Tous les paramètres avec un "min" ou "max" sont concerné, (level, scoreboard, rotations, etc.).
  • "limit":
Le paramètre de sélecteur "c" a été renommé en "limit". Ce paramètre indique le nombre d'entité a sélectionner.
Mais contrairement à "c", "limit" n'accepte pas de valeur négative. Une valeur négative permettait de sélectionner les entité les plus éloigné. Pour cela un nouveau paramètre a été créer: "sort".
"sort" peut prendre les valeurs suivantes:
- "sort=nearest": sélectionne les entités les plus proche (valeur par défaut pour tous les sélecteurs sauf @r)
- "sort=furthest": sélectionne les entités les plus éloigné (l'équivalent de la valeur négative de "c")
- "sort=random": sélectionne les entités par ordre aléatoire (valeur par défaut pour le sélecteur @r)
- "sort=arbitrary": sélectionne les entités sans les classer, c'est l'option la plus rapide mais on ne doit l'utiliser que si l'ordre des entités n'a aucune importance dans la commande.
  • Paramètres renommés:
De nombreux paramètres de sélecteurs ont été renommés, en générale par un nom plus long mais plus explicite:
- "m" devient "gamemode"
- "l" et "lm" deviennent "level"
- "r" et "rm" deviennent "distance"
- "rx" et "rxm" deviennent "x_rotation"
- "ry" et "rym" deviennent "y_rotation"
- "c" devient "limit"



Retour de la commande /execute
Dans notre précédente news nous vous annoncions la suppression de la commande /execute, remplacé par les commandes /as, /at, /offset et /detect. Retour en arrière pour Dinnerbone, la commande /execute restera dans Minecraft 1.13, mais sa syntaxe sera totalement différente de ce que nous connaissons actuellement.

La cause de ce revirement de situation: la suppression des commandes /testfor/testforblock et /testforblocks. Dinnerbone pense qu'il serait plus simple d'inclure ces commandes de test dans la commande /execute, mais la syntaxe actuelle ne permettait pas cela. Il a donc ajouter 2 nouveaux paramètres à /execute: "if" et "unless".
Ainsi, la commande /as devient:
/execute as ...
La commande /at devient:
/execute at <entité> ...
La commande /offset a été remplacé par:
/execute at <x> <y> <z>
Et /detect est remplacé par la condition if.

Ainsi nous devrions avoir les syntaxes suivantes:
  • /execute as <entity> <command> runs <command> ==> Exécute en tant que l'entité, mais sans prendre sa position
  • /execute at <entity> <command> runs <command> ==> Utilise la position de l'entité pour exécuter la commande, mais sans changé l'entité source
  • /execute at <x y z> <command> runs <command> ==> Exécute la commande en utilisant la position indiqué
  • /execute (if|unless) block <x y z> <block> <command> ==> Exécute la commande if (ou l'inverse) le bloc à la position indiqué <x y z> correspond au bloc indiqué <block> (équivalent de la commande /testforblock)
  • /execute (if|unless) blocks <begin> <end> <destination> (all|masked) <command> ==> Exécute la commande si (or l'inverse) la region entre <start> et <end> est identiqué à la destination <destination> (équivalent de la commande /testforblocks)
  • /execute (if|unless) entity <entity> <command> ==> Exécute la commande <command> si (ou l'inverse) l'entité <entity> existe (ou si le sélecteur retourne une ou plusieurs entités) (équivalent de la commande /testfor )
Mais ce nouveau système alourdit la syntaxe, par exemple:
L'ancienne commande:
/execute @e ~ ~ ~ detect ~ ~ ~ stone 0 say Stone!
devient:
/execute as @e execute at @s execute if block ~ ~ ~ stone say Stone!
3 fois le mot "execute" dans la même commande, ça fait beaucoup.

Des voix ont commencé à se lever contre ce changement, et Dinnerbone à proposer un nouveau changement:
"as", "at", "if bloc", "if blocks" et "if entity" ne seront toujours pas des commandes, mais le mot "execute" ne serait plus obligatoire. En d'autre terme, la commande execute serait composé de plusieurs fragment commençant par "as", "at", etc. On garde donc le fonctionnement du dernière exemple, mais sans avoir a répéter le mot "execute" a chaque fois. Voici une démonstration en images:
Voici quelques exemples avec cette nouvelle syntaxe:

  • execute at @a then summon pig ==> Spawn un cochon pour chaque joueur
  • execute at @a if block ~ ~-1 ~ grass then summon pig ==> Spawn un cochon pour chaque joueur qui se trouve sur un bloc de pelouse
  • execute as @a at @s unless entity @e[distance=..5,type=creeper] then effect give @s regeneration 5 ==> Donne un effet de regénération a tous les joueurs, à moins qu'un creeper se trouve a proximité
Maintenant que la commande permet de gérer les conditions if et unless, cette fonctionnalité a donc été supprimé de la commande /function, ainsi l'ancienne commande:
/function foo if @e[tag=bar]
Devra maintenant s'écrire:
/execute if entity @e[tag=bar] function foo
Cela permettra la prise en charge de conditions plus élaborées, non plus limité sur les entités, mais aussi sur les blocs.



La suppression des DataValues
Dans notre précédente news Dinnerbone avait annoncé la suppression des DataValues (aussi connue comme étant la valeur de "Dommage" pour les armes et outils), mais il était resté assez vague sur le système permettant de les remplacer. Nous en savons maintenant un peu plus:

Concernant les blocs qui étaient différenciés par leur DataValue (laine de couleur, type de roche, etc.) ils auront maintenant leur propre ID. Par exemple les différentes couleurs de terracotta s'appelleront désormais: "minecraft:blue_terracotta", "minecraft:red_terracotta", etc. (Notez au passage que le nom changera, ce n'est plus "hardened_clay" mais "terracotta" en 1.13).

Pour les armes, outils et tous les items qui s'use, c'est plus délicat puisqu'il s'agit toujours du même objet. Dinnerbone envisage l'utilisation des tags NBT pour stoquer la valeur d'usure:
/give @p minecraft:diamond_sword{Unbreakable:1,Damage:1}



Suppression des gamerules personnalisées:
Lorsqu'on utilise la commande /gamerule avec un nom de gamerule qui n'existe pas, la commande créer alors une "variable" avec ce nom, et lui affecte la valeur de notre choix: ce sont les gamerules personnalisées. Mais ce système pose plus de problème qu'il n'en résout:
  • Les valeurs ainsi affectées sont très difficile a récupérer dans d'autres commandes
  • Ce système est sujet au faute de frappe: il est facile de se tromper sur un nom de gamerule, et aucune erreur n'apparait.
  • Il est impossible de faire de la gestion d'erreur dessus, puisque tous les noms sont valides
  • Et surtout, le système de fonctions et de scoreboard permettent de faire la même chose, mais de manière plus sur.
La commande /gamerule existera toujours, mais seules les valeurs prises en charge par le jeu seront autorisées, il ne sera plus possible de créer des variables personnalisées.



L'assistant de commande:
Ce n'est pas une nouveauté, mais voici une nouvelle animation présenté l'assistant de commande, et comment les couleurs peuvent aide a s'y retrouver parmis tous les arguments de la commande !
Un autre exemple avec la sélection automatique par l'assistant des sous-commandes (commandes avec plusieurs syntaxes possible):


Cet article a été publié par Tronics, le 2017-08-10 04:13:53. Source
Validé par  Tronics. Dernière modification par  Tronics le 10/08/2017 à 16:16.
Partager :
Commentaires de la news Minecraft
[MàJ] Minecraft 1.13: Les commandes, /execute, sélecteurs, etc. :
Tronics (administrateur)
le 10/08/2017 à 05:44
Ça va m'en faire du boulot pour mettre à jour le générateur de sélecteur de Minecraft.tools tout ça !
le 10/08/2017 à 06:59
@Tronics < Alors good luck !!!

De mon avis ils devraient garder/utiliser certain alias pour leurs paramètres et commande ! Cela gênera en rien leur nouvelles syntaxes et permettra de condenser les commandes !
Merci pour la new.
le 10/08/2017 à 07:20
C'est une vraie révolution ! Très bonne news !
le 10/08/2017 à 08:53
Je préfère déminer le terrain tout de suite, que personne ne vienne râler à cause des one command: ça ne sert plus à rien les one command, il y a les fonctions actuellement, et en 1.13 il y aura les data pack, donc je veux entendre personne se plaindre de la longueur des commandes ;)
Incoo (anonyme)
le 10/08/2017 à 09:21
Je n'est pas toucher aux commandes depuis la 1.11.2, et quand tu découvre plein de nouveautés sur les commendes tu comprend que tu es devenu un ancien pro des commendes complètement largué xD...
le 10/08/2017 à 09:58
@franswa ah on est d'accord, avec les fonctions ils ont réussis à effacer la limite de "caractères" et ça c'est bien !
le 10/08/2017 à 11:01
@Incoo < Après 5 ans de jeux, j'ai réussi a apprendre a me servir de toutes les commandes, ça va être dur de tout réapprendre.
Je vais devoir attendre avant de faire le système de ma nouvelle map jump. C'est dommage car j'ai utilisé des blocs de commandes partout sur plusieurs maps créa donc si j'y retourne en 1.13 il faudra tout refaire.
le 10/08/2017 à 11:10
I'm out
le 10/08/2017 à 11:20
Si cela restera inchangé, je dis oui tout de suite sauf pour le /tp, qui pour moi est entièrement différent du /teleport, et qui donc devrait rester une commande à part entière. Sinon très bonne news qui résumé très bien la chose.
PS : Allez voir ma suggestion j'ai mis quelque choses d'intéressant : http://fr-minecraft.net/forum/topic-32895-engager-des-correcteurs-sur-le-site.html
le 10/08/2017 à 12:02
STOP !!! Ne détraduisez pas le jeu ! On dit un bloc d'herbe, pas un bloc de pelouse !
le 10/08/2017 à 12:32
Ce qui est sûr c'est que vous n'êtes pas près de voir Across The Time 2 sortir ^^.
Ca fait très mal, limite ça me déprime parfois de passer autant de temps sur des commandes pour qu'ensuite les modifier encore et encore. Quand tu commence une map en 1.8, puis en 1.9, puis en 1.10 1.11 1.12 pour finir en 1.13, je crois que le pire souvenir qui me restera sera bien ce passage vers la 1.13.

En tout cas, maintenant ça ne sert plus à rien de faire des commandes sur vos maps tant que la 1.13 n'est pas sortie totalement. Ce n'est en plus pas la fin des modifications de Dinnerbone, j'espère sincèrement qu'après la 1.13 il n'y aura plus JAMAIS de changement interne du système de commandes. Ils ont beau faciliter la création sur Minecraft, au bout d'un moment les mapmaker ils en ont quand même un peu marre à force de tout ces changements ^^.

Je croise les doigts pour que cette mise à jour soit la dernière qui refonde complètement le jeu!
ChillyPolarBear (anonyme)
le 10/08/2017 à 12:36
Il faudrait qu'il rajoute une commande pour rotationner les blocs ex: /rotate bed x 0 z 90. Le lit va ëtre à la verticale
le 10/08/2017 à 13:18
MOI !!! LE PRO DES COMMAND_BLOCKS ...vais rester pro sur MC:PE et attendre la fin des modifications de commandes sur Minecraft avant de m'y mettre :/
mais je vais faire une map ou Minecraft sera plus dangereux et cette commande va m'etre utile tiens ;)

execute at @a if block ~ ~-1 ~ mycelium then effect give @s poison 3
le 10/08/2017 à 13:27
Pour ceux qui feront des maps (actuellement) pour la 1.13, faites les constructions en 1.12 et quand la 1.13 sortira vous vous attaquerez aux commandes (c'est ce que je ferais pour ma prochaine map)
le 10/08/2017 à 13:47
Moi je dis surtout, faites tous vos commandes block 1.12 avec des outils de création assisté en ligne, quand la 1.13 sortira, vous pourrez tout convertir en un clic comme ça.
le 10/08/2017 à 14:27
Rigolez pas les mecs mais ils sont en train de rendre le jeux programmable à fond.

Plus besoin de miliers de command_block, juste un seul avec une function et c'est bon vous avez un jeux complètement différent. Vous pouvez raller autant que vous voulez, mais c'est une bonne chose qu'il fassent une révision des commands.

J’adhère à ce nouvel aspect, même en étant un vieux de la vieille (septembre 2011 faut pas déconner, j'ai vu le jeux grandir), tout le monde dit "ouais gnagnagna les one_command c'est mort, aucun système ne fonctionne, je suis larguer je comprend rien", prenez 5 minutes pour analyser les nouvelles commandes et vous remarquerez qu'elles sont 100 fois plus puissante qu'avant (et plus claire aussi).

Vous comprenez que ça va être un jeux dans le jeux ? Un environment de programmation (si je puis m'exprimer ainsi) où la seul limite est votre connaissance et comprehension des mécaniques du jeux.

Vous pouvez par leur en vouloir de changer le jeux il faut que ça évolue.
SkytAsulNoCo (anonyme)
le 10/08/2017 à 14:37
@Kassixlom mais tellement !
Poisson (anonyme)
le 10/08/2017 à 14:51
@Builderwither Oooh je suis toucher, tu donne 3 poissons à tout les joueurs qui vont sur le mycelium.
Tronics (administrateur)
le 10/08/2017 à 16:16
J'ai mis à jour la news: j'avais oublié de parler de la suppression des gamerules personnalisé et de la suppression des conditions dans les fonctions.
le 10/08/2017 à 17:18
Kassixlom depuis la création des commandes block on peut faire des jeux dans un jeu. Tu n'apprend rien aux gens, tu crois que les mapmaker ne savent pas que les commandes vont être plus puissante avec la 1.13. C'est une question de temps et de travail simplement, commence par faire des maps de plus 10h de jeux sur minecraft et après on en reparlera de la réaction où tout est toujours plus beau et crachant sur les mapmaker qui se démènent vraiment à faire chaque fois des update de leur map. Ca prend énormément de temps et pour que ta map soit prise en compte par Mojang il faut qu'elle soit dans la dernière version.

Dans chaque mise à jour il y a des avantages et des inconvénients, et pour le moment les mapmakers ne voient que les inconvénients à défauts de ne pas encore pouvoir tester la 1.13, et c'est tout à fait normal.
On va s'adapter comme à chaque mise à jour, mais il faut avouer que ca ne fait pas toujours plaisir de voir ton temps de travail rallongé quand tu croyais arriver au bout de ta map. Au passage Dinnerbone fait du bon boulot, mais il est payé pour ça ^^.
le 10/08/2017 à 18:02
Moi qui pensait que la 1.13 serait de la BOMBE ! :smile: Et bah je pense que ce sera la PIRE update de minecraft....
Toute les commandes vont être changé (pratiquement...) et les data setblock ~ ~ ~ stone 5 RIP >> Maintenant stone varient=andesite OBLIGATOIRE
Aussi : Gamemode 3 RIP Gememode spectator OBLIGATOIRE
Incoo (anonyme)
le 10/08/2017 à 18:27
@M3treCude Setblock reste la même commande sauf que ta plus besoin de mettre le data value ^^, et pour le /gamemode 3 etc..., tu a juste à faire "/gamemode s", puis un coup de tab pour auto complétion :).
le 10/08/2017 à 19:20
@Isko81 > J'étais du même avis que toi, mais au final si on réflechit il y a maintenant /execute at

@franswa > Pas exactement. Pour passer de l'ancien /execute au nouveau, il y a toujours des moyens mais ce sera bcp moins efficace, puisque le convertisseur ne sait pas pour quelle fonctionnalité de /execute tu l'utilisais.

@Piccomaster > Je crois me rappeler que tu es map maker... Tu ne vois donc aucune amélioration avec la 1.13 ??

@M3treCube > Tu te moques de nous ? C'est la meilleure update de toutes !! Des tonnes de nouvelles fonctionnalités avec les commandes, moins de lag avec les split de execute et sinon pour la stone ya pas de parametre "data" parce que chaque bloc sera un bloc indépendant.

Genre wool 14 = red_wool
Noximilien01 (anonyme)
le 10/08/2017 à 19:31
C'est quand même drôle qu'a chaque maj y'a des gens qui disent '' C'est la pire maj de Minecraft '' ^^

Certes les mapmaker qui ont fait des trucs avant la 1.13 vont l'avoir mal, mais faut voir plus loin que le bout de son nez. Si vous êtes sûr de ne plujs avoir ce genre de changement, dans le futur vous êtes gagnant non ?
le 10/08/2017 à 19:36
@neil3000 faut regarder ou on trouve des ~ ~ ~ si on a une commande du type /execute entité ~ ~ ~ commande
faut remplacer par execute as
si t'as /execute @s position commande , faut remplacer par /execute at
et ainsi de suite, pareil pour les testfor, etc...
donc oui, un convertisseur doit analyser tous les arguments pour faire la bonne conversion mais c'est faisable.
C'est pour ça qu'il faut impérativement que tous ceux qui font des command blocks aient un fichier texte avec toute les commandes, sinon c'est juste inconvertissable, ou il faut un filtre mcedit.
le 10/08/2017 à 20:21
Neil3000 non seulement j'ai bien sous-entendu que je suis conscient que les commandes 1.13 seront plus puissante comme l'affirme Dinnerbone, mais en plus ce n'est qu'une affirmation. Nous ne voyons pour le moment que l'aspect négatif à savoir le changement d'écriture des commandes_blocks. Mais en aucun cas nous ne pouvons pour le moment vérifier sir ce que dit Dinnerbone tient ces promesses en matière d'efficacité des commandes et le fait qu'après il y aura plus de MAJ de fonte des commandes.
Mojang niveau communication avec leur promesse sur le future du jeu et tout, on en connait un rayon à savoir qu'il ne savent pas eux-même ce qu'ils vont faire. Ils prévoients des choses qui ne voix jamais le jour, comme l'ajout de chose dont onne soupçonnait même pas l'arrivé.

Bref pour conclure et que tout le monde comprenne, pour les mapmaker il y a pour le moment trop d'inconnu dans les points positifs et trop de certitude dans les point négatif. CQFD.
Tronics (administrateur)
le 10/08/2017 à 23:16
@M3treCude J'avoue que pour le coup de la commande /gamemode je ne comprend pas ce choix. Autant pour la plupart des commandes je peux comprendre leur choix (parfois j'approuve, d'autre fois, mais dans tous les cas je comprend que ce sont des choix réfléchit), autant pour le cas de /gamemode je ne comprend pas. Quel est l'avantage a supprimer les alias ? En quoi cela posait-il problème ? Ce choix de supprimer les raccourcit texte et valeurs numériques me dépasse.
le 10/08/2017 à 23:29
@Noximilien01 > De base il y a forcément quelqu'un qui dirait cela vu la taille de la communauté MC, mais c'est vrai que MC bat des records xD

@franswa > Bonne chance parce que c'est (presque) impossible. J'ai essayé de trouver un bon exemple, mais sans grand succès.

@Piccomaster > Oui ok.

@Tronics > Pas faux. Mais je crois qu'ils avaient une raison.
Je suis presque sûr qu'ils ont fait ça, parce qu'ils ont transformé les GameModes en un ENUM. Et du coup ils n'ont pas voulu se casser la tête à passer des "public" en "static"
ecrireIci (anonyme)
le 11/08/2017 à 03:43
C'est triste de voir des heures d'apprentissage et de pratique réduites à néant. RIP
Voici mon avis, en gros:
/execute if entity @e[name=1.13..] at @e[name=..1.12] summon creeper ~ ~ ~ {Fuse:0,ExplosionRadius:100}
Diabolixeur (anonyme)
le 11/08/2017 à 07:40
@Tronics, je ne sais pas si tu as jetais un coup d'oeil là dessus mais...:https://gist.github.com/Dinnerbone/943fbcd763c19be188ed6b72a12d7e65
Parce que j'ai remarquer des trucs:
/gamerule structureSaveDestination <valeur>
/teleport <victime> <entité> (donc /teleport pourrait fonctionner comme le bon vieux /tp + ça revient à une sorte de "fusion" de /tp et /teleport)
Sinon il y a quelques commandes qu'ils m'y sont inconnues (mais qu'ils existes (probablement) avant la 1.13):
/list
/save-all
/save-all flush
/save-off
/save-on
Tu as aussi oublier de préciser certaines choses (Commandes qui sont déplacés vers /execute par exemple)
le 11/08/2017 à 07:48
Est-ce que ils ont aussi supprimé le gamemode c, s, a, sp ?
(écrire "/gamemode c" nous passe actuellement en créatif, sans utiliser les chiffres, sans auto complétion ave Tab)
Bon, si c'est le cas, l’auto complétion reviendra au même pour ce qui est de l’exécution manuelle ^^
Incoo (anonyme)
le 11/08/2017 à 10:30
Au pire si des mapmakers ne sont pas contents ils ont qu'à rester en 1.12.1 et finir leur map, aussi les joueurs n'ont qu'à joué sur la même version que la map, faut pas être bête non plus...

Puis le jours ou vous allez faire une X ème map, vous passer en dernière version, avec l’expérience de la première vous allez non seulement connaitre d'avance quoi faire, mais en plus ça va vous permettre de faire une map plus clean niveau commandes.
Et aussi passer sur un standard pour ne "presque" plus avoir besoin de mettre à jour votre map ^^.

@Tronics Ils ont fait ce changement pour la compréhension de la commande je crois, Minecraft reste avant tout un jeu ou il y a beaucoup de jeunes.
Comme c'est une commende de base qui est importante, pour eux c'est plus facile de comprendre un "gamemode survival" que un "gamemode 0".
FranciumSB (anonyme)
le 11/08/2017 à 12:07
Pourquoi se sentent-ils obligés de tout changer quand on est habitué ? Ça devient plus relou et franchement, pour les maps qui passent les MAJ, comment on fait ? Ils devraient mettre à disposition un outils de conversion de commandes ! (poce blo)
le 11/08/2017 à 12:24
@franciumsb faudrait un convertisseur de fonction, car convertir des command block sans passer par mcedit out in truc du genre, c'est quasi-impossible. En plus ce serait pas inédit car ils avaient déjà proposé un convertisseur de texture pack 1.6 en ressource pack 1.7
SkytAsulNoCo (anonyme)
le 11/08/2017 à 12:35
@neil3000 au niveau des enums, ce n'est sûrement pas ça. Et absolument pas besoin de passer par des valeurs statiques, il suffit de passer par enumValue.ordinal() ou à l'inverse enum.values()[id].
Et en plus je crois que les GameModes marchaient déjà avec une enum (en tout cas c'est comme ça dans l'API Bukkit depuis toujours).
le 11/08/2017 à 14:55
@neil3000 Là n'est pas le problème !!
Mais toute les ancienne création, OneCommand, Fonctions, etc.. Seront MORTE !
Par exemple je fais un serveur un fonction... Je vais devoir TOUT, TOUUUT, refaire !! Donc après 1 semaine de travail intensif, rebelote ! :(

@Incoo Oui il y a juste à faire /gamemode s *auto-completion* Waaa c'est simple ! :DDD
MAIS NON ! :(
Toute les commandes/function comme dis au dessus seront corrompues et on devra chercher toute les commandes cassées et tout re-edit... Ça va nous prendre un temps FOU !
le 11/08/2017 à 16:46
pour ma part, lorsqu'on aura enfin quelque chose de définitif concernant le execute, j'essayerai peut-être de faire un convertisseur en java ou en python.
AC10266 (anonyme)
le 11/08/2017 à 17:21
Mais wtf pourquoi tout changer après tant d'années... Ma map qui a plus de 150h de travail rien que pour les commands blocks va être totalement cassée si je veux la jouer en 1.13...
le 11/08/2017 à 17:32
Comme exemple, @Grand_Corbeau à une map CommandBlock depuis la 1.8.
Il à déjà du tout refaire avec la 1.9, mais c'était un choix car presque tout fonctionnait encore, sauf quelque commandes telles que /playsound.. Mais là il devra regarder CHAQUE tout petit command block et ragarder où il y a un changement pour le corriger aver la commande modifié ! :((
RIP à toi G_C x)

Mais le pire reste tout de même la suppression des DataValues !!! C'était prévisible mais ça fait TELLEMENT CH**R !! De un petit chiffre, /setblock ~ ~ ~ stone 5 on passe à : /setblock ~ ~ ~ minecraft:stone[varient=smooth_andesite] ... Non mais sérieusement ?!
Pourquoi pas faire directement /setblock ~ ~ ~ smooth_andesite !?? Ils nous *embêtent* mais MOINS ! D:
Ou même les nbts ! Mais wtf... /give @p minecraft:stone[varient=smooth_andesite]{ench:[{id:5,lvl:8}]} MAIS POURQUOI TOUT EST COLLÉ ??! D: c'est illisible... -_- et niveau caractères on va EXPLOSER le compteur...
tastx (anonyme)
le 11/08/2017 à 18:46
Ce site est tombé bien bas...
Azukii (anonyme)
le 11/08/2017 à 19:12
Bonne chance a tous pour upadte vos maps et comme dit plus, si votre map est génial alors les gens resteront en 1.12 pour jouer dessus :)
@tastx explication et arguments s'il te plait sinon dégage !
Incoo (anonyme)
le 11/08/2017 à 19:52
@M3treCube Je ne sais pas d'ou tu sors ton "[varient=smooth_andesite]" mais ça n'a jamais exister, c'est juste "minecraft:smooth_andesite" ou "smooth_andesite" tout cour.
Les NBTS je ne crois pas que tes obliger de le coller à l'identifient, tu peux toujours faire un espace.

Enfin beaucoup de ouin ouin pour rien, en plus la 1.13 est spécialement faite pour les mapmakers, elle vous évite dans les prochaines version de devoir tout remettre à jour à chaque fois...
le 11/08/2017 à 20:00
@M3treCube > Ou au pire tu utilises un conertisseur. Tu auras juste besoin d'un peu de travail.

Sinon cette commande que tu as écrite:
/setblock ~ ~ ~ minecraft:stone[varient=smooth_andesite]
ne marche pas en 1.13.

Celle là /setblock ~ ~ ~ smooth_andesite marchera par contre.

Et le truc du "pk tout est collé" tu n'es pa
le 11/08/2017 à 20:14
Au pire MRGaretto va faire un convertisseur comme à chaque version donc
NoPANIC and WAIT
Les commands makers vous pouvez continuer vos maps/serveur/nomod et les convertirs simplement quand la 1.13 sortira ^^
le 11/08/2017 à 23:31
@_RedCoal_ > Faudra quand même retravailler un peu sur les commandes pour la 1.13. Juste histoire que cela soit plus optimisé :)
Tronics (administrateur)
le 12/08/2017 à 01:36
Diabolixeur: Yep je connais la page, même si je t'avoue ne pas l'avoir éplucher en profondeur.
- Le "/gamerule structureSaveDestination <valeur>" J'avaii pas vu non, mais aucune idée de sa fonction. Surtout que j'ai vu Dinnerbone dire que le dossier de sauvegarde ne serait pas personnalisable.
- Pour le /tp et /teleport... effectivement c'est une "fusion", c'est exactement ce que dit la news non ? ^^
- Les commandes /list, /save-all, etc... ne sont pas nouvelles, loin de la, je les utiliser déjà il y a 4 ou 5ans quand j'avais les serveurs multijoueurs. C'est surtout des commandes utiliser sur les serveurs, elles n'ont pas vraiment d'utilité en mode solo.
- Enfin pour le /execute, tu parles de quels commandes ? si tu parles des /testfor* la news en parle deja. S'il y a autre chose dit le moi vite.

@Damien-63: Oui les nom cours sont aussi supprimé pour /gamemode :-( Même si effectivement le tab compensera, ca reste plus long a taper (une touche de plus), c'est dommage.

@franswa Aucune chance de voir un convertisseur officiel, Dinnerbone a rejeter l'idée plusieurs fois déjà, impossible selon lui, car certaines commandes ne peuvent être convertie que manuellement.

@Incoo Si si il a raison, faut que tout sois coller, car le parseur considère un espace comme un changement de paramètre dans ta commande, donc tout doit être collé d'un bloc.

A propos du débat "minecraft:stone[varient=smooth_andesite]" VS "smooth_andesite" pouvez-vous m'indiqué vos source svp ? Car personnellement je n'ai aucune source qui indiquerez que c'est l'une ou l'autre des possibilités. La seule choses que je sais, c'est pour les blocs colorés (red_wool", "blue_terracotta", etc.). D'ailleur je trouve ca dommage de faire un ID pour chaque couleur, ça veux dire qu'il sera beaucoup plus complexe de faire plein de chose dans les commandes: vous voulais savoir si un bloc est de la laine ? Avant il suffisait de tester si l'ID était "wool", et quelque soit la couleur ca matché. Maintenant il faudra tester les 16 couleurs. J'avais fait une table de loot perso qui donne de la laine aléatoirement aussi, en quantité et en couleur. Maintenant ce n'est plus possible, il faudra indiqué toutes les couleurs possibles, très lourd comme opération.
le 12/08/2017 à 10:00
donc peut on dire que cette suppression d'ID est une bonne chose finalement ?
Incoo (anonyme)
le 12/08/2017 à 11:34
@Tronics "minecraft:stone[varient=smooth_andesite]" ça revient au même que "minecraft:stone 6" mais en pire, hors il y a plus de datas values, les blocks ne sont plus lié à un même id donc pas de "varients", la logique veux dire que c'est forcément un "smooth_andesite" comme la "red_wool".

Je pense à ce genre la "minecraft:stone smooth_andesite", avec un coté particulier, le regroupement des blocks sont faite par des préfixe indépendant des ids.
(En gros tu prend un tas de blocks, tu les mets dans une boite, puis tu donne à cette boite le préfixe "stone".

Enfin on verras bien ce que la Snapshot nous resserve :x.
RandomGuy (anonyme)
le 12/08/2017 à 15:49
Ces nouveautés sont super selon moi. Notamment les "if" et "unless" qui manquent à minecraft. J'aurais préféré quelque chose de plus poussé (intégré aux commands blocks et pas seulement limité à /execute, avec toutes les logic gates, et donc la possibilité d'avoir plusieurs plusieurs conditions à une même commande), mais c'est déjà mieux que rien. Ce qui me fait peur, c'est surtout les data values des outils, avec un resource pack, on peut assigner une texture différente à chaque durabilité d'un outil (ce qui m'est très pratique pour ma map qui va avoir de nombreux objets customs et ça permet aussi d'éviter tout ce qui est usage non-intentionnel de l'item retexturé -comme la possibilité de crafter avec, ou de le perdre car c'est un objet qui peut s'utiliser comme une enderpearl ou du blé face à une vache-), mais j'ai peur que Dinnerbone n'est pas pensé à ça, étant donné qu'on peut changer la texture d'un item uniquement en fonction de sa data_value, et si ça devient un tag nbt, ça sera plus possibe (sauf s'il prévoit quelque chose pour que ça le soit).
le 13/08/2017 à 00:50
Mon fameux "minecraft:stone[variant=smooth_andesite]" qui fait polémique sort en fait d'une compréhension détournée... Si je puis dire. Car sur ce poste reddit par Dinnerbone en personne : https://www.reddit.com/user/Dinnerbone/comments/6l6e3d/a_completely_incomplete_super_early_preview_of/

J'ai pu remarquer ceci : "minecraft:furnace[facing=north]{BurnTime:200}"

Sachant que ceci : minecraft:furnace[facing=north] existe d'une manière différente : setblock ~ ~ ~ minecraft:furnace facing=north en 1.12.

Je me suis donc dis que c'était de même pour TOUT les Datas, car "setblock ~ ~ ~ stone variant=smooth_andesite" fonctionne aussi en 1.12, il était donc logique pour moi que cela devienne "minecraft:stone[variant=smooth_andesite]".

Voilà tout ! x)
LambdaGuy (anonyme)
le 13/08/2017 à 05:34
1.13 :
Un petit pas pour la majorité des joueurs de Mc, mais un grand pas pour les command blockers et les map makers.
SkytAsulNoCo (anonyme)
le 13/08/2017 à 11:24
@LambdaGuy tellement vrai x)
le 13/08/2017 à 12:25
@LambdaGuy > :D

Ajouter un commentaire


Pour ne plus poster de commentaires anonymes, connectez-vous sur le forum.