14 réponses à ce sujet

[alliop]

Bonsoir.

Tout est dans le titre.

J'ai lu ici ou là qu'il ne fallait pas "en mettre trop", sans jamais avoir une explication technique rationnelle de ce que signifie ce "trop", de sa mesure et de ses conséquences en termes de fonctionnement.

Par ex dans Nova, nous avons créé 42 globales, toutes indispensables (+quelques items ajoutés en douce dans l'inventaire et qui tiennent lieu de globales ponctuelles), et pour quelques projets de la V2 il en manque encore quelques unes.
Tous les bugs qui nous ont étés reportés ont trouvé une explication, soit du côté de nos erreurs soit du côté de celles des joueurs installant mal leurs patchs ou modifiant l'esp, aucun de ces bugs ne semble pour l'instant provenir d'une saturation d'épices dans la soupe.

Si quelque chimiste de la cuisine scriptale pouvait me donner des informations plus précises, je m'en trouverai sans doute un peu moins bête qu'avant.  

***********

° j'en profite pour passer une info (probablement déjà répertoriée mais on ne sait jamais) : méfiez-vous de l''outil "Find Text" :

- Il ne trouve pas les termes au-delà d'environ 80 lignes de script

- il a tendance à s'emméler les pinceaux entre les " L" et les "I".

[Nenfëa]

Hello !

Voilà quelques raisons pour lesquelles il vaut mieux éviter de mettre trop de globales. Celà dit, dans l'ensemble, les inconvénients sont vraiment négligeables par rapport aux avantages, je ne pense pas que tu aies à te modérer outre mesure dans leur utilisation !

Spoiler

1) Pour éviter les incompatibilités si deux mods utilisent une globale du même nom (mais comme Nova Magica utilise une nomenclature spécifiques, les risques sont presques nuls)

2) Pour autant que je sache, toutes les globales sont chargées à tout moment du jeu, ce qui consomme de la mémoire vive en permanence (un peu comme le ferait un script global). Mais vu la quantité de mémoire vive requise par une variable, il n'y a vraiment pas de quoi s'affoler.

3) Par soucis de clarté - on s'y perdra très facilement dans les 50000 globales in-TESC (ou in-game en utilisant la commande console "sv")

4) Sans doute le plus important : l'option "Error check result" des dialogues modifie la valeur de départ des globales (elle l'incrémente de un à chaque fois que le vérificateur de syntaxe trouve une utilisation de la globale ?! ), il faut donc systématiquement se taper la vérification de la valeur de départ pour chaque variable globale après avoir utilisé cette option, ce qui est moins pratique s'il y en a un grand nombre !

Comme je l'ai dit, il n'y a rien de bien majeur dans ces points négatifs, n'hésite pas à les utiliser si tu en as besoin !


Et merci pour l'information sur le FindText, je ne connaissais pas !  

[alliop]

Merci pour ces éclaircissements qui enchantent bien ce début de journée!

L'honnêteté intellectuelle m'oblige à une précision : contrairement à ce que tu penses, les globales de Nova, hélas, sauf certaines concernant les familiers, n'ont pas d'IDs spécifiques (les prochaines commenceront toutes par "NM_", tiens, comme les scripts).

[Angora]

Le coup de "error check result" est de loin le pire, parce qu'il n'est mentionné presque nulle part... En fait, il faut sauver avant de faire error check result, noter tous les problèmes, recharger le mod, les corriger, sauver, vérifier s'il n'en reste plus, recharger le mod, etc. Ne jamais sauver après un ECR!

[alliop]

Et qu'en est-il du "recompile all"? (Je suppose que c'est également bugué, y'a pas de raison!    )

**********

Tant qu'on y est, une autre question concernant les timers.

Si j'ai par exemple 5 scripts utilisant des timers qui tournent en même temps.

° Je suppose que le calcul des "Set timer to ( timer+GetSecondsPassed )" sera effectué 5 fois simultanément.

° N'aurait-on pas intéret, pour des gros mods utilisant beaucoup cette fonction, à créer un timer global permanent en startscript mettant à jour une globale de référence (secondespassées), et à y référer par le biais d'une locale de comparaison?

Par ex :

Begin LeScript

float top
; globale float secondespassées

if ( top != 0 )

	 if ( secondespassées == top )
		  set top to 0
		  messagebox "driiiiiiiinnnnnnng"
	 endif

else

	  set top to secondespassées+(x)

endif
   
end

Dans le cas donc de plusieurs scripts utilisant simultanément cette fonction, est-ce que ce ne serait pas plus léger?

Modifié par alliop, 19 octobre 2006 - 09:31.

[Nenfëa]

Voui, faire tourner un timer unique par script global et accéder à la variable globale du timer depuis des scripts locaux sera plus efficace que de faire tourner 50 timers locaux !

Attention juste à un petit détail :

Spoiler

     if ( secondespassées == top )

          set top to 0

          messagebox "driiiiiiiinnnnnnng"

     endif

Il ne faut jamais mettre d'opérateur "==" pour comparer des floats, cf la toute fin de ce post pour plus de détails !

[alliop]

Ah voilà une info qui vaut une gemme spirituelle supérieure! merci

[Angora]

 alliop, le 19.10.2006 à 10:29, dit :

Et qu'en est-il du "recompile all"? (Je suppose que c'est également bugué, y'a pas de raison!    )ce ne serait pas plus léger?

Effectivement, ça recompile tous les scripts, y compris ceux qui ne sont pas ajoutés ou modifiés... Donc, le mod se charge de tous les scripts du jeu (ce qui augmente un peu sa taille et surtout provoque une source inépuisable de conflits absurdes).

Pour tout ce qui est script, je suggère fortement d'utiliser la dernière version de MWEdit (0.6). Il contient une fonction "compile all active scripts" qui fait exactement ce que "recompile all" devrait faire dans le CS de Bethesda. En plus, l'éditeur de script inclu fait la coloration syntaxique, affiche les messages d'erreurs de compilation de façon pratique (pas une par une avec des dialogboxes) et permet d'aller directement aux lignes fautives. De surcroit, il vérifie la syntaxe de façon plus rigoureuse, permettant d'éviter bien des problèmes que le CS ne détecte pas ; et permet de compiler des scripts utilisant des fonctions supplémentaires comme celles de MWE ou MWSE.

Bref, script = MWEdit.

[Orann]

Ce topic est vraiment très interessant  

Je rajoute juste sur les variables globales ce que je me rappelle d'un topic d'il y a des années: une variable globales est stockée dans la mémoire vive de la même façon qu'une variable locale. Donc la distinction variable globable/locale au niveau de la mémoire est insignifiante (contrairement à la distinction script local/global).  

Bref, depuis que j'ai lu ça, je ne fais plus le radin sur les variables globales, c'est tellement pratique  

[Angora]

Un autre truc à savoir à propos des variables globales : les shorts sont des maillots. Euh, les entiers courts (shorts) sont en fait des chiffres en virgule flottante (float), ce qui peut provoquer des problèmes quand on utilise de grandes valeurs. Ou alors, plus simplement, si vous voulez les afficher dans une messagebox.


Exemple :

;global short GlobVar
short LocVar
float longitude

set longitude to ( Player->GetPos X )
set GlobVar to ( longitude / 8192 )
set LocVar to ( longitude / 8192 )

messagebox "Longitude %f, c'est à dire cellule %g ou %g", longitude, GlobVar, LocVar

Vous aurez une surprise : la première longitude de cellule sera un chiffre à virgule, et non pas un entier. Encore mieux, si pour corriger ça vous essayez %.g (ou %.0g) au lieu de %g, vous aurez droit au chiffre en écriture scientifique, c'est à dire illisible puisque les chiffres après la virgule ne seront pas indiqués (ça, au moins, ça marchera).

Par contre, le deuxième, une variable locale cette fois-ci, est bel et bien un entier; et s'affichera donc de façon arrondie sans poser de problèmes.

[Cogite Stibon]

 Orann, le 19.10.2006 à 18:00, dit :

Je rajoute juste sur les variables globales ce que je me rappelle d'un topic d'il y a des années: une variable globales est stockée dans la mémoire vive de la même façon qu'une variable locale. Donc la distinction variable globable/locale au niveau de la mémoire est insignifiante (contrairement à la distinction script local/global).  

Bonjour,

Juste une petite précision : une variable locale, dans un script attaché à un objet ou à un PNJ, occupe-t-elle toujours la mémoire vive quand on sort de la cellule de cet objet ou un PNJ ?

Merci
Cogite

[chef]

      

Super ! Moi, qui culpabilisais chaque fois que je créais une variable de globale !  

Spoiler

Je me suis même surpris a utiliser un seau présent dans la cell en guise de variable de globale, pour pas encomber la liste, setangle, getangle... Les débuts sont les débuts...

Petite question, le nombre de scripts et de variable de gloable n influence pas sur le poid de la sauvegarde ?


Bonne nuit !

[alliop]

Tant que les longs ne sont pas des futs, tout va bien.  

Oui, tout ça est très instructif.

(Post inutile s'il en est... mais on ne remercie jamais trop... euh.... assez... euh....bon... voilà    ).

EDIT :

(Et l'exigence de donner à ses globales des ID cohérentes et regroupées n'est pas la moindre de ces petites leçons ).

Modifié par alliop, 19 octobre 2006 - 22:14.

[Orann]

 Cogite Stibon, le 19.10.2006 à 21:05, dit :

Juste une petite précision : une variable locale, dans un script attaché à un objet ou à un PNJ, occupe-t-elle toujours la mémoire vive quand on sort de la cellule de cet objet ou un PNJ ?

Le jeu conserve toujours en mémoire la valeur de la variable locale car, si tu re-rentre dans la cell, ton script local se réactive avec la valeur de la variable locale qu'elle avait en sortant...

[alliop]

EDIT : j'avais écrit une grosse bêtise :
"quand un objet est "disable", son script ne "continue" pas de tourner, mais il "recommence" à tourner : ses variables sont réinitialisées à l'instant du "disable" [...] "
C'était une erreur, le script de mon objet de référence remettait une variable à 0 après disable  

Je laisse quand même les rappels qui suivent :
° au lieu de "disable" on peut déplacer l'objet dans une cell "poubelle" ("Au pays des merveilles" par exemple), où il sera conservé dans son état présent, et le rappeler si besoin est (par un script global ou porté par un activator local). (Le plus simple étant évidemment d'utiliser des globales, qui ne seront pas réinitialisées par le "disable").

° Changer de script sur un objet : créer des doubles de l'objet avec des scripts différents, et les remplacer les uns par les autres au fur et à mesure des besoins. Très pratique par exemple sur des compagnons, pour simuler une IA plus complexe et éviter les bugs causés par trop de modifications de kit d'IA sur un même objet, ou/et pour "dépasser" la limite de volume de script acceptée par Morrow. (Ce qui actuellement manque aux familiers de Nova, par ex.... sans parler des compagnons du jeu de base ^^ ).

Modifié par alliop, 20 octobre 2006 - 16:06.