Problèmes avec la deconnexion/reconnexion et les testfor.

La solution, c'est de ne pas avoir de testfor qui soit constamment actif, ça n'a pas l'air d'être une solution, mais c'est ce qu'il y a de mieux à faire (ou alors rendre ton testfor indépendant des joueurs en utilisant un joueur fantôme et la commande /scoreboard players test). Il n'est pas possible de détecter la déconnexion d'un joueur (mais on peut détecter sa reconnection avec la stat "leaveGame"). Et même si c'est possible, y a forcément un moment où on passe par l'état "faux" dans le testfor.

 

Crée donc un objectif nommé genre "leave" ou "gameLeave" dans la catégorie stat.leaveGame. Dans tes testfors, ne fait aboutir que à des commandes ne marchant que sur les joueurs pour qui ce score est à 0; et à la fin de tous tes testfors, mets un command block pour réinitialiser le tout

Code (cpp):

/scoreboard players set @a[score_nomDuScore_min=1] nomDuScore 0

.
J'en profite pour te conseiller très fortement d'abandonner (ou presque) les testfor: ce sont des commandes dépassées depuis l'arrivée de /execute, c'est à dire depuis...un paquet de temps. En vérité, le /testfor n'a le dessus sur le /execute (ou le /scoreboard avec des commandes à côté, mon préféré que je sur-utilise) que pour les petits tests qui demandent peu de rapidité.

EDIT: Dépassé par Mlakuss ;(

 

Le /testfor reste très utile dans certains cas mais c'est vrai qu'il se remplace aisément par un /scoreboard ou un /execute (en fonction de ce qui est testé).

 

Ce serait sans doute un sujet à débat, mais désormais je ne me sers du /testfor que pour les petits tests en général de position, quand je n'ai pas besoin d'effectuer actions rapidement et sur plusieurs joueurs...ou bien pour créer des événements irréversibles/qui s'activent au bout d'un certain temps (une porte qui se déverrouille si le joueur si le joueur a tel truc, ou un explosion à telle position, ou encore une exécution de commandes au bout d'un certain temps etc.).
J'ai peut-être parlé un peu trop vite tout à l'heure, mais pour être exact je pense qu'on peut dire qu'il est devenu bien moins utile avec 1/L'arrivée des ultra clocks & 2/L'arrivée du /execute. Sa lenteur et son côté bloqué à cause de l'utilisation du comparateur peut-être utile...comme totalement inutile

 

Intéressant tout cela.
Mais y a une chose qui me chiffonne : c'est la syntaxe de la commande /execute...

 

/execute <cible> x y z <commande>
Il faut le comprendre comme s'il fonctionnait de la même manière qu'un testfor sauf que, quand la condition est vraie, une commande s'exécute immédiatement.
Le x, y et z sont pas forcément utile (sauf cas du /playsound), on met très souvent "~ ~ ~" pour dire que la commande doit être exécutée sur le joueur.

 

Hum.

En gros, si je veux savoir si un joueur est à tel endroit et si oui, lui faire un effet de Strength, la commande sera celle-ci ? :
/execute @a[x=<cd.>,y=<cd.>,z=<cd.>,r=1] ~ ~ ~ /effect @a 5 100 1

 

Non. Si tu mets bien les coordonnées de l'endroit à la place de tes <cd.>, dans ton /effect, c'est "/effect @p 5 100 1" qu'il faut mettre.

 

Ok.

Je comprends donc un peu mieux le /execute