[SYSTEME] Le PUMA!

Répondre
Partager Rechercher
Donc je vous donne la fonction pour eviter de vous faire chercher . Donc c'est avec cette fonction que vous rajouter dans le OnLeave du module, et cela sauvegardera la loc des PC.
Comme je vous ai dis, je l'utilise moi même .

De plus si un jour vous vous en rappelez plus, il se trouve logiquement si je ne me trompe pas dans le readme du pwum. Par contre je dois avouer qu'il faut quand même le trouver mais bon .

Enfin donc voilà cette fameuse fonction:

Code PHP:

    SetPCToSaveLocation(oClient); 


oClient est bien sur l'object qui sort du module donc GetExitingObject();

voilà,

Si vous avez d'autres questions, je suis tout ouïe.
Citation :
g remaqrué que le puma revenai a la normal qd je fermai le server
Ah ouiiiiiiiiii !
En fait c'est pas un plantage, il attend juste la fin de l'execution du nwserver.exe

Pour tout expliquer, PUMA n'utilise qu'une seule procedure pour tous les appels d'exécutables externes (1 a 3 appel a nwnnsscomp.exe et 1 appel a nwserver).

Au départ, il n'attendais pas la fin d'un exécutable pour continuer, mais les appels a nwnnsscomp trop rapproché causais des accès concurrentiels au fichiers pwum_function.nss (dans le répertoire override). La fonction a donc été modifier pour attendre la fin de l'exécutable, y compris dans le cas du nwserver.exe (puisque c'est la même fonction).

C'est bien noté, ce sera corrigé dans la prochaine version (quoique je ne vois pas d'intérêt a toucher au PUMA une fois le serveur lancé)

En tout cas bravo, fallait le trouver ce bug la !
Citation :
Provient du message de Iridian
Il doit sûrement y avoir une bonne raison pour ne pas avoir mis le script dans le onExit, reste a voir si avec les changements de versions de nwn certaines choses n'ont pas été corrigé.
Là ça me surprend beaucoup, ce que dit Rat, parce que chez moi le GetLocation(GetExitingObject) dans le onClientLeave du module, ça renvoie une location vide (une area "", et 0.0 dans les trois vecteurs). Visiblement l'objet est détruit dès sa déconnexion, et plus moyen d'accéder aux informations qui le concernait (c'est très frustrant ).

Du coup, le timewarp dont parle Taern devient très gênant, puisqu'il survient à chaque déco/reco, même si le serveur n'a pas été rebooté entre deux. Or dans le cas normal (sans ResumePCLocation), le serveur stocke bien la position et la restore au retour du joueur s'il n'y a pas eu de reboot.

J'ai commencé par contourner le désagrément (faute de mieux) en passant les sauvegardes de position à la fréquence de 30 secondes (au lieu de 300s), ça ne posait pas trop de problèmes vu la rapidité de la fonction de sauvegarde, mais le log a vite enflé et je me retrouvais avec 2,5 mb de logs tous les jours (que le PUMA digérait très bien, au passage même si dans ces cas là il rame pendant trente secondes en donnant l'air d'être planté).

Actuellement, je note le "numéro" de ma session dans une variable persistante incrémentée à chaque reboot et je ne lance ResumePCLocation que si la location sauvée appartient à une session strictement inférieure (autrement dit, je ne Resume pas s'il n'y a pas eu de reboot, vu que le jeu le gère très bien de lui-même, et sans time warp). Inconvénient, je dois sauver le numéro de session avec chaque sauvegarde de position (mais je pense pouvoir gérer ça par la date d'expiration des variables, en la comparant à la date de reboot du module... je verrai bien).

Bref, dans mon cas c'est loin d'être aussi simple qu'il n'y paraît. Donc si vous avez quelque chose de plus optimal, je prends.
Ba personnellement, je ne peux rien te dire de plus que ce que j'ai testé.

En mettant cette fonction là, tant que le serveur ne reboot pas, je ne perds pas du tout la localisation de mon PC.

Je peux vous le dire, j'ai testé PWUM sur pas mal de chose, et mon module de test l'utilise tout le temps.

Donc maintenant, je ne peux rien vous dire de plus! qu'avec cette fonction, je sauvegarde bien la loc.

Voilou
Je crois en avoir une pas mal, alors je la mets ici

Gadjio, et si tu mettais une simple variable locale (tu sais, celles qui ne contiennent pas les lettres P, U, M et A ) sur ton module ? un truc genre "location_chargée"+le nom du PJ+la clé publique.
Comme ça, si le joueur se connecte et que la variable sus-dite est à 1, tu n'exécutera pas sur lui la fonction ResumePCLocation(). Sinon, tu le fait (et tu mets la variable à 1)

Comme ça, si le serveur reboot, toutes ces variables seront effacées et on repart pour un tour Résultat, un timewarp par reboot de serveur au lieu d'un à chaque reconnexion.

@ Vifounet : SetPCToSaveLocation(oClient); c'est pas seulement pour enregistrer la position du joueur, c'est aussi et surtout pour dire au script que cette position devra être enregistrée à chaque éxécution du script "pwum_loctimer".
Enregistrer la position se résume à une simple écriture dans le log, et pour la connaître précisément tu copie-colle la ligne du "pwum_loctimer" concernée.

Vivi tout à fait, je suis d'accord avec Taern. Mais justement, et c'était marqué dans le readme, cette fonction va sauvegarder en locale, donc non par le pwum, donc cela ne créera aucun conflit.
Mais cela permet donc sans plantage du serveur, d'enregistrer donc sa loc à ta sortie.

En tout cas c'est comme ça que marche mon module .
Citation :
Provient du message de Gadjio
Là ça me surprend beaucoup, ce que dit Rat, parce que chez moi le GetLocation(GetExitingObject) dans le onClientLeave du module, ça renvoie une location vide (une area "", et 0.0 dans les trois vecteurs). Visiblement l'objet est détruit dès sa déconnexion, et plus moyen d'accéder aux informations qui le concernait (c'est très frustrant ).
Oui, OnExit ne se déclenche que lorsque l'objet est déjà sorti du module, donc il est à peu près impossible d'accéder à la moindre information concernant cet objet (Oui bon, on peut en récupérer quelques unes en forçant un peu, mais rien de bien utile)
OnExit sert principalement à la maintenance générale du mod - à rien, en gros- et pas à la gestion des persos, pour autant que je sache. Il vaut mieux passer par d'autres solutions (il en existe de toutes sortes) pour enregistrer la localisation d'un joueur.
10 minutes me parait un délai un peu long aussi Il me semble préférable de mettre à jour un peu plus fréquemment les variables de position du joueur. Ca ne signifie pas qu'il faille forcément enregistrer le log aussi souvent, ce sont deux choses distinctes.
Bin moi aussi, Rat !! Non j'invente pas tout ça exprès pour t'embêter..

Bonnes idées, Taern et Cheni (coucou toi, d'ailleurs ). Je vais mettre :
-une variable locale qui signale si le PJ s'est déjà connecté depuis le dernier reboot. (Et si oui, alors on n'appelle pas ResumePCLocation.)
-Une sauvegarde dans une variable locale toutes les minutes, qui récupèrera la position des PJ comme le fait LocationTimer, mais qui la stockera simplement en SetLocalLocation.
-Une sauvegarde PUMA vers le log toutes les cinq minutes, par LocationTimer, mais qui écrira plutôt le contenu des variables ci-dessus (les LocalLocation prises chaque minute).

Enfin... je vais surtout faire le premier point, les deux suivants je ne sais pas encore. A priori, ça servirait uniquement pour avoir une sauvegarde plus récente de la position d'un perso qui déco et qui ne reco qu'après un reboot... J'ai l'impression qu'on peut s'en passer (un GetFirstPC.. GetNextPC toutes les minutes, c'est lourd).

Merci pour les conseils en tout cas. J'arrive toujours à faire à peu près ce que je veux, mais en général je le fais n'importe comment parce que je suis pas très doué J'ai quasi commencé à programmer avec le Toolset, il y a un mois, donc j'ai pas encore beaucoup de réflexes même pour des trucs évidents
Bonjour tout le monde,

pour commencer, et bien j'ai qu'une chose à dire, BRAVOOOOO

Sinon, je me rends compte de plus en plus que je vais avoir besoin du System PUMA, d'ou ma question (j'ai vraiment la fleme de chercher) existe t'il un pakage comprenant tout ce qui est nécessaire pour mettre en place ce systéme? et un petit mode d'emploi au passage?

Merci d'avance

Prophetia
Ba je n'ai qu'un seul mot à dire pour t'aider : "oui" lol , oui tout à fait. En téléchargeant notre dernière versions, tu auras tous les scripts à mettre, une explication pour l'installer. Et même un module pour le tester
oooops, désolée, mais entre temps ben j'ai trouvé, c'etait pas compliqué à trouver d'ailleur
Donc j'ai télécharger la version 0.4 et testé avec le module de test, et bien maintenant, je vais tenter d'integrer tout ça à mon module et de voir ce que ça donne

Sinon, il y a des correctif de script ou nouveau scripts recommandé qui serrait sorti apres la version 0.4?

En tout cas merci pour ce travail formidable
Ba de rien .

Donc non il n 'y a pas eu de correctif depuis, car normalement tu as la dernière version c'est à dire là ou il y a toutes mes fonctions pour le système de banque et donc tous les rajouts qu'a fait iri sur le log.
Citation :
Provient du message de Prophetia Astrae
Bonjour tout le monde,

pour commencer, et bien j'ai qu'une chose à dire, BRAVOOOOO

Sinon, je me rends compte de plus en plus que je vais avoir besoin du System PUMA, d'ou ma question (j'ai vraiment la fleme de chercher) existe t'il un pakage comprenant tout ce qui est nécessaire pour mettre en place ce systéme? et un petit mode d'emploi au passage?

Merci d'avance

Prophetia
Oui, le package explication est un forum plutot sympa où traine pleins d'allumés du bocal en manque évident de sommeil.
PUMA et Base de données?
Je me demandais, si j'ai bien compris, le PUMA ecrit des données dans le fichier de log du serveur pour stocker les donnés, puis vient lire ce meme fichier de log afin de les récuperer.
Je me demandais, si il etait envisageable de remplacer ce fichier de log par une base de donnée?

Je pense que le systéme serrait bien plus performant de cette façon, les requête faites sur une base de donnée étant bien plus rapide que la recherche dans un fichier à plat...

c'est une idée comme ça, peut etre y avez vous déjà pensé, peut etre pas, mais si c'est possible d'avoir les source du systeme, je veux bien y jetter un petit coup d'oeil, mais m'ettant pas penché plus que ça sur le probléme, je ne sais meme pas si c'est possible.

Prophetia
En fait pour l'instant il y a des fonctions du toolset qui permette de créer une entrée dans le log (le nwserverlog1.txt est toujours généré, avec ou sans Puma). Donc le Puma exploite ce truc pour créer une entrée personnalisée, de type "<PUMA>blablabla", comme ça en fouillant le log, le parser peut récupérer les infos écrites spécifiquement par les fonctions du Puma (y compris des choses comme le nom d'une variable et ce qu'elle contient). Il utilise donc le log simplement parce que c'est le seul moyen à ma connaissance d'écrire dans un fichier à partir d'un module lancé.

Si Nwn gère les bases de données (comme c'est prévu un jour en principe), on aura sans doute des fonctions pour écrire ailleurs que dans le log et ça pourra être exploité aussi.

(Je crois que pour l'instant la seule fonction d'output extérieur au module est le WriteTimestampedLogEntry(), mais faudrait vérifier)
Nop, tu en as une ou deux autres fonctions mais elle s'écrit dans le même fichier Log. La différence entre celle que tu donnes et les autres, c'est qu'elle donne l'heure en même temps
Les BdD de nwn sont prévu pour le mois prochain (donc comptes milieu du mois d'après, puisque la 1.28 prévu en janvier sort comme maintenant).

Mais je suis septique quand a la praticité d'utilisation de ces nouvelles fonctions
-pourra t-on partager la base entre 2 serveurs ? (ce serai la panacée)
-pourra t-on exploiter cette base hors nwn ? (par odbc ou autre)

L'avenir nous le dira
Et si l'avenir nous dit OUI (pour le 2e point) préparez vous a une suite de logiciel d'aide a la gestion de persistant
(avec bon nombre des idées évoqués sur ce forum)
Répondre

Connectés sur ce fil

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