[¤ TynriL ¤]

Script initialement proposé par Azrael07 !

Citation :

Comme promis dans un coin paumé du forum je vais donné un script pour "emuler" un OnHeartBeat, qui sera activé uniquement si un joueur est dans l'area.
C je pense bcp moins lourd que le OnHeartBeat.

Bon finis les blabla voici le fameux code :

Dans le OnModuleLoad rajoutez la ligne suivante

Code PHP:

SetLocalInt(GetObjectByTag("TAGAREA"),"iPlayerInAreaTAGAREA",0);
//Ca correspond a une variable qui donne le nombre de joueur actuelement dans l'area conserné. 

Puis dans le OnPlayerEnter de l'area

Code PHP:

//OnHeartBeat emulator
//Created by Azrael
//File for OnEnter of area

int iPlayerInArea;//Nombre de joueurs dans l'area
void main()
{
iPlayerInArea = GetLocalInt(OBJECT_SELF, "iPlayerInAreaTAGAREA");//On recupere l'integer qui sauvegarde le nombre de joueurs dans l'area
iPlayerInArea++;//On incremente la valeur
SetLocalInt(OBJECT_SELF,"iPlayerInAreaTAGAREA", iPlayerInArea);//Et on l'archive de nouveau
if (iPlayerInArea == 1)//Si c'est le premier joueur qui arrive
{
ExecuteScript("NOMDUSCRIPT",OBJECT_SELF);//On active le script qui definira l'action
}

} 

Dans le OnExit meme chose :

Code PHP:

//OnHeartBeat emulator
//Created by Azrael
//File for OnExit of area

int iPlayerInArea;//Nombre de joueurs dans l'area
void main()
{
iPlayerInArea = GetLocalInt(OBJECT_SELF, "iPlayerInAreaTAGAREA");//On recupere l'integer qui sauvegarde le nombre de joueurs dans l'area
iPlayerInArea--;//On reduit la valeur
SetLocalInt(OBJECT_SELF,"iPlayerInAreaTAGAREA", iPlayerInArea);//Et on l'archive de nouveau
} 

Maintenant voici le gros paquet, c'est un script independant appelé par ExecuteScript("NOMDUSCRIPT",OBJECT_SELF), mais vous devriez donner un autre nom pasque NOMDUSCRIPT c pas terrible -lol-

Code PHP:

//OnHeartBeat emulator
//Created by Azrael
//New script called by OnEnter of area

//Le nombre de joueurs dans l'area, indispensable pour pouvoir tout arreter si y'en a plus
int iPlayerInArea = GetLocalInt(OBJECT_SELF,"iPlayerInAreaTAGAREA");
int iSecond;//Pour retenir la seconde (voir + loin)
int iNextAction = GetTimeSecond();//La prochaine action realisee

void main()
{
while(iPlayerInArea > 0)//S'il n'y a plus de joueurs la boucle se termine
{
//On retient la seconde actuelle pour :
// 1.Ne pas surcharger en appelant tjrs le temp par la fct
// 2.Etre sur qu'on ne change pas de secondes entre deux lignes de codes (tres peu probable mais possible)
iSecond = GetTimeSecond();
//Si il y a eut 6 secondes depuis la derniere action...
if (iNextAction >= iSecond)
{
//...On reinitialise la variable du temp pour la prochaines action

//En revenant a zero si le temp a depasse 54(prochaine action dans 6s : 54+6 = 60, c a dire hors de l'echelle des secondes

if (iSecond >= 54)
{
iNextAction = iSecond - 54;
}
else
{
iNextAction = GetTimeSecond() + 6;
}

//Ici on a reproduit un OnHeartBeat qui ne se produit que si des joueurs sont dans l'area.
//Vous pouvez donc mettre ici votre code comme normal
//Si vous faites un ExecuteScript vous pouvez meme cibler un autre objet
}
//On update le nombre de joueurs present dans l'area
iPlayerInArea = GetLocalInt(OBJECT_SELF,"iPlayerInAreaTAGAREA");
}
} 

Alors l'interet d'appeler un nouveau script au niveau du OnEnter, c d'une part pasque je trouve que c plus propre, bon c vrai qu'on s'en fous que ca soit sale du temp que ca marche...
D'autre part je ne suis pas sur que l'on puisse appeler deux fois le meme script en meme temp.

A oui je viens de penser a un bug : si jamais un joueur meurt dans l'arene?
Il faudrait rajouter dans le OnPlayerDeath du module un code du style "Si le player est dans l'arène, alors virer un player dans iPlayerInAreaTAGAREA.

Bon maintenant la question qui tue : a quoi ca sert puisqu'on a deja le OnHeartBeat
En fait, le serveur n'aura a calculer l'action que si un joueur est dans l'area, contrairement au OnHeartBeat.

Le problème c que g pas pu le tester car jusqu'a la fin des vacances je suis sur un pII 350, alors si Aurora peut passer, neverwinter c meme pas la peine
Je vais ouvrir un post sur le forum pour commenter le script, comme Uther a demander, y'en a qui on dut oublier, de pas commenter les scripts dirrectement sur cette page...

N'hesitez pas à me donner toutes propositions/améliorations, coup de geule, enfin je sais pas moi.

Et puis si y'a qlq qui veux bien le tester pour etre bien sur que ca marche...

[eMRaistlin]

Apres des tests preliminaire, il semble que si un joueur meurt et quitte l'area, ca declenche le OnExit. (pour info)

[¤ TynriL ¤]

Pas certain pour les déco/reco par contre... Enfin, c'est bricolable en faisant un SignalEvent sur le ClientEnter/ClientExit, mais c'est chiant.

['Az]

Bon j'en ai marre de voir ce script en tête des liste de script alors qu'il ne marche pas, alors je le corrige, maintenant que j'ai la sagesse et l'experience de mon coté (ralala les erreures de jeunesse ^_^)

Code PHP:

//OnHeartBeat emulator
//Created by Azrael
//File for OnEnter of area

void OnHeartBeat();

void main()
{
    int nPlayerInArea = GetLocalInt(OBJECT_SELF, "nbrPC");//On recupere l'integer qui sauvegarde le nombre de joueurs dans l'area
    nPlayerInArea++;//On incremente la valeur
    if (nPlayerInArea == 1) DelayCommand(6.0f, OnHeartBeat());//On active le script qui definira l'action

    SetLocalInt(OBJECT_SELF,"nbrPC", nPlayerInArea);//Et on l'archive de nouveau
}

void OnHeartBeat()
{
    if(!GetLocalInt(OBJECT_SELF, "nbrPC")) return;

    //code....

    DelayCommand(6.0f, OnHeartBeat());//On active le script qui definira l'action
} 

OnExit :

Code PHP:

//OnHeartBeat emulator
//Created by Azrael
//File for OnExit of area

void main()
{
    int nPlayerInArea = GetLocalInt(OBJECT_SELF, "nbrPC");//On recupere l'integer qui sauvegarde le nombre de joueurs dans l'area

    nPlayerInArea--;//On reduit la valeur
    SetLocalInt(OBJECT_SELF,"nbrPC", nPlayerInArea);//Et on l'archive de nouveau
} 

Voila, ca devrait mieux marcher....

qu'est ce que je scriptais mal a l'époque ^^

EDIT : vi par contre y'a le problème des decos/recos que j'ai pas corrigé... tampis

[Jedaï]

Les décos/recos y devrait pas y avoir de problème.

Par contre, vu comme c'est écrit je ne suis pas sûr de l'opportunité d'utiliser ce script : Il faut absolument que tu entoure ton code dans un bloc, sinon ça va être l'enfer : DelayCommand() copie toutes les variables "vivantes" dans le script au moment de son appel....
C'est une fonction qui n'est absolument pas optimisé de ce point de vue...

Donc faut l'utiliser prudemment, je te conseille plutôt :

Code PHP:

void OnHeartBeat()

{

    if( GetLocalInt(OBJECT_SELF, "nbrPC") ) 
    {
        //code
    }
    else return;

    DelayCommand(6.0f, OnHeartBeat());//On active le script qui definira l'action

} 

Ca évitera que tu perdes du temps CPU plutôt que d'en gagner....

['Az]

euh.... je n'ai pas très bien compris la...

si DelayCommand copie de toutes facon toutes les variables, en quoi cela nous avancerais de le mettre entre crochets ?

Je ne comprend pas bien en quoi au final cela diffère...

[Sire Pom-pom]

La portée des variables déclarées dans un bloque est limitée au bloque. Le DelayCommand étant hors des crochets il n'est pas dans la portée de ces variables et donc elles ne seront pas copiées. Enfin j'espère:
normalement, pour

Code PHP:

{ 
      int  i;
}
i=0; 

Le compilateur doit dire erreur dans la déclaration de variable ("variable declared without type").

['Az]

Ben j'ignorais completement ca

Alors la o_o on en apprend vraiment tout les jours...

Bien merci pour cet éclairssissement, c'est vraiment bon à savoir

[Hidwulf]

Je ne trouve pas cela satisfaisant du tout moi. Certes cette pseudo-parade permet de palier à une utilisation des hearbeats qui exécutent du code toutes les 6s mais coté jouabilité ...

Dans le cas ou le respawn des monstres se fait via des hearbeats ...

Cela revient à dire que le pj se fait tout les monstres de la zone et doit se faire des aller et retour de cette zone vers une autre pour pouvoir espérer revoir un jour ses monstres chéris?
Non ce n'est guère apréciable qu'en dîtes vous? Et le fait des faire respawn les monstres via un delaycommand est encore des plus néfaste pour un server presistant car nwn ou ses objets ont une capacité maximale de stockage pour les delaycommand.
Moi je me vois mal avec mes 300 zones et mes pjs se frittants masse monstres mettre des delay ...

A noté qu'au début je le faisais et ... bof bof. Donc ne pas utiliser les hearbeat ... d'accord je veux bien mais dans ce cas faire en sorte que cela ne repose pas sur un pj ... Pourquoi pas n'allouer une sorte de pnjs invisible et invincible qui s'occupe de faire çà? Genre ce pnj pourrait passerait d'une zone à une autre en marchant et c'est lui qui déclencherai les heartbeat.

[eMRaistlin]

Euh...


A priori, c'est pour emuler des OnHeartBeat generic, pas forcement des respawn...


Personnelement, les respawns, je les gere sur le OnDeath des creatures... et je pense pas etre le seul

['Az]

Euh.... je crois rêver ????

Est ce que j'ai seulement insinué qu'il faut remplacer TOUT les onheartbeat du module par ce shéma ?

J'espère bien que celui qui va programmer un respawn de monde persistant ne va pas s'en aller utiliser un truc substitutif et absolument pas adapté pour ce genre de situation.

Entre le respawn des créatures et des evenements régulier appliqués a des zones en particulier, il y a une grande différence...

Ce système est très pratique (bien que je ne l'utiliserais moi même pas sous cette forme la) pour faire des animation dans une zone, qui sont totalement inutiles si aucun joueur n'est dans la zone, comme par exemple des dialoges entre des pnj par des "SpeakString"

De plus, ce n'est pas la seule méthode, mais celle ci a l'avantage d'être utilisable par un simple copier/coller. Après, puisque tu semble si sur de tes compétences, libre à toi d'utliser n'importe quel système.


Pour finir, je dirais qu'il ne me viendrais plus à l'idée en se moment de proposer de tels scripts, mais étant donné que celui ci éétait en première place dans les scripts proposés dans le post persistant, je me suis dis qu'il serait au moins bon que je propose quelque chose qui marche.

[Hidwulf]

Je n'ai jamais dis le contraire bien entendu voyons. Mais tu avoueras tout de même que ce n'etait pas explicite tout de même.

Et oui ce système peut être pratique mais certainement pas dans l'utilisation de tous les heartbeat comme il a été mentionné au debut de cette rubrique, c'est contre çà que je dis "pas terrible".

Et puis tu dis :

Citation :

puisque tu semble si sur de tes compétences, libre à toi d'utliser n'importe quel système.

- Bon certes je possède des compétences en la manière de par mes études qui d'ailleurs sont loin d'être finies. Mais je me base bien plus sur les constats effectués aux fils des mois d'existance de mon serveur. Le simple fait de passer d'un système de respawn dit classique avec des delaycommand à un système de respawn statique permet déjà de gagner pas mal de mémoire.
Car même si l'on voit le mnémonic "delaycommand", pour ceux qui ont pu voir les quelques morceux des sources de nwn ... delaycommand n'est ni plus ni moin qu'un hearbeat géré directement par le module lui-même, tout comme les encounters.
- Mais mais mais, tout dépend aussi de la taille du monde, des zones, et surtout a n'en point douter du nombre de pnj/monstre dans la zone. Car dans certain cas le delaycommand est bien plus pratique, genre moins de 150 zones de respawn.

Je dis çà car coté lag j'ai tout tenté pour alléger au maximun les codes qui s'excécutent. Maintenant si vous voulez tester de part vous-même passer d'un respawn de type delaycommand à un respawn via heartbeat je suis convainqu que vous y verrai un changement notable, si toute fois votre module fait beaucoup de calcul. Parce que le miens en fait en permance du à de nombreux scripts bah c'est comme çà on m'appèle pas le scripteur fou pour rien mdr.

Ceci dis je ne critique pas hein? Je donne juste un conseil afin d'aider les autres car moi on ne m'a pas aider de ce coté là j'ai du apprendre sur le tas. A vous de prendre en considération ma remarque ou pas, après c'est selon le bon vouloir de chacun.

[Iridian]

Citation :

Provient du message de Hidwulf
Le simple fait de passer d'un système de respawn dit classique avec des delaycommand à un système de respawn statique permet déjà de gagner pas mal de mémoire.

*intéressé* et qu'appel tu un "système de respawn statique" ?
J'utilise personnellement des DelayCommand et ca fonctionne très bien, mais s'il est possible d'obtenir les mêmes résultats avec moins de calculs, c'est toujours intéressant ...

[Hidwulf]

Bah lol, déjà le delaycommand n'étant pas une action tu fait faire le spawn du monstre par qui par quoi?

['Az]

Citation :

Car même si l'on voit le mnémonic "delaycommand", pour ceux qui ont pu voir les quelques morceux des sources de nwn ...

Et bien je ne fais pas parti de ces rares élus, mais de toutes facon je me doute bien qu'un DelayCommand fonctionne au départ comme un OnHeartBeat, c'est de toutes facon des fonction appellées en fonction du temp, et je n'ai jamais dit qu'un "DelayCommand(6.0f" soit plus rapide qu'un OnHeartBeat.

Simplement, ce script n'est effectué qu'a la condition que des joueurs se trouvent dans la zone, d'où l'interet, DANS CERTAINS CAS, par rapport à un OnHeartBeat qui est appelé toutes les 6s qu'il y ai des joueurs présents dans la zone ou non.

[Jedaï]

Citation :

Bah lol, déjà le delaycommand n'étant pas une action tu fait faire le spawn du monstre par qui par quoi?

Je trouve que cette phrase est étrange de la part de quelqu'un qui se prétend un scripteur fou...
La catégorie "action" dont Bioware nous a gratifié est une généreuse approximation puisque toute fonction qui ne renvoie pas de valeur renvoie visiblement en NWScript un pointeur sur elle-même, seul moyen de passer une fonction en paramètre en C (en C++ en fait).
Or DelayCommand() est une fonction qui renvoie "void", elle est donc tout à fait utilisable en tant qu'action, ce qui fait qu'on peut faire effectuer le Respawn par le module via AssignCommand().
Ignorais-tu cela, toi qui prétend avoir utilisé un système à base de DelayCommand() auparavant (sinon comment as-tu fait tes tests) ?

Par ailleurs tu parle de respawn sur 150 zones, or que je sache tu n'as pas 150 joueurs sur ton module ? Donc respawner sur 150 zones est inutile, tu ferais peut-être bien de considérer les avantages du DelayCommand() sur ce plan.

PS : Par ailleurs, le code source de NWN n'est accessible qu'aux développeurs de Bioware, si tu as des lumières à nous donner sur la façon dont Bioware a programmé son gestionnaire d'évènement, tu peux y aller, ça nous intéresserait énormément. Nous expliquer que le DelayCommand() fonctionne de la même façon que le OnHeartBeat n'est pas significatif si tu ne nous dit pas comment ce dernier fonctionne.

[Hidwulf]

Oula tu n'as pas bien compris justement : AssignCommand()
On est obligé de passer par là c'est bien là le hic... Car dans la mesure du possible il faudrait que l'objet auquel tu assignes la commande n'est pas "trop" d'action a faire dans le temps sinon ...

Je ne parlais pas d'action de personnage mais d'action réelle telle qu'un appel à une fonction. Car de ce fait tu fais un assign command qui va empiler ses action sur le respawnmaster (objet a qui tu alloues tes action de respawn).
De plus, plus tu alloueras d'action a un obje quelqu'il soit plus il aura du mal, car il devrai decompter pour chaque evènement si oui ou non il peut le dépiler. Car là dessus le système est mal concu car il est des plus probable que le assigncommand va fontionner telle une pile et faire du FILO, premier entre, dernier sorti. Et une pile est une pile et comme la gestion des mallocs ne peut être accessible il est fort probable qu'il existe une sorte de tampon qui soit géré par le mod en attendant de pouvoir les transmettre à l'objet qui n'a plus de "place dans la liste de ses actions".

tu veux mon ancien script de respawn avec des delaycommand? soit ... 2s j'ouvre le mod j'en ai pour 5-10 minutes

[Hidwulf]

Code PHP:

void StaticSpawn(string szClass, location lWhere, string info);

void main()
{

    XP_RewardXPForKill(); /* gestion xp et fp */ 
    
    object oSpawnMaster;
    
    string szMonsterTag = GetTag(OBJECT_SELF);
    int nLength = 0;
    string szSpawnPointTag = "";
    string szSpawnPointInfo;
    string szMonsterClass;
    object oSpawnPoint;
    float fSpawnTime;
    location lSpawnPoint;
    
    if( GetSubString(szMonsterTag, 0, 3) == "ms_" ) {
    nLength = GetStringLength(szMonsterTag);
    
    szSpawnPointTag = GetSubString(szMonsterTag, 3, (nLength - 3));
    } else {
    
    szSpawnPointTag = GetLocalString(OBJECT_SELF, "ms_info");
    }
    
    if(szSpawnPointTag != "") {
    
    oSpawnPoint = GetWaypointByTag(szSpawnPointTag);
    szSpawnPointInfo = GetName(oSpawnPoint);
    
    nLength = GetStringLength(szSpawnPointInfo);
    
    fSpawnTime = StringToFloat( GetSubString(szSpawnPointInfo, 0, 3) + ".0" );
    
    szMonsterClass = GetSubString(szSpawnPointInfo, 4, (nLength - 4));
    
    lSpawnPoint = GetLocation(oSpawnPoint);
    
    oSpawnMaster = GetObjectByTag("spawnmaster");
    
    AssignCommand(
    oSpawnMaster,
    DelayCommand(fSpawnTime, StaticSpawn(szMonsterClass, lSpawnPoint, szSpawnPointTag))
    );
    }
}

void StaticSpawn(string szClass, location lWhere, string info) {
object oNewMonster = CreateObject(OBJECT_TYPE_CREATURE, szClass, lWhere);
SetLocalString(oNewMonster, "ms_info", info);
} 

Bon désolé pour l'indentation mais j'ai pas retrouve une bonne version ca fait un bail que je ne l'utilise plus ...

[Jedaï]

Hummm, avec un tel script c'est sûr que ça risque de bloquer pas mal : relis les post sur la copie des variables au-dessus.

Par ailleurs c'est étrange que tu dises que les Actions seraient posés dans une structure FILO, ne serait-il pas plus logique que la structure soit de type FIFO ?

Autre chose, il me semble que ton script pourrait, même en dehors du DelayCommand() être optimisé, exemple le stockage du SpawnPoint par une local string au lieu d'un local object : un pointeur prend moins de place qu'une string en mémoire. D'autant plus que GetObjectByTag() est une fonction lourde.

Mais effectivement, tout dépend de ses besoins en Respawn, j'imagine que s'ils sont vraiment massifs, le recours à un OnHeartBeat est moins coûteux.
En effet, tu emploies ici un seul "respawnmaster" pour tout ton module, il est fort probable qu'il soit vite saturé, surtout si tu gères un module où les combats sont nombreux. Tu pourrais, par exemple utiliser GetArea() à la place.
Ce genre de chose peut rendre le script beaucoup plus efficient au final, non ?

[Hidwulf]

Alors ouep je me suis trompe c'est bien du FIFO ...
Ce qui induit que cela bloque les respawn suivant dans la file si le précédent n'est pas fini. Donc en plus si ils n'ont pas la même durée de spawn ..

Et non le fait est que le spawnmaster est unique par zone ou groupe de zone car dans une autre version que je n'ai plus ce n'est pas getobjectbytag mais nearest ce qui allège grandement les scripts.

Le fait d'allouer plustot une chaine des caractère qu'un objet de type waypoint si j'ai bien compris est tout de même assez ennuyeux car coutant en mémoire. Certes l'accès sera des plus rapide mais ademettons une centaine de monstres, 100 pointeurs dessus et je ne suis pas certain que cela soit mieux. Ne pas oublié qu'une chaine de caractère est ni plus ni moins qu'un pointeur de type char qui pointe que le premire caractère de la chaine. Donc coté alouement çà va, c'étais çà ma priorité première ... maintenant alouer directement l'objet bah pourquoi pas.

Citation :

Mais effectivement, tout dépend de ses besoins en Respawn, j'imagine que s'ils sont vraiment massifs, le recours à un OnHeartBeat est moins coûteux.

Ben en comptant les 350 zones oui le delay à du mal chez moi ...
Et puis je ne peux pas dire de faire getarea(), mon area comme tu dis travaille déjà. Car elle travaille via une sorte de garbage collector qui supprime les drops et objets posés.

D'ou l'idée m'est venu de passer aussi par des heartbeat, car le fait est que je parcour la zone, si c'est un item ou un placable de type sac de drop je les traite, si c'est un objet de type waypoint alors je regarde si c'est un waypoint de type respawn alors traitementq.

Donc je me suis dis à raison je pense que cela est bien moins dommageable non? Autant faire d'une pierre deux coups, qu'en dis-tu?

[Sire Pom-pom]

Avertissement: tout ce qui suit n'est que mon opinion qui vaut ce qu'elle vaut, même quand j'ai l'air sûr de mon fait .

Je ne crois pas que cela aie grand chose à voir avec une différence de performance entre un DelayCommand et l'utilisation du heartbeat. Tes deux "versions" n'ont pas du tout le même design d'après ce que je comprends, donc tu ne peut pas les comparer. Dans un cas, celui que tu utilises maintenant, si j'ai bien compris, tu signales la mort de chaque créature à ton Spawnmaster par un moyen ou par un autre (UdE ou simplement un SetLocal), et par le biais d'un seul Onheartbeat tu respawn les créatures. Dans l'autre cas le respawn des créatures est directement lié à leur onDeath je suppose. Ces deux design n'ont au fond rien à voir avec OnHeartbeat et Delaycommand, tu pourrais te passer totalement de l'OnHeartbeat dans le premier, en recréant les créatures quand un PJ entre dans la zône par exemple, et dans le deuxième cas tu pourrais te passer totalement du DelayCommand, en recréant les créatures immédiatement, ça n'est juste pas là même manière de faire.

Pour l'option 1, parcourir tous les objets d'une zone en Heartbeat, comme tu as l'air de le suggérer (mais je pense que je n'ai pas bien compris) me semble une très mauvaise idée.

Citation :

D'ou l'idée m'est venu de passer aussi par des heartbeat, car le fait est que je parcour la zone, si c'est un item ou un placable de type sac de drop je les traite, si c'est un objet de type waypoint alors je regarde si c'est un waypoint de type respawn alors traitementq.

L'information que tu passe à la matrice lors du OnDeath (en fait quelle créature est morte tout simplement, et ce sous une forme ou une autre, par exemple un entier, en créant un pseudo tableau sur la matrice) doit te permettre de faire les respawns par elle même. Et encore une fois cela n'a rien à voir avec le OnHeartBeat, tu pourrais accrocher le script de respawn à n'importe quel événement.

Pour ce qui est de l'option 2, et de ton script en particulier,
Ton DelayCommand n'était pas du tout optimisé, comme le remarquait Jedaï, toutes ces variables sont copiées en mémoires:
oSpawnMaster; szMonsterTag; nLength; szSpawnPointTag; szSpawnPointInfo; szMonsterClass; oSpawnPoint; fSpawnTime; lSpawnPoint;

Quand tu fais un SetLocalString tu crées une copie de la chaîne en mémoire, puis tu récupères un pointeur: si ton pointeur pointait n'importe où, ça te ferais une belle jambe de le récupérer. Je doute que SetLocalObject crée une copie de l'objet...

Par ailleurs si je peux me permettre quelques remarques d'ordre général, tout l'intérêt d'avoir une matrice comme le RespawnMaster que tu as créé est de minimiser la nécessité d'échanger, et d'aller pêcher (GetObjectByTag) des informations, tout ce qui est lieu de respawn, laps de temps avant le respawn, ResRef de la créature devrait être dans les scripts de la matrice et pas dans ceux de la créature... Et tu ne devrais avoir recours qu'à des OBJECT_SELF, ou des GetLocal...(OBJECT_SELF,...) pour récupérer les informations. Pour récupérer la matrice sur chaque créature, si tout ce qu'elle fait ce sont les respawns, tu ne peux pas vraiment optimiser, car il faudra de toute façon que tu ailles la chercher une fois par un GetObjectByTag(...). Mais quite à ce qu'elle les respawns elle devrait aussi les créer la première fois, auquel cas un simple:

Code PHP:

       object oCreature = CreateObject....
       SetLocalObject(oCreature,"Mat", OBJECT_SELF); 

Te permets d'avoir une référence directe à la matrice sur les créatures, c'est pas avec un SetLocalObject par créature que tu vas réussir à remplir ta mémoire... ce qui est important c'est le gain CPU je pense.

ensuite tu fais par exemple un

Code PHP:

SignalEvent(GetLocalObject(OBJECT_SELF,"Mat"), EventUserDefined(nLeCodePourLaMortDeTaCréature)); 

Et tous le reste, y compris le DelayCommand, si c'est comme ça que tu veux faire, est dans l'UDE de la matrice, en toute lettre pour ce qui est des ResRef et autre truc du genre.

Pour le

Citation :

Ce qui induit que cela bloque les respawn suivant dans la file si le précédent n'est pas fini. Donc en plus si ils n'ont pas la même durée de spawn ..

Comprend pas, de toutes façon un seul script est exécuté à la fois, ça n'a rien de spécifique au DelayCommand, ça ne bloque rien comme le prouve le fait que nwscript fonctionne, et je ne comprend pas ce que tu veux dire par "durée de spawn";

[Hidwulf]

Pas vraiment ... je m'expliquer car je l'ai mal fait.

J'ai du utiliser les demaycommands pas longtemps du tout. Pourquoi? Car mes éboueur de zones parcourent les objet dans la zones, et il passent forcément par un mes waypoints de respawn (qui oui au passage sont bien en pointeur de nom en stockage de chaine de caractère sinon il est vrai que le proc aurrait bien du mal). Et donc pourquoi ne pas faires les traitement de respawn sur le waypoint de respawn une fois tombé dessus?

Car en effet les eboueurs d'area sont execute suivant des hearbeat, là je ne sais pas si vous avez qqch de mieux je suis prenneur sinon, et ainsi je couple le traitement des suppressions des drops au respawn. Maintenant à savoir si cela est plus pratique que de mettre des flags ...

Pour ma durée de respawn, en fait la durée de respawn d'un montre varie en fonction du monstre lui-même forcément mais aussi de son lieu. Par exemple, plus on s'enfonce dans une crypte, plus le respawn est rapide et donc la difficulte de même. Et le fait qu'il faudrait alors mettre dans la palette plusieurs copies des monstres dont la durée de spawn varie? Bah çà ne me tente pas trop vu déjà que les métiers tels que forgeron, bijoutier prennent énormément d'objet dans la plalette (enorme c'est énorme ...)

Donc je ne sais pas mais je n'ai pas d'autre moyen que de lier çà a un waypoint, qui contient les infos adéquoites et donc variables selon les cas.

Je posterai un de ces quatre le respawn que j'utilise pour "recevoir" vos amélioration, moi je suis toute ouie )

[Hidwulf]

Le script via delay n'etait pas le mien mais celui de nwnvault datant de septembre, voilà celui que j'ai fait en fonction de mes besoins :

Code PHP:

//::///////////////////////////////////////////////
//:: Spawn-Heartbeat-ResRef
//:: hidwulf_spawn
//:: Copyright (c)
//:://////////////////////////////////////////////
/*
    Ce script vous permet de faire respawner une creature
    selon le temps, un resref et un waypoint.
    MAGIQUE!!!

    le waypoint a placer
    => nom: XXXX_resref, ou XXXX est la duree de
    temps de respawn de la creature sur 4 chiffres
    unite le heartbeat = 6 secondes. Ainsi il y'a un
    décompte de hearbeat en somme.
    => tag: ms_xxx, le tag doit commencer par ms, le
    on s'en fout c'est pour vous ou la comprehension
    => Avec ce système plus besoin de "poser" les
    monstres dans la zone, cela se fera automatiquement.
    Gain de place considérable. On est passe chez
    moi d'une reduction de 10Mo du mod. Mais forcément
    au chargement du module, l'usage du cpu est assez
    important pendant les 2 premières minutes, apres
    c'est du tout bon : 
        usage cpu a vide (de joueur) : 30%-52%
    A noter que si je remplace a peu près le tout par des
    delaycommand je fais du 32-55%, mais avec des spikes
    (des pics et descentes) qui atteignent les 75% a
    intervals constants ...    

    Voila bon spawn!!!
*/

//::///////////////////////////////////////////////
//:: SignalerMort_oWay
//:://////////////////////////////////////////////
/*
    A mettre dans l'evenement OnDeath du monstre
    dans la palette
*/
//:://////////////////////////////////////////////
//:: Created By: Hidwulf
//:: Created On: 15/10/2002
//:://////////////////////////////////////////////
void SignalerMort_oWay( object oMonstre)
{
    object oWay = GetLocalObject(oMonstre,"oWay");
    if ( GetIsObjectValid(oWay) )
    {
        SetLocalInt(oWay,"Vie",0);
    }
}

//::///////////////////////////////////////////////
//:: Spawner_oWay
//:://////////////////////////////////////////////
/*
    Permet de faires spawner les monstres de
    facon dynamique.
    Version ici qui va parcourir les waypoints
    de la zone et que ceux-ci.
*/
//:://////////////////////////////////////////////
//:: Created By: Hidwulf
//:: Created On: 15/10/2002
//:://////////////////////////////////////////////
void  Spawner_oWay ( object oArea )
{
    location baseloc = Location(oArea,Vector(),0.0);
    int counter=1;
    object oWay = GetNearestObjectToLocation(OBJECT_TYPE_WAYPOINT,baseloc,counter);
    while ( oWay != OBJECT_INVALID )
    {
        if ( GetSubString(GetTag(oWay),0,3) == "ms_" )  /* waypoint de spawn */
        {
            if ( GetLocalInt(oWay,"Vie") == 0 ) /* Si monstre rattache mort */
            {
                string nom = GetName(oWay);
                int temps = GetLocalInt(oWay,"Dcpt")-1;
                if ( temps <= 0 ) /* Si le decompteur est a 0 */
                {
                    /* Realloue le temps de respawn */
                    SetLocalInt(oWay,"Dcpt",StringToInt(GetSubString(nom,0,4)));
                    int taille = GetStringLength(nom) - 5;
                    object oCreature = CreateObject(OBJECT_TYPE_CREATURE,GetSubString(nom,5,taille),GetLocation(oWay));
                    SetLocalObject(oCreature,"oWay",oWay);
                    //SetLocalString(oCreature,"oWay",GetTag(oWay));
                    /* Indique que le monstre est vivant */
                    SetLocalInt(oWay,"Vie",1);
                }
                else // Il n'est pas encore le temps de respawn pour le monstre
                {
                    SetLocalInt(oWay,"Dcpt",temps);
                }
            }
        }
        counter++;
        oWay = GetNearestObjectToLocation(OBJECT_TYPE_WAYPOINT,baseloc,counter);
    }
} 

La par contre si vous avez des remarques à faire je veux bien car je suis près à faire toute modifications me permettant de soulager le cpu du serveur et dieu sait qu'il en a besoin le bougre.
Je préfère de loin que vous critiquez quelque chose que j'ai fait moi-même et que j'utilise

Merci de me dire si il y a mieux ou si il est possible de pouvoir optimiser certaines choses.

[ruru2a]

Ce systeme a l'air interressant, car j'utilise par exemple dans les tavernes des pnj ki font des actions au hazard, histoire de mettre un pe d'embiance.

Donc ma kestion est :

Si j'utilise c scripts sont il sensés couper les OHB de mes pnj de chake tavernes (ya d'autres pnj aussi mais on s'en fiche pour l'exemple), a partir du moment ou les joueurs ne sont plus dans la zone, ou bien faut il modifier les scripts (Azrael) pour que ceux-ci marchent avec mon module ???

en bref le script d'azrael est il un script generik ki fonctionne avec chake module ou fo t'il faire une modif pour les OHB ?

[Jaha Effect]

On a une taverne fabuleuse sur le forum, avec de l'ambiance a plus savoir quoi en faire que même les ricains du vault nous envie?
Et toi tu te demande comment mettre un peu d'ambiance...
Y'a des fois je me demande pourquoi on se fait *****.

Jaha Effect