Monde persistant et journal de quête ?

Répondre
Partager Rechercher
t'es passé ange toi......grrr

*s'ébat dans l'eau en se disant que dauphin, c'est pas top..t'as la télépathie mais personne te comprend*

(occupe le post pour pas qu'il descende en deux secondes)
Je ne sais pas, le journal reste entre 2 connections ? (sans reboot serveur)

Parce que si c'est le cas, il y a peut-être possibilité de créer une fonction tirant parti du PUMA pour garder ca... l'idéal serai de pouvoir limiter une entrée du journal a une ligne dans le log.
Faut voir aussi avec la longueur de chaine nécessaire.

Sinon si tu as du courage Jaha, tu attribue un numéro a chacune de tes quêtes et tu conserves par persistance l'état d'avancement de celle ci. Avec un peu d'organisation du devrai alors pouvoir déterminer quelles sont les entrées a afficher dans le journal. (je ne sais pas si je suis clair la)

Bref beaucoup de supposition et peu de certitude.
Un truc qui pourrait éventuellement t'être utile selon le moment que tu choisis pour faire tes sauvegarde: tu es sûrement déjà au courant, mais l'état d'avancement d'une quête est stocké sur le PJ concerné et peut être récupéré ainsi:
Code PHP:

int iState GetLocalInt (oPC"NW_JOURNAL_ENTRYtag_de_la_quête"); 

Citation :
Ajout des variables personnalisées dans le système de journal. Promis juré, c'est vrai cette fois.
modification dans la 1.29.(voir persistant sur la tour effondrée)


*je me demande quand même si il s'agit bien du journal dans aurora ou du journal log du serveur nwn.....*

voila si ca peut être utile.......
Je remonte ce post juste pour dire que sur un module (ile_de_lloth), dans les modules persistants (2) , j'ai vu un systeme de stockage des quetes dans une petite boite, celles ci etant dans l'inventaire, et donc sauvegardée avec le personnage.

woila, woila

a+
Ouais mais ça reste encore un système qui surcharge l'inventaire. Je crois que ça va finir en une énorme collecte de variables persistantes a l'entrée du joueur dans le module...

Jaha Effect
Il suffit de choisir un objet du Joueur (getFirst...) et de lui coller un script qui garde en mémoire le journal, non ? Puis un autre qui indique que si il n'est plus dans l'inventaire, il faut redéfinir. Ou bien spécifier une redéfinition toutes les x secondes. Enfin utiliser l'existant uniquement. Vais voir *baille* demain.:baille:
Citation :
Provient du message de Jaha Effect
Ouais mais ça reste encore un système qui surcharge l'inventaire. Je crois que ça va finir en une énorme collecte de variables persistantes a l'entrée du joueur dans le module...

Jaha Effect
Tu n'as pas tort du tout lol Jaha, je pense que le meilleur moyen , cela serait en utilisant le PUMA en attendant qu'on trouve mieux (database de bioware peut être ) ,

RAT
Bon alors c'est super simple du moment que tu ne changes pas de module. Tu assignes une variable à chaque entrée du journal, tu regroupes toutes ces variables en binaire, et tu as tout à coup en une variable tout ton journal, crypté selon le nom du joueur. Bon. Le problème c'est que si tu as 200 joueurs, et ben t'as deux-cent variables binaires... Oups. . Donc tu fais en sorte qu'elle n'existent que quand le joueur est là; le reste du temps elles sont reliées à un objet de son inventaire. En fait c'est le choix : un objet d'inventaire (disons un anneau) ou alors un amas de variables.

Ca intéresse encore quelqu'un ce problème ? Non ? Bon.
Dévelloppement :

Ben tu associes à chaque entrée du journal un numéro. En binaire tu peux stocker plus de variables : par conséquent, une variable en binaire par joueur suffirait. Ca surchargerais pas trop le CPU, une variable par joueur, non ?
Deuxième idée = la variable est éphémère : elle est stockée sur un objet du joueur déjà existant (genre son épée) puis détruite. Quand le joueur revient, l'épée fournit toute seule le journal. Ainsi les variables journal n'apparaissent qu'au téléchargement, pendant une fraction de seconde, et ne chargent pas le CPU du tout.

Bon il doit il y avoir un truc à prendre dans cet amas de trucs impossibles
Si tu fais référence à au système d'Azrael et Jédaï, ils ont orienté ça plutôt sur des valeurs booléennes à stocker par des valeurs binaires, je crois que là manipulation de int en l'occurrence risque d'être beaucoup moins drôle surtout que je n'excelle pas du tout en la matière. Ca me fait l'impression d'avoir un remède pire que le mal mais je me trompe peut être?

Jaha Effect
Et bien je dirais que le script serait effectivement assez dur. Je ne pense pas y arriver seul. Je dirais aussi que le mal n'est pas bien grand, mais qu'un seul script permet de s'en débarrasser, si on s'y mettait à 3, par exemple, je suis sur qu'en 6 heures on arriverait à une ébauche correcte. Mais bon... Moi je suis prêt à tenter, mais bien qu'ayant appris les scripts à une vitesse grand V (une capacité innée, peut-être), je n'ai pas la maîtrise technique de beaucoup (ça doit faire 20 jours que je scripte, grosso modo). Donc seul, je ne peux pas. Si quelqu'un veut tenter, je suis partant.
Le gros problème des variables booléennes, c'est qu'elles ne sont pas très adaptées au stockage de l'état d'une quête qui peut avoir plus d'une dizaine de niveau de progression...

Peut-être une variable hexadécimale serait-elle plus adapté, avec ses 16 états possibles ?
(Là c'est à Jaha de ma répondre )

L'avantage, c'est que tu peux en stocker 32 sur un seul tag et 8 sur un seul local int.

Donc à toi de voir si cette solution te convient (je suppose naturellement que tu es en servervault) : A l'arrivée d'un joueur tu vérifie s'il possède un objet de nom "stock_quest" et tu lis son tag pour restaurer l'état de ses quêtes. Ensuite tu détruit l'objet et au cours du jeu tu mets à jour 4 local int grâce à des fonctions de mise à jour du journal personnalisées. A la sortie, il te faudra recréer l'objet sur lui, ce qui sous entend qu'il te signale sa sortie avant de déconnecter (l'idéal serait que tu puisse utiliser les emplacements de créatures, auquel cas, tu te contentes de mettre à jour l'objet en même temps que les local ints, ça serait mieux (les local ints sont plus rapides à accéder mais peut-être pas indispensable dans ce cas))

Par contre il te faudra définir l'ordre dans lequel tes quêtes seront stockés en dur.

Bon, faudrait quand même vérifier, si ça se trouve c'est très facile à faire avec un petit outil extérieur, que je serais prêt à te faire.
Je pense également que les variables hexa sont plus adaptées au stockage de variables de quête. Par contre les emplacement créature, enfin la peau me sert déjà à autre chose donc là faudrait trouver une autre alternative mais bon c'est pas vraiment une problème.
En fait, je pense que je vais attendre la persistance de bioware pour régler ce problème, je pense que ça devrait plus trop tarder puisque c'était prévu pour Mars.

Jaha Effect
Répondre

Connectés sur ce fil

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