Un delaycommand placé devant un executescript ou devant le nom d'une fonction (permettant de lancer celle-ci passé le delay) tournant sur une longue periode (24h IG, 72h IG voir plus) consomme t'il des ressources de la machine ou peut t'il provoquer des lags sur le réseau malgrès le fait que la fonction ou le script concerné est de cette manière placé en attente?
Si oui, est-ce négligable ou important?

Un seul DelayCommand n'est pas de nature, quelle que soit la durée de son compteur, à affecter les performances. La tâche régulière d'un tel compteur est juste de "décompter" le temps qui reste, le fait qu'il doivent le faire plus longtemps ne rend pas cette tâche plus difficile. Les impacts sont donc négligeables (et même inexistants).
J'attire juste ton attention sur le fait que tu n'auras aucun contrôle sur un tel système, et que si, pour une raison X, le DelayCommand n'exécute pas la fonction comme c'est prévu, ton système de comptage récurrent se casse la figure. Car il convient de savoir qu'un DelayCommand n'est pas fiable à 100% et qu'il arrive que son exécution se "perde" à un moment où la charge de la machine est importante. Lancer un DelayCommand sur 1 heure ou plus me paraissant déjà risqué, le faire sur une période de 24h IG est assez téméraire.
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

Existe t'il une autre solution qu'un delaycommand pour un tel lap de temps?

Une boucle à l'interieur de laquelle l'heure actuelle par rapport à l'heure d'arrivé du personnage dans le module serait constament évalué(la 1ere fois que le personnage arrive dans le module ensuite le temps déjà écoulé serait mémorisé avant une déco) serait plus judicieux? Dans ce cas le script ou la fonction serait activée des que la différance entre l'heure actuelle et l'heure de départ serait égale a 1heure ou plus suivant le cas.

A vrai dire, il existe plusieurs solutions pour réaliser ce que tu demandes, sans pour autant utiliser le DelayCommand. En voici une possible :

Il y a un évènement dont on soit sûr de l'exécution en toute circonstance et régulièrement : OnHeartBeat sur le module. Il s'exécute toutes les 6 secondes. Tu peux donc décider de compter les rounds qui s'écoulent dans l'absolu. Pour cela, une simple variable entière stockée sur le module et incrémentée toutes les 6 secondes comme ci-dessous n'est pas quelque chose de très couteux en ressource (ça sera même transparent) :


Le calendrier d'un module est aussi un bon moyen de compter le temps qui s'écoule, mais le nombre de variables impliquées dans le calcul est nettement plus important (année, mois, jour, heure, minute, seconde) et effectuer des opérations pour comparer ces valeurs va être couteux. Alors que maintenir un compteur de round est d'une facilité exemplaire. Toutefois, il faudra tôt ou tard que ce compteur déclenche quelque. Si tu souhaites avoir une certaine régularité, tu peux décréter qu'au bout d'un certain nombre de round écoulé, le compteur soit remis à zéro et qu'un évènement soit déclenché. Voici donc un nouveau code à placer sur le OnHeartBeat du module :


Cette modification permet de remettre le compteur à 0 quand 600 rounds ce sont écoulés, et exécute le script que tu souhaites.
A noter que cette solution est persistante si on utilise le système de sauvegarde standard de NWN (puisque la variable TOTAL_ROUND sera incluse dans la sauvegarde). Au démarrage du module TOTAL_ROUND=0 de manière implicite puisque la variable n'existe pas.

Ceci ne répond pas totalement à ce que tu souhaites, car tu as ajouté le fait que ce qui t'intéresse est que quelque chose se passe sur le PJ en fonction du moment où il entre et où il sort. C'est déjà plus délicat.
Si tu n'as qu'un PJ dans un module solo, cette solution est applicable, car le temps d'ouverture du module correspond au temps de présence du personnage. Donc la variable représente le nombre de round écoulé depuis que le personnage a démarré le module. Pour un groupe de PJ (ou un serveur persistant) ça ne marche plus. Chaque joueur devrait avoir son propre compteur et il pourrait s'avérer couteux de mettre à jour le compteur de tous les joueurs toutes les 6 secondes. Mais si tu ne souhaites pas le faire toutes les heures, rien ne t'empêche de le faire plus souvent, toutes les minutes par exemple. Dans ce cas, chaque PJ possède un compteur personnel de temps écoulé qui sera mis à jour par un script. Tu peux garder la même base de travail, changer la valeur de la constante NB_ROUND (par exemple 10 pour faire une minute) et le script qui sera lancé toutes les minutes par ce biais sera celui qui te permettra de mettre à jour le compteur de tes personnage-joueurs (et éventuellement leur statut dans la foulée).
Cette méthode implique, pour gérer la persistance, de sauver les variables compteurs des personnages soit dans la base de donnée (mais il vaut mieux le faire avec une variable locale et ne lire ou sauvegarder dans le base de donnée que lorsque le personnage se connecte ou se déconnecte), ou bien sur le module (avec un nom de variable propre au PJ pour la reconnaître plus tard) si on utilise la sauvegarde standard du module.

Je te laisse creuser la question
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

Hey bien je te remercie beaucoup pour ta superbe réponse et je vais creuser ca

et de cette manière ca ne sera pas trop lourd? sachant que dans le OnHeartBeat il y a de grande chances que je lance des scripts différents en fonction d'une autre valeur de round disont par exemple 3 jours pour la faim 1jours pour la soif et si je rajoute encore un ou deux scripts que j'ai pas en tête pour le moment en fonction d'un nombre de round encore différent ?

Dans le OnEnter:
Code :


Dans le OnHeartBeat (j'ai mis 10 pour le test mais j'ai bien l'intention de mettre beaucoup plus):

Code :


Pour le test:
Code :



je ne suis pas sur d'avoir été assez clair lol enfin vous me le direz si vous avez pas compris

arf non il y a un hic en multi joueur le systeme s'applique uniquement pour le dernier connecté enfin j'ai essayé que pour deux personnes. Mais si je place un GetFirstPC(); et getnextpc etc... j'ai peur que ca alourdisse de beaucoup mon script surtout placé dans un onheartbeat comme tu me l'a si bien expliqué lendraste d'ailleur..... bref c pas cool ca

J'allais le dire.
Cela dit, tu n'as pas trop le choix. A un moment ou à un autre, ce qui n'est pas géré par des évènements spécifique doit être déclenché de cette façon. Dis-toi qu'un seul script, même s'il doit boucler sur 20, 30 ou même 90 joueurs n'est pas très long à exécuter si l'on se débrouille pour que le nombre d'opération par joueur soit très limité. Et puis il y a d'autres astuces :
Tu peux te débrouiller pour n'avoir à traiter qu'une partie des joueurs à chaque "tic" de ton horloge et non la totalité. En les répartissant dans le temps, en nombre limité, tu réduit la charge instantannée de ta machine au moment de boucler sur les PJs, n'en traitant qu'un petit nombre plus régulièrement plutôt qu'un grand nombre peu souvent (ce qui a plus de chance d'impacter le serveur). Mais là encore, cela dépend grandement du nombre de PJs. Je maintiens que boucler sur 90 joueurs pour n'incrémenter qu'une variable et faire un test (et donc enchaîner éventuellement la gestion de la fatigue correspondant à son compteur) n'est pas de taille à réduire les performances.
D'autant que tu n'as pas posé la véritable "question à problème" dans cette affaire
Si les PJs peuvent se fatiguer, les PNJs de ton module le peuvent-ils aussi ?
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

aie oui tu as raison bon, il ne faut mieux pas car la bonjour les dégats alors non les pnjs ne peuvent pas etre fatigués ou sous l'effet d'un de ces scripts mais le contraire aurait été plutot sympas. Euh mais j'ai une autre question aussi dans Baldur's Gate les pnjs étaient soumis a la fatigue ou pas?
Bon sinon je dis de suite je ne prévoie pas mon module pour 90joueurs ca non, depuis le départ j'ai décidé de ne pas péter plus loin que le jeu lui meme étant donné que ce module sera énormément géré par les scripts, je voudrais plutot faire quelque chose destiné a un, deux ou trois MD pour 3 à 10 joueurs formant un groupe ou deux groupes opposés ou pas.
Cela me permettera de me sentir plus à l'aise sur la personalisation du jeu et d'ajouter un plus grand nombre de script que pour un module persistant et puis j'ai horreur des lags qui pour ce jeu sont fréquent et meme obligatoire pour un mod de ce genre.
De plus ce module sera avant tout une plateforme sur laquelle n'importe quel MD pourra faire vivre son aventure le groupe de joueur sera donc un groupe ayant probablement décidé de jouer ensemble avant la partie, a mon avis le jeu a dabord été concue comme tel donc je m'en tien à ca afin de bénéficier au maximum du merveilleux outil qu'est l'éditeur de script.

Avec ca en tête pour le reste je développe le mod comme un mod persistant et les questions ressources m'importe tout de même plus que beaucoup lol.

Bon treve de bétises j'ai un but, voici ce a quoi je pense pour le moment:



Evènement liés au module

OnEnter:
-Une variable représentant le nombre de minutes perdues est déterminé (par exemple pour 15h50, le nombre de minutes sera 50) puis incrémenté à la valeure "dMinute" (oPC) stoké dans la database.
-Cette variable ("dMinute" (oPC)) est ramené à une valeure relative soit "dMinute" (oPC)/60=x
-Le nombre x décrémente de sa valeure les variables locales "lFatigue" (oPC), "lFaim" (oPC) et "lSoif" (oPC).

OnPlayerRespawn:
-Une variable représentant le nombre de minutes perdues est déterminé (par exemple pour 17h25, le nombre de minutes sera 25) cette variable décrémente ensuite de sa valeure les variables locales "lFatigue" (oPC), "lFaim" (oPC) et "lSoif" (oPC).

OnHeartBeat:
-Toutes les heures IG un script nommé ido_compteur se lance.

OnPlayerRest:
-La variable "lFatigue" (oPC) est décrémenté d'un certain nombre (la valeure de ce nombre sera determiné apres de nombreux test afin que cela reste juste).

ido_compteur:
1ère partie du script:
-Ce script incrémente de 1 la variable locale "lFatigue" (oPC) de chaque créature (joueur ou pas) présent sur le module et ce à la condition que la créature en question ne soit pas immunisée aux effets de la fatigue.
-De la même manière ce script incrémente de 1 la variable locale "lFaim" (oPC) de chaque créature (joueur ou pas) présent sur le module et non imunisée au effets de la faim.
-Toujours de la même manière ce script incrémente de 1 la variable locale "lSoif" (oPC) de chaque créature (joueur ou pas) présent sur le module et non imunisée au effets de la soif.
2ème partie du script:
-Ce script vérifie les valeurs "lFatigue" (oPC), "lFaim" (oPC), "lSoif" (oPC) si l'une de ces valeures est supérieure à un nombre prédéterminé et pouvant etre différent pour chaque cas (la faim, la soif, la fatigue) alors un script spécifique à chacune de ces situations est lancé sur la créature en question.




Evènement liés aux créatures

OnSpawn:
-Une variable représentant le nombre de minutes perdues est déterminé (par exemple pour 15h50, le nombre de minutes sera 50) puis incrémenté à la valeure "dMinute" (oPC) stoké dans la database.
-Cette variable ("dMinute" (oPC)) est ramené à une valeure relative soit "dMinute" (oPC)/60=x
-Le nombre x décrémente de sa valeure les variables locales "lFatigue" (oPC), "lFaim" (oPC) et "lSoif" (oPC).

OnDeath:
-Les variables "lFatigue" (oPC), "lFaim" (oPC) et "lSoif" (oPC) sont effacées.

OnRested:
-La variable "lFatigue" (oPC) est décrémenté d'un certain nombre (la valeure de ce nombre sera determinée apres de nombreux tests afin que cela reste juste).




Autre
Ce qui suit est déclanché soit par le joueur lui même grace à une boite de dialogue soit par une créature quelconque grace au npcactivities. Bien sur les circonstances dans lesquels la créature aura la possibilité de déclancher ces scripts ne sont pas encore déterminées.

Le script de dodo:
explication: Ce n'est pas un script de repos, le repos est un repos, il permet permet de faire de nombreuse chose comme s'occuper des soins de l'entretien des armes j'en passe et des meilleurs ( ce n'est pas le sujet) le dodo est un arret total de toute activitées.
-Ce script permet de ramener la variable locale "lFatigue" à 0

Le script de restauration naturelle:
explication: il pourra être déclanché grace a un menu spécial (boite de dialogue) qui apparait en cliquant sur ce qui est a l'origine l'icone du repos.
-Ce script permet de décrémenter la variable locale "lFaim" (oPC) d'un nombre dépendant de la nourriture consommé par le personnage mais aussi la variable locale "lSoif" (oPC) si la créature ou le personnage dispose d'eau.(La restauration naturelle prend quelque temps si elle est déclanché séparément cependant une proposition apparaitra avant chaque repos, dans un tel cas la restauration naturelle ne prendra pas plus de temps que le repos lui même).

--------------------------------------------------------------------------------------------------------------------------

Il y a de grandes chances pour que les choses ne se passe pas comme je me l'imagine de plus ma solution n'est peut être pas si terrible apres réflexion ou peut être est elle un point de départ pour une autre solution, quoi qu'il en soit vos conseils, vos avis, vos remarques et vos doigts qui se pointes vers les choses qui ne vont pas ou vraiment pas m'interesse beaucoup autant que les ressources de la machines qui peuvent etre consommé ou la surcharge du réseau lors de partie multijoueur via internet.
Enfin ceci n'est qu'une réfléxion et rien de plus pour le moment, un peu d'aide oué ho que oué! c'est ca que je recherche héhé .


Sinon j'ai une dernière question j'aurais bien aimé savoir ce qui peut bien arriver a une variable locale apres un plantage du serveur et dans mon cas comment sauver les variables qui doivent etre sauvées malgres un plantage du serveur ou du client?

Autre solution:

Et si mon script "ido_compteur" était lancé toutes les minutes IG et que ma valeure "dMinute" (oPC) servait a déterminer le décalage d'un delaycommand? Jusqu'a quelle valeure peut on considerer ce delaycommand comme étant fiable (en minute ou seconde réelle)?