Faire une liste de joueur dynamique

Coucou,

J'aimerais créer un petit event, les joueurs s'inscrivent, etc.
Sauf qu'il y a le cas où le joueur s'inscrit, mais entre-temps il se déconnecte...

La liste (si je prend un tableau) va donc comporter tous les joueurs, même ceux déconnectés, et si j'essaye de leur attribuer des statuts spéciaux, java va m'engueuler comme quoi il ne trouve pas certains joueurs (ceux qui se sont déconnectés si vous suivez bien ).

Ma question est donc, comme faire une liste qui se met à jour lorsqu'un joueur se déconnecte, et qui ne laisse pas une case de vide...

J'ai regardé un peu, et j'ai vu les FastList, mais je n'ai pas très bien saisie son utilité, même en cherchant sur Google...

Merci d'avance,

A bientôt !

FastList = Liste = tableau dynamique (notion simplifié)
Quand un joueur se déconnecte tu n'auras pas de case vide, tu auras juste un case pointant sur un objet qui n'existe plus. Donc jolie NPE à prévoir assez facilement.
Quand tu veux "bosser" sur un joueur, il va falloir que tu tests s'il est connecté ou si la l'élément de la liste est "null" (j'ai un doute d'un coup >_<).
J'espère éclairé ta pensée un peu.

Respawner a écrit:

Quand tu veux "bosser" sur un joueur, il va falloir que tu tests s'il est connecté ou si la l'élément de la liste est "null" (j'ai un doute d'un coup >_<).

Y'a pas de doute a avoir, si l'objet a était détruit le pointeur en memoire va renvoyer "null" (Il pointe sur rien). Donc toujours vérifier qu'un objet n'est pas égal à "null" (Qu'il existe bien quoi ) avant de faire appele à des méthodes de celui-ci.

Inutile si les méthodes sont "static" bien entendu

Mais sinon dans la classe WordMap ou WordRegion je sais plus comment elle s'appele, il y a un méthode pour vérifier qu'un joueur est toujours en ligne il me semble, et ainsi accéder a son instance etc etc

Mais plutot que de stocker l'instance compléte du joueurs dans ton tableau, stockes juste l'identifiant de celui-ci et va chercher l'instance par cette fameuse classe "WordMap" tu économisera de la mémoire ce qui n'est pas négligeable je pense

J'avais donc bien vu.
Merci pour ces lumières, je vais voir un petit peu cette fameuse classe WordMap, et je reviendrais très certainement poser des questions...

Merci encore ^^.

Le pointeur ne vas pas retourner "null" car notre gentil garbage collector ne l'a pas emmené aux oubliettes !

Cependant, on ne peux rien faire sur le personnage. Pour savoir s'il est connecté ou non, utilise L2PcInstance#getClient()#getConnection()#isClosed(), supprime le de ta liste ensuite s'il n'est plus là et là le garbage collector se charge du reste.

C'est bien plus rapide que de chercher dans le L2World.

Grimly a écrit:

Le pointeur ne vas pas retourner "null" car notre gentil garbage collector ne l'a pas emmené aux oubliettes !

Il devrait pourtant Et si je me trompe pas, cela fonction par référence en java (heureusement) et donc, si l'instance n'existe plus ça doit renvoyer null, Garbage Collector ou pas... lui il n'est là que pour libérer de la mémoire alloué, par pour dire si l'instance existe toujours ou pas.

Il est d'ailleurs par convention utile d'aide le Garbage collector en mettant une variable à null pour qu'il ai moins de boulo et qu'il libère la mémoire plus rapidement.

Citation :

Cependant, on ne peux rien faire sur le personnage. Pour savoir s'il est connecté ou non, utilise L2PcInstance#getClient()#getConnection()#isClosed(), supprime le de ta liste ensuite s'il n'est plus là et là le garbage collector se charge du reste.

Le core d'L2J le gére automatiquement normalement, quand le joueur se déconnecte lui même (Bah oui pour mettre a jour le "L2word" sinon tu verrais des joueurs à coté de toi qui ne sont pas là . Si c'est une déco intenpestif, je ne sais plus trop, normalement y'a une tâche qui vérifie la connexion, et vire l'instance du joueur. ca fait longtemps que j'ai pas mis la main dans le pâté L2J.

Citation :

C'est bien plus rapide que de chercher dans le L2World.

Plus rapide à coder mais plus gourmand en ressources...

phpsteuf a écrit:

Grimly a écrit:

Le pointeur ne vas pas retourner "null" car notre gentil garbage collector ne l'a pas emmené aux oubliettes !

Il devrait pourtant Et si je me trompe pas, cela fonction par référence en java (heureusement) et donc, si l'instance n'existe plus ça doit renvoyer null, Garbage Collector ou pas... lui il n'est là que pour libérer de la mémoire alloué, par pour dire si l'instance existe toujours ou pas.

Il est d'ailleurs par convention utile d'aide le Garbage collector en mettant une variable à null pour qu'il ai moins de boulo et qu'il libère la mémoire plus rapidement.

Citation :

Cependant, on ne peux rien faire sur le personnage. Pour savoir s'il est connecté ou non, utilise L2PcInstance#getClient()#getConnection()#isClosed(), supprime le de ta liste ensuite s'il n'est plus là et là le garbage collector se charge du reste.

Le core d'L2J le gére automatiquement normalement, quand le joueur se déconnecte lui même (Bah oui pour mettre a jour le "L2word" sinon tu verrais des joueurs à coté de toi qui ne sont pas là . Si c'est une déco intenpestif, je ne sais plus trop, normalement y'a une tâche qui vérifie la connexion, et vire l'instance du joueur. ca fait longtemps que j'ai pas mis la main dans le pâté L2J.

Citation :

C'est bien plus rapide que de chercher dans le L2World.

Plus rapide à coder mais plus gourmand en ressources...

Monsieur oublie que ... s'il a ce problème de liste qui garde les joueurs déconnecté, c'est bien pour une raison. Il y a toujours un accès à la donnée (joueur) par la fastlist.
L'automate dont tu parles n'agit que sur les L2World et companie.

L'accès, vérification et suppression sont d'ailleurs très rapide car à l'aide de l'itérateur, lorsqu'on effectue les modifs, tu parcours tes personnages un par un (Iterator#next()), pour ensuite les vérifier (code que j'ai donné en haut qui n'est rien d'autre qu'une lecture d'une case mémoire, il n'y a aucun calcul), et ensuite le supprimer s'il le faut (Iterator#delete()).

Une fois delete, plus rien ne pointe sur l'objet, le garbage collector peux enfin reprendre ses droits sur l'espace mémoire anciennement utilisé.

Un objet n'est détruit QUE si plus rien de déjà accessible ne pointe sur lui. Si on néglige ce problème, on obtient une fuite de mémoire.

Grimly a écrit:

Monsieur oublie que ... s'il a ce problème de liste qui garde les joueurs déconnecté, c'est bien pour une raison. Il y a toujours un accès à la donnée (joueur) par la fastlist.

Non TU oublies que j'ai justement dit de passer par L2World, c'est ce qu'il y a de plus propre. Il est là pour ça

Citation :

L'automate dont tu parles n'agit que sur les L2World et companie.

Bien, on y vient...

Citation :

Une fois delete, plus rien ne pointe sur l'objet, le garbage collector peux enfin reprendre ses droits sur l'espace mémoire anciennement utilisé.

Inutile de refaire ce que L2World fait déjà et ce pourquoi il existe : Check des joueurs online ou pas. Le L2Word n'est pas là pour rien, inutile d'éparpiller des check de connexion partout, le jour ou L2J décide de changer ces méthodes, tu vas devoir motifier partout ou tu regardes si le joueur est connecté...

Citation :

Un objet n'est détruit QUE si plus rien de déjà accessible ne pointe sur lui. Si on néglige ce problème, on obtient une fuite de mémoire.

Donc passer par le L2World, ça évitera d'avoir des tableaux de joueurs dans tous les sens qui peuvent pointer sur des objets qui sont censé ne plus exister...

Le stockage de joueurs utilisés ici est une liste de L2PcInstance, complètement externe à L2World.

Jusqu'à preuve du contraire, L2World n'a aucune boule de cristal (et ça n'existera jamais) qui pourrais l'aider à supprimer un joueur qui se déconnecte de toutes les listes qui existent.

Donc, on a bien la liste qui pointe vers un joueur déconnecté, avec le L2Client et MMOConnexion qui vont avec !
Le garbage collector NE les a PAS détruit. L2J est codé en java, pas en C++, les destructeurs n'existent pas.

Si vraiment la liste n'avait plus le joueur, d'où viens donc le problème ?

De plus, L2World fait une vérification sur toute la liste de joueur. A 10 joueurs connectés, la différence de puissance est très négligeable. Remplace 10 par 500 et tu paie cher cette vérification ensembliste. Quand on peux faire un accès instantané à l'information, il ne faut jamais hésiter.

Citation :

Le garbage collector NE les a PAS détruit.

On s'en fout ! Du moment que ta liste centralisée ne pointe plus sur ton instance, ça vaut null point barre. Qu'il existe encore en mémoire on s'en tamponne le GC fera le nettoyage mais on pointe plus dessus.

L'intéret de cette liste centralisée c'est de pouvoir virer les joueurs à un seul endroit sans se soucier si on doit le viré partout ou tu as des listes ou des maps de joueurs qui restent...

Citation :

L2J est codé en java, pas en C++, les destructeurs n'existent pas.

Tu me prends pour qui ? Qui t'a parlé de destructeur ? Je t'ai parlé de variable == null.

Parce que si chez L2J, on devait vérifier que le joueur est belle et bien connecté à chaque fois qu'on devait faire une action dessus, ou vis a vis d'une partie de joueurs (Genre les joueurs dans un range de x).

Tu crois que ces joueurs dans un range de x on regarde s'il est vraiment connecté avant de lui appliquer un effet Fear ? certainement pas, on le sait déjà s'il est en ligne ou pas.

Citation :

A 10 joueurs connectés, la différence de puissance est très négligeable. Remplace 10 par 500 et tu paie cher cette vérification ensembliste.

500 c'est du pipi de chat, surtout quand tu accède directement à ton objet via son ObjectId, auquel cas pas d'itération, ça te renvoit ton objet ou null...

Checker si le joueur est en ligne c'est faire un travail qui est déjà fait et prévu, c'est inutile. Tu stock son ObjectId et tu le récupéres directement via L2Word ton objet ou null s'il n'existe plus dans le jeu (Et on s'en fout que le garbage collector soit passé ou non et qu'il a libéré la zone mémoire c'est pas notre problème dans le code).

Je suis d'accord avec phpsteuf c'est bien plus simple de le gérer ainsi. A quoi bon rebalancer des objets qui existent déjà dans une liste qui centralise le tout. Pour imager ça, si tu fais ça dans la base de données ça signifie que tu recrérais toutes les données joueurs dans plusieurs tables ... Tu le fais tu les gères via l'ID stoo. L'avantage de le retirer via le L2World est que t'as direct l'état du joueur. GC ou pas on s'en fout ça revient strictement au même pour le développeur. Que la case mémoire ne soit pas allouée ou qu'elle soit simplement vide tu le gères pareille dans ton code (valeur null).

Petite question, je vois qu'il y a vector, et fastlist, quelles sont les différences ?

Vector est plutôt vieux (Java 1.0 je crois). Il faut savoir que FastList n'est pas disponible dans Java à la base. Il fait partit de Javolution.
De la doc y'a rien de mieux pour comprendre.

FastList - http://javolution.org/api/javolution/util/FastList.html
Vector - http://java.sun.com/javase/6/docs/api/java/util/Vector.html

<_< En fait, on se gueule dessus pour rien du tout.

VOUS gérez votre liste de personnages par leur ID (donc liste d'entiers)
JE gère la liste de personnages par leur instance (donc liste de L2PcInstance)


VOUS aurez un "null" en faisant L2World.getInstance().getObjectById(id)
JE n'aurais aucun "null" car mon instance est toujours là et dans ce cas je lis directement la connection par celle-ci.


Nos deux coups en temps et espace mémoire sont quasiment identique (je reste plus rapide en absolu et vous moins volumineux si le GC est vraiment performant)

Nos deux raisonnements sont valables mais travaillent sur deux implémentations différentes.

Grimly a écrit:

<_< En fait, on se gueule dessus pour rien du tout.

On se gueule pas dessus

Grimly a écrit:

JE n'aurais aucun "null" car mon instance est toujours là et dans ce cas je lis directement la connection par celle-ci.

Mais celle que tu décris à un sérieux défaut, si tu gére mal les instance dans ton tableau ou ta liste (ce qui est le cas de 90% des gens qui "codent" ici) il ne penseront pas à supprimer cette valeur et ne se baseront que sur le test sur la connexion pour effectuer cette action ou non. Le résultat, c'est qu'il restera des relations vers l'instance du joueur dans le code alors que ça ne devrait pas, résultat le GC va pas faire son boulo, résultat... Fuite de mémoire. Tout ça parce que 90% ne savent pas ce qu'est le GC, à quoi il sert, et surtout qu'il existe... Après on verra du "C'est bizarre au bout de deux jours mon serveur plante et j'ai une surconsommation de mémoire et de CPU".

De plus, et là ce n'est que mon avis, mais suivant le modèle Objet, tu as une classe qui sert à aller accéder à n'importe quelle instance de joueur en ligne qui est L2World, elle est là pour ça c'est SON rôle. Donc elle DOIT être utilisé, sinon inutile de faire de la POO à mon sens... Parce qu'on perd tout l'intéret de cette méthode de programmation et d'organisation du code Mais ça reste un avis il peut être discutable.

Respawner a écrit:

Vector est plutôt vieux (Java 1.0 je crois). Il faut savoir que FastList n'est pas disponible dans Java à la base. Il fait partit de Javolution.
De la doc y'a rien de mieux pour comprendre.

FastList - http://javolution.org/api/javolution/util/FastList.html
Vector - http://java.sun.com/javase/6/docs/api/java/util/Vector.html

Merci, j'avais déjà lu ces deux pages ^^.

En prolongeant le sujet, et toujours sur la même base du joueur online, j'aimerais maintenant savoir comment faire en sorte de stopper l'event, lorsqu'un joueur précis se déconnecte.

Disons qu'on a mis un statut spécial à un joueur : player.isSpecial = true;

Et si ce joueur déco, le thread finEvent se lance, qui averti que le joueur est parti, et choisi un autre joueur "spécial".

Je doute qu'il faille faire une boucle while, ou quelque chose dans ce genre, je n'imagine même pas la ressource utilisée par la suite...

Je ne sais pas s'il existe dans L2PcInstance, mais dans L2Client, il doit y avoir une méthode onDisconnection() ou qqch comme ça.

Le L2Client n'existe pas pour moi.
Et ce thread non plus malheureusement.

Dans le L2PcInstance, il y a un thread logout, qui gère les exceptions en cas de deloggue impossible, mais je n'arrive pas à savoir quand il est lancé...

L2GameClient

Respawner a écrit:

L2GameClient

Autant pour moi ^^'.

"Au temps pour moi" xD

cf : http://www.langue-fr.net/index/a/au_temps-autant.htm

Le français... Quelle langue étrange...

Au temps pour moi