1. Le forum de Minecraft-France va définitivement fermer ses portes. Celui-ci restera en lecture seule mais vous ne pourrez plus y apporter de nouveaux topics. Nous vous invitons à nous rejoindre sur le Discord de Minecraft-France qui permet de présenter vos projets, discuter avec la communauté etc.. Merci à tous d'avoir fait vivre ce forum de nombreuses années. Pour nous rejoindre sur Discord, Cliquez ici

Mapping Des shops compacts et intuitifs

Discussion dans 'Tutoriels' créé par Calambiel, 11 Mai 2015.

  1. Calambiel

    Calambiel Résident de l'End

    Inscrit:
    5 Août 2014
    Messages:
    6 595
    Points:
    229
    Bien le bonjour.

    Cela faisait un moment que je ne vous ai pas fait un petit tutoriel et comme je n’ai pas mis dans le support une réponse à une demande résolue en privée pour une demande de shop j’ai décidé de vous en présenter plusieurs types avec chacun leurs avantages et leurs inconvénients.

    Comme d’habitude l’objectif final est d’arriver à un modèle le plus intuitif possible et en utilisant un minimum de redstone ou de blocs de commande à l’état final. Pour les initiés aux commandes le dernier modèle vous intéressera peut-être, pour tous les autres bonne lecture !

    Les différents modèles qui seront présentés :
    • Shop utilisant le scoreboard
    • Les villageois et la 1.8
    • Shop hybride utilisant le /stats
    Shop utilisant le scoreboard :

    Le scoreboard reste le moyen le plus simple de symboliser une monnaie échangeable contre des bonus. Il est d’ailleurs possible de le relier directement à une stat du joueur comme le nombre de monstres/joueurs qu’il a tué, le nombre de blocs qu’il a miné etc….

    Les principaux avantages de ce modèle sont la simplicité de construction et la flexibilité de fonctionnement. Cependant il n’est pas le plus intuitif pour les joueurs et oblige l’affichage du scoreboard, soit dans en « list » que les joueurs doivent vérifier régulièrement soit en « sidebar » qui gêne une partie de l’écran.

    Il en existe de nombreuses adaptations mais pour limiter la taille des systèmes nous allons tout simplement passer par panneau cliquable qui contiendra toutes les commandes nécessaires. Je vous donne ci-dessous une commande où vous n’aurez qu’à remplacer les textes et chiffres par ce qui s’adapte à votre situation.

    Commande pour se give un panneau :
    Code (cpp):
    give @p minecraft:sign 1 0 {BlockEntityTag:{Text1:"{\"text\":\"Nom de l'objet\",\"color\":\"dark_blue\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p[r=2,score_Coins_min=X] <Id_item_givé>\"}}",Text3:"{\"text\":\"X coins\",\"color\":\"gold\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/scoreboard players remove @p[r=2,score_Coins_min=X] Coins X\"}}"}}
    Pour plus d’informations sur le JSON utilisé ici pour réaliser les clickEvent allez lire le tutoriel de Mlakuss sur le sujet.

    Le shop avec des pancartes est extrêmement compact et simple pour un joueur. Cependant il présente deux défauts : la limitation à un seul échange par pancarte et la limitation de taille des commandes (ne pouvant dépasser la taille d’un message de joueur en chat). Si votre commande de /give est trop longue (à cause de la présence d’un NBT tag ou autre) vous devrez passer par un /setblock activant un système ou un /scoreboard pour identifier les joueurs réalisant une transaction. Le modèle suivant ne subit cependant pas ces problèmes.

    Les villageois et la 1.8 :

    Les villageois sont un autre moyen extrêmement utile de réaliser un shop. Ils présentent de nombreux avantages comme la possibilité de regrouper plusieurs échanges en un seul marchand tout en pouvant vendre des items complexes sans système extérieur. Depuis la 1.8 le fonctionnement des villageois a été sensiblement modifié c’est pourquoi je me propose de vous l’expliquer avant de passer à la création du shop.

    Les différents NBT tag des villageois :
    • Profession : défini la texture utilisée par le villageois et son nom dans l’interface s’il ne possède pas de CustomName
    • Riches : nombre d’émeraudes échangées avec le villageois, ne sert à rien dans le jeu en survie mais peut toujours être utile si on veut tester des tags
    • Career : complémentaire de « Profession » pour définir les échanges proposés par les villageois
    • CareerLevel : le « niveau d’échange » du villageois, nous y reviendrons par la suite
    • Willing : tag servant à la reproduction dont nous ne nous servirons pas
    • Inventory : l’inventaire du villageois utilisé principalement par les fermiers qui peuvent récolter et replanter de la nourriture
    • Offers : les échanges proposés par le villageois
    Pour faire très simple à chaque fois que vous réalisez un échange avec un villageois son tag CareerLevel va se modifier et s’il est inférieur à la valeur se trouvant dans le tag « Career » alors un nouvel échange sera créé. Plus encore si le tag atteint 0 il va alors retrouver une valeur de 1 et la « Career » du villageois changera également.

    Pour résumer : auparavant un villageois générait une nouvelle offre à chaque fois que l’on utilisait la dernière offre qu’il propose, désormais il faut réaliser un certain nombre d’échanges jusqu’à ce que le CareerLevel soit inférieur au Career. Pour bloquer l’apparition de nouveaux échanges il vous suffit donc de donner une grande valeur à « CareerLevel » (pas trop grande non plus si vous ne souhaitez pas rencontrer un crash de type « OutOfBounds »).

    Passons maintenant à la structure des offres des villageois. Elles sont toutes répertoriées dans le tag « Offers » et possèdent plusieurs composantes :
    • buy : le premier item à donner au villageois
    • buyB : le second item à donner au villageois
    • sell : l’objet vendu par le villageois
    • maxUses : le nombre d’utilisations possibles de l’échange
    • uses : nombre de fois que l’échange a été réalisé
    • rewardExp : activer ou non le don d’xp lorsque l’échange est réalisé (il s’agit d’un true/false et non pas de la quantité d’xp donnée)
    Pour ceux qui connaissent la structure des NBT tags chaque échange est isolé dans des accolades, tous les trades étant regroupés entre crochets et séparés par une virgule. Tous les items demandés ou givés, leurs tags ou leur quantité sont déclarés comme dans le modèle trouvable ici.

    Exemple :
    Ici on a deux échanges étant respectivement de la terre contre de l’herbe et deux de charbon + un minerai de fer contre deux lingots de fer
    Code (cpp):
    [{buy:{id:"minecraft:dirt",Count:1},sell:{id:"minecraft:grass",Count:1},maxUses:1000,rewardExp:false},{buy:{id:"minecraft:coal",Count:2},buyB:{id:"minecraft:iron_ore",Count:1},sell:{id:"minecraft:iron_ingot",Count:2},maxUses:1000,rewardExp:false}]
    Important : il ne faut pas oublier de préciser le nombre d’item via le tag « Count » et ce même si vous souhaitez le mettre à 1 car par défaut il est à 0. Il est aussi à noter que pour une raison obscure Mojang a décidé de placer entre le tag « Offers » et la liste des offres le tag « Recipes » qu’il faut donc bien écrire à chaque fois bien qu’en soi il ne sert à rien à par rajouter une accolade et un mot avant le crochet
    Si on reprend tout depuis le début et qu’on rajoute tous les tags qui nous intéresse voici la commande pour summon un villageois invincible avec les deux trades précédents et qui ne donnera pas d'autres échanges.
    Code (cpp):
    summon Villager ~ ~1 ~ {Invulnerable:1,Offers:{Recipes:[{buy:{id:"minecraft:dirt",Count:1},sell:{id:"minecraft:grass",Count:1},maxUses:1000,rewardExp:false},{buy:{id:"minecraft:coal",Count:2},buyB:{id:"minecraft:iron_ore",Count:1},sell:{id:"minecraft:iron_ingot",Count:2},maxUses:1000,rewardExp:false}]},Career:1,CareerLevel:1000}
    Invoquer un villageois avec un échange : (il suffit de séparer tous les échanges par une virgule)
    Code (cpp):
    summon Villager ~ ~1 ~ {Invulnerable:1,Offers:{Recipes:[{buy:{id:"Id du premier item demandé",Count:X},buyB:{id:"Id du second item demandé",Count:X},sell:{id:"item vendu",Count:X},maxUses:1000,rewardExp:false,Career:1,CareerLevel:1000}
    Il existe beaucoup de générateurs de villageois en ligne qui peuvent vous aider si vous ne comprenez rien à la syntaxe des NBT tag. Celui-ci est notamment très bien fait avec une syntaxe très propre ce qui facilite sa compréhension ou modification.

    Les villageois ont le grand avantage de fonctionner avec des items et non des scoreboard ce qui est bien plus représentatif pour un joueur. Cependant ils demandent plus de temps pour réaliser un échange et sont des entités, donc plus difficiles à contrôler. Le dernier modèle que nous allons voir aujourd’hui a pour but de regrouper les avantages des deux modèles précédents.

    Shop hybride utilisant le /stats :

    Je vous entends déjà paniquer rien qu’à l’idée d’utiliser cette commande qu’est le /stats mais ne partez pas tout de suite vous verrez que nous ne pousserons pas son utilisation très loin aujourd’hui. Je ne ferai ici qu’une explication sommaire et concise du /stats pour vous simplifier sa compréhension mais si vous souhaitez en savoir plus allez voir le récent topic de Mlakuss.

    De manière très résumée le /stats va vous permettre de transposer la valeur d’un tag dans un scoreboard. Je vous arrête de suite on ne parle pas ici de l’ensemble des tags mais uniquement de ceux étant générés comme résultats d’une commande regroupés dans le tag « CommandStats » à savoir :
    • SuccessCount : prenant une valeur de 1 si la commande a réussi et une valeur de 0 si elle échoue
    • AffectedBlocks : le nombre de blocs affectés par une commande type /fill
    • AffectedEntities : le nombre d’entités affectées par une commande avec sélecteur
    • AffectedItems : le nombre d’items affectés par une commande type /clear
    • QueryResult : la valeur ressortie par une commande type /time query daytime ou /worldborder get
    Nous nous servirons ici uniquement du tag AffectedItems. Pour relier la valeur du tag et le scoreboard il faut utiliser une commandes /stats de syntaxe :

    Pour récolter un tag d’un bloc :
    Code (cpp):
    /stats block <x> <y> <z> set <Tag visé> <Sélecteur de l’entité à qui attribuer le score> <Objectif où la valeur sera enregistrée>
    Pour une entité :
    Code (cpp):
    /stats entité <Sélecteur de l’entité du tag visé> set <Tag visé> <Sélecteur de l’entité à qui attribuer le score> <Objectif où la valeur sera enregistrée>
    Pour « délier » le score et le tag il vous suffit de remplacer le « set » par « clear ».

    L’énorme avantage du /stats est qu’il n’est désormais nécéssaire d’aucune commande pour transposer la valeur du tag dans le scoreboard. A chaque fois que la valeur changera elle sera automatiquement mise à jour dans le scoreboard.

    Mais vous vous demandez probablement pourquoi je vous parle de tout cela. Ce que j’appelais un magasin hybride sera en fait un magasin utilisant le scoreboard mais où les valeurs des objectifs vont être définies par un nombre d’items dans l’inventaire des joueurs ce qui le rend beaucoup plus intuitif et évite l'affichage du scoreboard tout en restant plus rapide qu'un échange de villageois.

    En effet pour calculer le nombre d’items dans l’inventaire des joueurs il nous suffira de réaliser une commande /clear retirant…. 0 items où l’AffectedItems ne mesurera pas le nombre d’items retirés mais le nombre d’items portant l’id correspondant.

    Avant de pouvoir mesurer le nombre d’items par joueur il va cependant falloir quelques commandes d’initialisation. Tout d’abord avant de pouvoir être mis à jour l’objectif doit posséder une valeur quelconque. Ensuite pour que chaque joueur ait un score propre peu importe le nombre de joueurs et sans passer par des blocs de commande propres à chaque joueur il va nous falloir utiliser un execute.

    Voici donc les deux commandes d’initialisation :
    Code (cpp):
    /scoreboard players set @a Coins 0
    /execute @a ~ ~ ~ stats entity @p set AffectedItems @p Coins
    Il ne vous reste plus qu’à exécuter un clear en execute pour mettre à jour le scoreboard (j’ai choisi ici d’utiliser les gold nuggets comme monnaie) :
    Code (cpp):
    /execute @a ~ ~ ~ clear @p minecraft:gold_nugget <Damage_Value> 0
    Pour un item simple remplacez la damage value par 0.

    La question qui se pose alors est : quelle clock utiliser pour mettre à jour cette valeur assez rapidement ? La réponse est extrêmement simple : aucune, nous allons intégrer la mise à jour directement dans notre shop.

    Nous ferons ici aussi un shop via un panneau cliquable qui reste le plus compact. Nous allons garder le même shop que le premier modèle présenté dans ce tutoriel en changeant les commandes.

    Commande pour se giver le panneau cliquable :
    Code (cpp):
    give @p minecraft:sign 1 0 {BlockEntityTag:{Text1:"{\"text\":\"Nom de l'objet\",\"color\":\"dark_blue\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/execute @p[r=2] ~ ~ ~ clear @p minecraft:gold_nugget 0 0\"}}",Text3:"{\"text\":\"10\",\"color\":\"gold\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p[r=2,score_Coins_min=X] <Id_item_givé>\"}}",Text4:"{\"text\":\"gold nuggets\",\"color\":\"gold\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/clear @p[r=2,score_Coins_min=X] minecraft:gold_nugget 0 X\"}}"}}
    Tout comme le premier modèle si votre give est complexe vous devrez passer par un setblock ou un scoreboard.

    Attention :
    Ce type de shop ne fonctionne pas en 1.8.4 car le /stats est complétement bugué dans cette version (d'ailleurs par défaut la 1.8.4 est à éviter, on m'a aussi parlé de problèmes avec des ArmorStand qui déchargent, bref merci Mojang d'avoir plié l'update trop vite pour corriger la faille de sécurité). Pour vous donner un exemple lors des tests à plusieurs joueurs le nombre d'items dans l'inventaire était enregistré dans le scoreboard du mauvais joueur (de l'autre joueur si vous êtes deux, à plus tous les scores sont carrément mis sur un même joueur et tous les autres joueurs ont un score de 0). Cependant en solo il n'y a normalement pas de problèmes.
    Bref soit vous attendez la prochaine update soit vous repassez en 1.8.1 ou 1.8.3.


    Voilà j’espère que ce tutoriel vous aura plus.
    Promis je vous ferai celui que je vous ai promis sur les Armor Stand, il prend plus de temps car il nécéssite un tri important des informations vu toutes les possibilités offertes.

    Sur ce bonne journée et bon map-making.
     
    • J'aime J'aime x 6
    • Informatif Informatif x 1
    #1 Calambiel, 11 Mai 2015
    Dernière édition: 16 Mai 2016
  2. Pikachu

    Pikachu Mineur

    Inscrit:
    26 Avr 2014
    Messages:
    392
    Points:
    89
    Sexe:
    Homme
    Nice ! :p

    J'ai hâte de voir des shops comme ça, vraiment !
    Tu devrais essayer de mettre des images, bien que ce soit un peu hard à les mettre dans ce posts. ;p
     
  3. Calambiel

    Calambiel Résident de l'End

    Inscrit:
    5 Août 2014
    Messages:
    6 595
    Points:
    229
    Je ne vois pas l'utilité de rajouter des screens, ça serait juste des panneaux avec un texte ou des villageois x)
    Il n'y a même pas de système à montrer vu que tout est géré par le-dit villageois ou panneau cliquable.
     
    • J'approuve J'approuve x 1

Partager cette page