[CENTRALISATION] DarkTime

Voici un topic où tu devrais pouvoir centraliser tout tes posts, et où nous essayerons de te fournir to *tousse* les réponses

Cette centralisation te permettera d'avoir un suivi, ainsi que l'avantage de regrouper en un seul endroit TOUS les posts de DarkTime.

Bon courage encore pour votre projet... Et que la force soit avec toi

Bonjour à tous et merci d'avoir créer un topic juste pour nous !

Le premier problème auquel je suis confronté est le suivant :

Comment faire pour qu'après un reboot, les PNJs présent par défaut sur une map, et ayant été tués, ne réapparaissent plus de façon intempestive ?

Ce sujet a déjà été débatu sous MSN avec Silk, mais je voulais avoir d'autres avis et vous faire part de mon idée.

L'idée que j'ai eu est la suivante, je voudrais que vous me donniez votre avis sur le lag éventuel que cela pourrait générer.

Je pensais inscrire une variable persistante de type int ( fonction : ff_SetPersistantInt ) sur l'event Ondeath de chaque PJ, dans une table spéciale nommée pnj_death.

Et tester ensuite dans l'event pre spawn de chaque PNJ (mais faire ce test une seule fois, pas à chaque fois que l'event se déclenche) si la variable persistante en question est présente dans la bd, et le cas échéant, détruire le PNJ.

La fonction en question semble assez rapide, du moins dans en petit mod de test que j'ai réalisé, mais si le module devient plus gros et plus peuplé, qu'en sera-t-il à votre avis ?


Merci de vos réponses !

Enki a écrit:

Comment faire pour qu'après un reboot, les PNJs présent par défaut sur une map, et ayant été tués, ne réapparaissent plus de façon intempestive ?

Ici, tu as 2 possibilités :

1- Tes PNJs font partie intégrante de ta map et là honnêtement... galère ! Pas forcément que ce soit compliqué mais cela t'obligera à stocker dans une base de données l'état "PNJ tué" (POUR CHAQUE PNJs considéré) et lier le tout à un Spawn. Cela va donc impliquer :
des appels du OnSpawn à chaque fois qu'un PJ ente dans la zone
résoudre d'éventuels conflits : que faire si un PJ d'un groupe à tuer le PNJ et pas les autres, qu'il ne l'ont jamais rencontré, etc...
des accès à la base de donnée et R/W pour CHAQUE évenement
... ce qui risque à force de surcharger le CPU et de créer des lags

2- Créer dans ta bibliothèque l'ensemble de tes PNJs et/ou les mettre dans une zone (d'attente) spécifique. Ainsi, lors d'anim, tu les auras sous le coude et il n'apparaîtront QUE lorsque tu fera appel à eux.

Voilà ! Personnellement, j'opterai pour la solution 2... mais ce n'est QUE m'on avis

Bonjour et merci de ta réponse !

En fait, je pense que les deux solutions proposées ne sont pas incompatibles.

Je viens de faire un test sur un petit mod d'une dizaine de zones avec environ 200 PNJs de tag distinct et la première possibilité. évoquée au dessus.

Aucun lag n'est à constater.

Je pense qu'il faut considérer trois type de PNJs :


- Les PNJs apparaissant depuis des triggers ou des scripts : ceux là ne sont pas concernés par le système de "mort persistante".

- Les PNJs des anims : Eux non plus, ne sont pas concernés.

- Les autres : ces PNJs là, auront les scripts qui testeront s'ils ont déjà été tué, et si oui, seront détruit durant l'event pre-spawn.
S'ils n'ont pas été tués, le script ne retestera pas la Base de Données à chaque fois qu'un PJ les croise.
Cela implique plusieurs choses à mon avis :
- d'une part, que ces PNJs ne soient pas trop nombreux.
- d'autre part, de mettre en cache les scripts en question.
- Bien sûr, que chaque PNJ concerné par ces scripts ait un tag différent des autres PNJs. ( La variable que j'utilise tien compte du tag du PNJ pour éviter de faire des dizaines de scripts différents)
- Enfin, il faut de temps en temps regarder la base de donnée des pnjs morts, et faire le ménage sur le mod ( comme leur tag est inscrit dans les variables de la Base, il est aisé de les retrouver).

Qu'est-ce que vous en pensez ?

Par ailleurs, cela m'amène à poser une question de gros débutant ^^

Pour faire mon test avec les 200 pnjs, j'ai utilisé la base de donnée "global", qui est créée par défaut par NWN-FF.

Je ne sais pas comment en créer une autre, qui serait réservé au PNJ mort ?

Est-ce que vous pourriez, brièvement et quand vous en aurez le temps, m'expliquer la marche à suivre ?

Merci encore pour votre aide !

salut, comme je suis en crete je ne peux pas trop m attarde. Juste pour te dire que si tu as fait ton test avec 200 pnj et 1PJ ca peut passer mais si il y a 30 PJ qui vont chacun dans une zone differente avec une vingtaine de pnj ds chaque zone, ca ne sera plus pareil car il y aura une trentaine d acces a la bd en meme temps...

Pour ce qui est de la variable de mort de pnj tu n a pas besoin de creer une autre base, mais en fait une autre table !

dans le script ff-buildtable tu rajoute une ligne du genre CREATE TABLE mortpnj IF NOT EXIST (`champ1`,`champ2`...) tu n a qu a prendre exemple sur une autre table cree (salete de clavier qwerty)

Bon je vais me baigner a ++ je reviens le 07 juillet)

Silk le veinard qui passe des vacances en Crète a écrit:

Juste pour te dire que si tu as fait ton test avec 200 pnj et 1PJ ca peut passer mais si il y a 30 PJ qui vont chacun dans une zone differente avec une vingtaine de pnj ds chaque zone, ca ne sera plus pareil car il y aura une trentaine d acces à la bd en meme temps...

Oui, ta remarque est très pertinente, il faudra faire pas mal de test en multi, et si cela ne fonctionne pas, simplement désactiver les lignes des scripts concernés.

Je voulais précisément parler d'une nouvelle table, mais mon vocabulaire était imprécis : Merci et bonne baignade !

Silk a précisé ma pensée lorsque je te disais "il faudra faire un accès à la base à chaque fois qu'un PJ entre dans la zone" car je n'avais pas dû être clair.

C'est en effet les temps d'accès R/W sur la table qui vont prendre du temps. ... Et tu auras un accès POUR CHAQUE PJ !!!
En effet, il n'est pas sûr que tu puisses te contenter de lire la table une fois pour toute (à la connexion du PJ sur le module par exemple) car là, tu seras confronté à un autre problème : tu auras des TAS de variables globales (pour quelles puissent passer d'un script à l'autre), multipliées par autant de joueurs connectés...

De quoi c'est la m**** !?

Sinon, pour ton problème de création de table, j'ai déjà donné un exemple --> ici

Oui, je vois maintenant ce que tu voulais dire.
Est-ce qu'il te semble davantage possible de faire un script dans le OnModuleLoad, ( donc avant que les joueurs ne se connectent )
qui ferait une boucle de tous les PNJs possédant la variable et le cas échéant, le détruirait.
Il y aurait ainsi de nombreux accès à la base de données mais avant que les joueurs ne se connectent et donc, cela ne produirait qu'une seule fois (et ne devrait pas causer de lag in Game bien que le chargement du mod serait plus long.)

Qu'en penses-tu ?

Crois-tu que le chargement du mod serait beaucoup trop long ?

Enki a écrit:

Est-ce qu'il te semble davantage possible de faire un script dans le OnModuleLoad, ( donc avant que les joueurs ne se connectent )
qui ferait une boucle de tous les PNJs possédant la variable et le cas échéant, le détruirait.
Il y aurait ainsi de nombreux accès à la base de données mais avant que les joueurs ne se connectent et donc, cela ne produirait qu'une seule fois (et ne devrait pas causer de lag in Game bien que le chargement du mod serait plus long.)

Qu'en penses-tu ?

Crois-tu que le chargement du mod serait beaucoup trop long ?

Je vois ce que tu veux faire, mais je ne pense pas que Aurora puisse le faire. En effet, cela implique que tu puisses créer DYNAMIQUEMENT les variables !

Je m'explique !
10 PJs ont tué le PNJ "Machin", tu stockes alors dans ta base les états suivants (en fonction de comment tu organises ta table) :
PJ1 a tué : Machin, Truc, Bidule, etc...
PJ2 a tué : Bidule, etc...
.....
PJn a tué : Chose

Le nombre de joueurs inscrit dans ta base augmentant (et donc les entrées dans ta table), il faudra que le OnModuleLoad créé un nombre de variable X=nbre_de_PJ_dans_la_table_PNJDead*nbre_d'entrée_par_PJ
Ces 2 grandeurs étant, bien entendu, variables.

Or donc, je ne pense pas qu'Aurora sache déterminer X !?

Toutefois, je pense à un truc...
*petite lumière qui s'allume*
Tu peux toujours tenter d'effectuer une double boucle (mais je ne sais pas si ça marchera) qui
lise une ligne "tant que différent de NULL"
passe de ligne en ligne "tant que différent de NULL"
Et là, on en revient au problème du nombre de variable X a gérer !

Quoi on tourne en rond ?

En fait, je pensais à un truc beaucoup plus simple, dis moi si tu penses que c'est possible.

Je créé une table ayant pour nom :

"mort_pnj"

Dans le script OnDeath de mes PNJs, je demande que le tag du PNJ qui vient de mourrir soit inscrit sur la table.

Pas le nom du joueur, ni rien de la sorte, une table avec une liste des tags des pnjs morts.

Ensuite, sur le OnModuleLoad, je récupère toutes les variables de cette table, qui correspondent aux tags des PNJS à détruire, et via une boucle, je demande que les PNJs portant ces tags soient détruits.

OK ! Je vois ce que tu veux faire !

Et là, je pense que tu te fais ch*** pour rien !
Si tu veux qu'un PNJ mort soit définitivement mort, vire-le carrément du module et recompile !

... Et là, plus de problème de test, de table, (...) de OnSpawn ni de lag

PS
Je ne suis plus joignable avant 1 semaine à compté de.... maintenant !

Encore moi et oui !

Ce qu il faudrait c implementer un fichier texte des nom des pnj tue et les supprimer au fur a mesure ou faire dans le onload comme tu disais c une bonne idee ms je ne sais pas si ca va marcher...

sinon,si des pjs tuent tout tes pnjs, que restera t-il aux autre pjs qui viendront par la suite ? (il y a des serial killer ...)

Tu t'en sors Enki ?