OnClientLeave, une alternative pour cet évènement ?

Répondre
Partager Rechercher
Bon, nous avons tous rencontré le problème du OnClientLeave qui ne permet pas de faire toutes les horreurs qu'on voudrait à nos pauvres petits joueurs avant qu'ils ne nous quittent.
Ma question est donc : comment obliger un joueur à faire un check-up avant qu'il ne se déconnecte ?
Ma réponse serait : en le marquant avec un local int à l'arrivée dans le module, et en n'acceptant que les joueurs non-marqués à l'entrée, le démarquage se faisant grâce à un objet fourni par nos soins au joueur, cet objet effectuant les opérations nécessaires puis déconnectant le joueur.
Ceci est extrêmement simple à mettre en oeuvre.

Les seuls problèmes sont les déconnexions accidentelles et les oublis, il faut donc prévoir un système permettant de se rattraper si on a été victime de l'un de ces deux cas : ceci nous amène au coeur du problème puisqu'il faut éviter que les tricheurs puissent profiter d'un système trop indulgent tout en évitant de punir injustement ceux qui sont victimes d'un accident.

Perso, vu le check-up que j'envisage, je vois bien un passage par une "salle d'attente" où le joueur serait informé du problème et où il lui serait suggéré de relancer l'objet de déconnexion pour régulariser sa situation. Cette salle d'attente permettant aussi de recommencer du lieu où il s'est déconnecté la dernière fois ou d'un des points de téléportation qui lui sont accessibles.

Bien sûr tout dépend du script de notre objet et de savoir si se déconnecter sans en passer par ce script correspond à un gros désavantage ou non.

Si un système équivalent vous intéresse, je peux faire les 2 ou 3 scripts nécessaire, mais ils sont vraiment très simple donc...


Tous les avis sont les bienvenus, sur le script de déconnexion, sur le système en cas d'erreur, etc...
L'idee est bonne, les scripts sont simple a réaliser, vraiment tout bon !
J'ajouterai seulement un ou deux petit détail :

Tu devrais créer un objet qui :
-regroupe toutes les fonctions "spéciale" comme celles ci qui peuvent être utile sur un module
-permet d'accéder a ces fonctions via un dialogue
-mettre tous les scripts déclenchés dans un seul include, histoire de faciliter la personnalisation de l'objet

Exemple de choses utiles qui pourrait être ajouté :
-donner la localisation (pratique pour les DM)
-lire la description "dynamique" d'un autre PJ (auparavant stockée dans une variable par un PNJ "scribe" via les listening patern)

Ce genre de choses quoi
Parce que le problème de ce genre d'objets, c'est que tu te retrouve rapido avec 15 objets utilitaire dans l'inventaire du PJ, ce que je trouve gênant quand même

Bref c'est exactement le genre de script que je ferai si j'avais le temps
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés