CommandBlock Proposition d'ajout pour les datapacks

[Oromis]

Hey !

Aujourd'hui, je viens solliciter votre aide !
J'ai fais une proposition d'ajout pour les datapacks de Minecraft, l'idée est de rajouter une nouvelle donnée : Les commandes.
On pourrait donc créer à partir de fichiers JSON une nouvelle commande en la liant à des functions ou des commandes déjà existantes, cela serait donc en quelque sorte un alias. Les commandes pourront bien sûr prendre des paramètres qui seront directement liés à des scores et pourront donc avoir une influence sur l'exécution de la commande.
Pour plus de détails, je vous invite à aller voir mon post en question sur Reddit (en anglais) :
https://www.reddit.com/r/minecrafts...for_datapack_command/?st=jhph9oen&sh=35431df2
Si l'idée vous plait, n'hésitez donc pas à laisser un diamant et commenter, et si vous avez des propositions d'amélioration, on peut toujours en parler ici
Merci à vous !

 

[Inferentiel]

A mon humble avis, c'est redondant en partie avec ce qu'il est déjà possible de faire aujourd'hui.
Aujourd'hui pour faire une commande perso, tu dois passer par les triggers (entre autre pour contrôler l'utilisation des commandes op).
Du style /trigger ma_commande_perso, (voir /trigger ma_commande_perso set 128 si tu as besoin d'un argument) et tu actives les fonctions que tu veux en attrapant ce trigger.
Ce que tu propose c'est de transformer cette commande /trigger ma_commande_perso en /mondatapack:ma_commande_perso.
(Exemple d'une simulation de la commande Home par un trigger: https://www.minecraftforum.net/foru...blocks-and/2900640-trigger-home-snapshot-1-13 )


C'est assez limité... De même le contrôle de l'argument peut deja se faire au sein des functions. La où ta proposition apporte quelque chose, c'est dans la gestion des arguments multiples (soit), mais surtout dans les gestions des arguments "strings" (et les arguments "ItemStack", "UUID", etc.).

Pour l'instant, la limite est surtout là: la gestion des variables a base de caractère. Et cela semble laborieux à réaliser en terme de programmation...

Donc selon moi ta proposition a un intérêt limité, l'intérêt se situant surtout sur la longueur de la commande. Je préférerais qu'ils utilisent leur énergie sur l'amélioration de la commande /execute store (gestion des strings, des items, entre autres), ou sur l'incorporation de nbt dans le JSON dédié aux recettes, plutôt que sur l'élaboration d'une architecture en JSON pour les commandes.

Si tu souhaites améliorer ta proposition, tu devrais commencer par la comparer avec les trigger.

 

[Oromis]

Hey !
Merci de ton retour !
Pour y répondre, je ne suis pas tout à fait d'accord avec toi, le trigger est très limité et franchement très laborieux :
- Il nécessite une activation à chaque utilisation
- Il nécessite une détection continue d'un changement de score
- Il est peu implicite dans les cas que je propose, il faudrait donner à l'utilisateur un tableau de correspondance score/effet, autant utiliser le /function qui a au moins à l'avantage de pouvoir voir ce que l'on exécute (mais qui ne marche pas pour les non-op).
2 des 3 points que je cite nécessite d'être activé continuellement (on peut à la rigueur jouer sur la détection du deuxième pour réactiver le premier mais bon...). Bref, la commande trigger, je trouve que c'est le genre de commandes qu'il faudrait faire disparaître, autant faire en sorte qu'un joueur cliquant sur un bouton ou sur un message du chat exécute directement la commande sans passer par un trigger (après tout, si on lui propose de le faire, il n'y a pas trop de problèmes de sécurité).
Comme je le disais, dans ce que je propose peut très bien servir d'alias comme tu le soulignes, mais permettrait surtout d'ajouter une nouvelle possibilité d'interaction entre le joueur et le datapack pouvant remplacer totalement le trigger (qui serait donc inutile) avec un système d'argument. La façon de traiter les arguments que je propose est faites pour se plier aux exigences de Minecraft : ne pas pouvoir stocker de String, ça peut paraître certes un peu laborieux, mais personnellement, je n'ai pas trouvé mieux pour gérer cela que par le passage indirecte d'un score. Pour tout argument variable, le passage par un tag est donc pour moi l'idéal par rapport à ce que l'on a, il permet de faire un système de variables basique (car, disons-le, Mojang n'a pas l'air de vouloir ajouter un véritable système de variable plus complet, donc j'essaye de limiter ce point), et sécurisé car tout cela reste seulement dans l'enceinte de la commande.
Enfin bon, ne retenons que le système d'alias qui est la seule utilité que tu lui vois vraiment :
Le système de crafts custom n'est-il pas seulement une alternative aux anciens systèmes de crafts que l'on faisait par le biais d'un dropper ?
Ce système est pourtant plus pratique à l'utilisation mais reste au final plus limité tant qu'ils n'auront pas ajouté la gestion des NBT
Et les functions une alternative pour simplifier le passage de command-block d'un monde à l'autre ?
Au final, on remarquera que la plus part des données des Data Packs sont justes des alternatives à ce que l'on avait déjà, permettant soit d'être plus complet, soit d'être plus pratique, mais tout était plus ou moins faisable avant ! (Seul exception pour les advancements je dirais, les Tags étant en sois juste un remplaçant à l'ancien système de data value que l'on nous propose de custom)
Donc voilà, ce que je propose n'est pas essentiel, mais permettrait tout comme les autres données de simplifier les choses sur certains point, de rendre plus pratique à l'utilisation et à la création, donc oui, si on retire tout les détails, ce n'est qu'une commande trigger, mais qui reste tout de même bien plus personnalisable
Et puis bon, quand l'on regarde les autres propositions comme "Ajouter des slime balls qui se mangent" ou "Dimension Aether", je ne pense pas que mon idée soit la plus inutile

 

[frodomax33]

Wow c'est une superbe idée ! On pourra enfin faire des maps et des serveurs uniquement en vanilla pur à l'aide de ce système ! J'approuve ^^

 

[harryco76]

Très bonne idée Malheureusement je pense que le premier commentaire que tu as eu sur Reddit dit vrai; seule une toute petite partie de la communauté Minecraftienne s'intéresse à ce genre de choses c'est pourquoi j'ai bien peur que ton projet n'aille pas plus loin :/
Cependant bonne chance à toi et je vais lâcher mon plus beau diamant sur Reddit en espérant t'aider ^^

(Je ne vois le problème avec les slimeballs qui se mangent... )

 

[Oromis]

Merci de vos retours !
En effet, ça ne concerne qu'une petite partie mais bon... On essaye ^^"
J'ai aussi posté sur le site de feedback officiel que voici :
https://feedback.minecraft.net/hc/en-us/community/posts/360011287031-New-data-for-datapack-Command

 

[Inferentiel]

Je t'ai upvote sur reddit tout de même, parce qu'il est vrai que cette partie du jeu m'intéresse le plus, et qu'il n'y a pas assez de propositions/vote pour l'améliorer.

Et puis c'est vrai que sur le long terme, la place de commandes perso serait plus dans un fichier JSON que dans des mcfunctions. Cela permet de spécifier bien plus d'options, comme tu le proposes (op/pas op, type de sélecteur, aide de la fonction etc.), et d'avoir une véritable parité avec les plugins et les mods. J'étais juste étonné que tu ne fasses pas naturellement la comparaison avec les triggers, puisque c'est la méthode que tu supplantes avec ça et que les conversions plugins->datapacks (comme essentials) existent déjà sur les forums anglais.

 

[Oromis]

Yep, c'est vrai que je n'y ai pas vraiment pensé sur le coup ^^"
J'ai aussi fait un post sur le site officiel de Minecraft pour les propositions
https://feedback.minecraft.net/hc/en-us/community/posts/360011287031-New-data-for-datapack-Command