Salut, salut !
Désolé, j’ai eu un problème de PC je n’ai pas pu me corriger ni répondre...
Ah d’accord merci scouarn, c’est donc un CUBE qui grandi jusqu’à ce qu’il trouve l’entité la plus proche correspondante, faut pas confondre avec r=1 qui sélectionne dans une surface définie en rayon...
Avant que je dise un truc faudrait que je le vérifie, je croyais naturellement que si l’ArmorStand était dans le command_block ça allait marcher, et ben non lol il détecte celui de droite quand même !
J'ai fait des trucs tordus comme : tenter de /setblock un bloc de lave un court instant sur l’ArmorStand ayant 1/2 cœur mais il me cramait celui du haut et du bas…
J’ai testé de /clone un dispenser avec un redstone_block qui tire une flèche (c’est pas rapide en plus) mais il ne tue pas l’ArmorStand car ils reposent tous dans des bloc barrier, j’ai tenté le NoGravity:1 mais là la flèche tire en dessous d’eux :S mdr
Mais de toute façon je ne recherche plus à /kill un ArmorStand le plus proche car même le fondement de mon système ne tient pas en globalité...
J’ai fait autrement, et ça compte bien marcher, j’avais préparé un gros commentaire pour expliquer mais ça n’intéresse peut-être pas forcément.
Bon allez je le poste, je l'ai pas fait pour rien...
Je suis passé par plusieurs idées, notamment de faire le /kill en /execute en faisant en double le système qui gère les conditions pour détecter tout ce qui se passe et doit se passer à l’écran du mini-jeu, et à la place de mettre un /clone à la fin de ce système double, je mettais un /kill, mais Minecraft choisissait le /clone et pas le /kill et quand j’inversais leur emplacement c’était Minecraft qui choisissait le /kill et pas le /clone, une histoire de priorité bizarre.
Donc j’ai décidé de mettre mes /kill dans les modules qui se font cloner et le tout aurait été /clone si le /execute detect pour l’ensemble des conditions étaient valides, mais en même temps ces mêmes états changent (les blocs qui se font detect) pour la suite des futurs détections, et que donc le /execute detect qui /kill ne détectait plus ce qu’il devait (ils agissaient en même temps, une histoire de priorité), j’ai donc mis un temps d’attente avec un /setblock en mettant le /kill au début, et ça marchait. Jusqu’à ce que je me rende compte que le fondement même de mon système ne tenait pas en globalité…
Mais j’ai compris le problème, je faisais un ensemble de condition pour chaque déplacement/action de ce qui se passait à l’écran de jeu pour détecter les ArmorStand si une action était possible et si oui elle se réalise, en une commande comme ceci : un exemple :
/execute @p[score_DIRECTION_min=4,score_DIRECTION=4] ~ ~ ~ detect ~ ~ ~ air 0 /execute @e[type=ArmorStand,name=HERO] ~ ~ ~ detect ~1 ~ ~1 stonebrick 3 /execute @e[type=ArmorStand,name=HERO] ~ ~ ~ detect ~1 ~ ~2 quartz_block 0 /clone 881 58 882 894 58 882 ~7 ~ ~
Le problème est que je n’avais pas pensé au fait que si du moment que les conditions sont valides pour UN ArmorStand, ça allait, mais que si en plus elles détectaient un autre et qu'elles n'étaient pas valides en totalité pour cet ArmorStand il suffisait qu’il y ait juste la dernière condition pour que le /clone se fasse à cet ArmorStand qui n’a pourtant pas rempli toutes ses conditions... Là-tout-le-sys-tème-é-tait-fou-tu…
Même si pour l’exemple il n’y a pas de problème car il n’y a qu’UN seul HERO dans le jeu. Mais pour les autres choses non...
Je n’ai donc plus géré via un système de côté où il gérait/détectait les ArmorStand qui correspondaient à la description, mais j’ai donc géré en clonant chaque condition sur la case même, en face d’un ArmorStand neutre m’en servant juste que pour faire mes conditions à la chaine dans un seul command_block (sinon ça m'aurait pris autant de blocs qu'il y a de conditions et en plus de cela j'aurais du faire une porte NOR pour chaque ensemble de conditions pour voire si elles sont valides...) et si elles réussissent elles /clone le module qui réalise l’action et met à jour les états pour de futurs détections et renvoie un /clone de détections à la nouvelle case, ainsi de suite, etc…
Mais le c=1 détecte toujours l’ArmorStand de droite, mais ça ne fait rien car j’en prends compte dans les coordonnées, je /clone les détections à gauche pour qu’elles détectent le bon ArmorStand qui est à leurs droite (à défaut d’être en face >< (mais pourquoi ? ><)), et il détectera toujours celui de droite car les ArmorStand ne sont ni /kill ni en déplacement.
La commande de l’exemple change donc un peu beaucoup, mais mon système est sauvé :
/execute @e[score_DIRECTION_min=4,score_DIRECTION=4,c=1] ~ ~ ~ detect ~ ~ ~ barrier 0 /execute @e[type=ArmorStand,c=1] ~ ~ ~ detect ~1 ~ ~1 stonebrick 3 /execute @e[type=ArmorStand,c=1] ~ ~ ~ detect ~1 ~ ~2 quartz_block 0 /clone 881 58 882 894 58 882 ~7 ~ ~
Cette commande et toutes les autres actions que peut faire le HERO sont maintenant /clone à la case où il se trouve en début de partie et actualisée pendant (et non plus unique de côté et géré sur le côté), il y aura donc autant de /clone de module de détections en face de chaque case qu’il y a de PIERRE, MONSTRE, etc…
Cette commande sert donc à savoir si le HERO veut et peut pousser une PIERRE à DROITE.
Il faut donc que ces conditions soient remplies pour que l’action se réalise :
Conditions :
1) Si le HERO va à DROITE.
2) Si il y a une PIERRE à DROITE du HERO.
3) Si il y a de l’AIR à DROITE de la PIERRE.
Faire : que le HERO va à DROITE en poussant la PIERRE à DROITE.
Et si tout ça est rempli, l’action se produit avec un /clone et les états pour les futurs détections sont mis à jour via le /clone correspondant qui est atterri en face de la case, qui lui est un ensemble de /setblock avec des redstone_block et un /fill air pour l’éliminer une fois qu’il a fait l’action et mis à jour les états pour de futurs détections.
En gros je fais comme avant, toutes les actions du système sont stockées en externe et passive, pouvant être appelés pour agir sur les 160 endroits (cases) potentiels sans mettre toutes ces actions à ces 160 endroits (cases), je gagne donc énormément de place, et ce n’est ni plus long ni plus lent c’est déjà rapide en exécution, il n’y a que l’état de la case qui est sur une case, et non pas tous les états potentiels sur une case, car quand UN fonctionne les autres NON, c’est donc un gain de place. Il y a juste maintenant les command_block qui détecte les actions qui sont /clone à la case correspondante, et non plus fixe en externe avec une détection d’ArmorStand avec un name. Le système sera plus grand qu’avant à moins que je /clone par deux fois les modules stocké en deux fois moins long mais deux fois plus haut, mais ça restera dans l’espace disponible de mon système. Mais de toute façon le système ne sera plus grand que quand on jouera au jeu, car tout est stocké sur le côté et /clone à la demande pour chaque case qui /fill air aussi tôt ce qui sera /clone, je ne suis pas obligé de /fill air, mais c’est plus classe quand on voit le système et plus propre, car de toute façon si je le laisse ça ne sera qu’un déchet de l’action précédente… Ça fera deux fois plus d’action pour Minecraft de le /fill air certes (même /clone en deux fois aussi, même j'ai pas envie que mon système soit plus grand :S), mais je ne crois pas que c’est ça qui va faire du lag, au pire je le laisse et quand la partie est terminée et que potentiellement donc on pourrait aller regarder le système je /fill air tous les restes inutiles… voilà ! xD
Vous en avez peut-être rien à faire de ce que je vous raconte mais voilà...
Si ça vous a intéressé j’en suis très content.
Et si vous n’avez rien compris, c’est que je me suis surement mal exprimé... xD
Merci de m'avoir lu
C’est résolu !
