Salut,
}, 20, 20); // Je ne sais plus à quoi sa correspond mais laisse comme ça
LEL !
Bon... Quand vous voulez développer avec une API (ce qui est le cas ici vu qu'on va développer avec spigot/bukkit) il ne faut pas avoir peur d'aller voir la documentation. Et il faut surtout savoir la lire !
Pour spigot, la doc est ici:
https://hub.spigotmc.org/javadocs/spigot/
Pour bukkit, la doc est ici:
https://hub.spigotmc.org/javadocs/bukkit/
Très peu de différence entre les deux (surtout dans quelque chose d'aussi basique).
Quelques notions tout d'abord sur le scheduler. Commençons par un lien vers la doc:
https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/scheduler/BukkitScheduler.html Je n'ai pas étudier en détail comment il fonctionne mais pour donner une image c'est comme si on lançais un thread. Celui-ci pourra être exécuter plus tard (runTaskLater) ou de manière récurrente (runTaskTimer). Pour plus d'informations sur les scheduler, je vous invite à venir voir ce tutoriel:
http://wiki.bukkit.org/Scheduler_Programming (cette page existe en français mais je le trouve moins précise
).
Bien maintenant regardons le problème de plus près. On veut interdire une commande durant un certains délais. A-t-on vraiment besoin d'un scheduler ? Si j'ai bien compris l'idée de Device, il veut mettre les joueurs dans une liste (jusque la je suis d'accord), lancer une tache scheduler et ensuite les retirer de la liste ? Non c'est pas vraiment ça que tu veux faire... mais je vois pas où tu veux aller.
Bref, voici ce que je propose:
- Lorque le joueur fait la commande et qu'il a le droit (que cela fait 24h qu'il ne l'a pas fait) on le rajoute dans la liste (on va enregistré son uuid) mais on va également enregistrer le timestamp (codification du moment présent sous forme de chiffre) actuel.
- Dès qu'un joueur fera la commande, on va commencer par vérifier si il est dans la liste. Si n'est pas dedans, tout est bon, il peut faire la commande. Si il est dans la liste, on va regarder si le timestamp enregistré est plus grand que le timestamp actuel + 24h. Si c'est le cas, il peut faire la commande, sinon on lui dit qu'il ne peut pas.
Attention, en faisant ce système alors que tu as beaucoup de joueur, tu as des risque de saturation de mémoire. Mais le système des schedulers est encore plus coûteux en ressource (d'un côté on a une liste, de l'autre on à des taches avec tout le contexte qu'il y a autour).
De plus, si ton serveur redémarre, tout sera remis à 0. Si tu veux conserver ces informations il faudra faire un système qui enregistrera cette liste dans un fichier et qui chargera ce fichier au démarrage.
Petite remarque en passant, je ne suis pas fan du PlayerCommandPreprocessEvent (même si Richie3366 adore ça), je trouve que le onPlayerCommand marche très bien
)
Pourquoi prendre l'UUID et non pas l'objet Player ou son pseudo ? Tout simplement parce que l'objet Player il est supprimé lors de la déconnexion (et un nouvel objet est créé) et le pseudo quand à lui peux-être modifié depuis le site de Mojang (même si c'est limité à un changement tous les 20 jours à peu près).
Concrètement en code ça donne ceci:
PHP:
private static HashMap<UUID, Long> playerCommand = new HashMap<UUID, Long>();
private static int DELAY = 86400000; // 60000 = 1 sec; 3600000 = 1h; 86400000 = 24h
@Override
public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
// Vérification que c'est la bonne commande, ect, ect....
// Je vais quand même pas tout écrire xD
if (sender instanceof Player) {
Player player = ((Player) sender);
UUID uuid = player.getUniqueId();
long tempsActuel = (new Timestamp(System.currentTimeMillis())).getTime();
if(!playerCommand.containsKey(uuid) || // Si il n'est pas dans la liste
(playerCommand.get(uuid) - tempsActuel) > DELAY) { // Ou que le temps est suppérieur
// La commande ici
playerCommand.put(uuid, tempsActuel);
} else {
player.sendMessage(ChatColor.RED +
"Vous devez encore attendre avant de pouvoir faire cette commande");
}
}
}
Cordialement,
Detobel36
.
