Il y a quelque chose que je ne comprends pas voici mes 2 triggers en image  
 

 

Quesque tu ne comprend pas ?    
 
Soit plus précis !

si tu avais bien lu c'était marqué dans le commentaire déclencheur du trigger chargement.
En fait la boucle principale de 1 à 5 ne s'éxécute que de 1 à 3
La seule expliquation que je trouves c'est peut être que worldedit ne suporte pas que l'on imbrique 2 boucles l'une dans l'autre

Il ne supporte pas.

bizarre quand même qu'il accepte la boucle de 1 à 3  

Mais plusieurs DisplayText pour voir ce qu'il se passe.

Faut le savoir, je ne l'avais pas vu non plus...

c'est déja fait ayane et je confirmes la boucle principale ne se lance que trois fois    

Le code GUI a l'air correcte, convertit le en Jass pour voir.

je vais essayer ca demain, j'en dirais plus quand j'aurais essayé
En fait les integer A et B peuvent eux aussi "saturer" la mémoire comme les variables locales ?
Si on utilise uniquement le gui il vaut mieux utiliser des varaibles pour éviter le lag ?

En t-k, moi j'essai d'éliminer toutes variables locales, alors oui moi je met des variables même pour les Interger! llol

Saturé? un entier sur WC3 est coder sur 4 octets soit une valeur maximale de FFFFFFFF, ce qui donne en décimale 4294967295, l'entier étant signé ça va de -2147483648 à 2147483647
0 à 2147483647 => 0 à 7FFFFFFF
-2147483648 à -1 => 80000000 à FFFFFFFF (à moins que ce ne soit l'inverse).
Donc tu auras du mal à saturer de 1 à 5.

rien compris ayane...
ps : mais j'aime bien kenshin aussi (les ais tous ^^)

c'est pour cela que j'avais mis saturé entre guillemets, je vais reformuler ma question plus précisément.
Je suis tout à fait conscient que ces seul triggers ne feront pas lagger le jeu, je ne suis pas tout à fait stupide.
En fait je parles des memory leak, j'ai cru comprendre que cela concernait les variables locales, du genre triggering unit, center of playable map area, picked unit, etc.
Bref pas mal de choses sauf les integer A et B et je voudrais confirmation ou que la vérité m'éclaire une fois pour toute  

En fait tu n'as pas de mémoire non-libérée (ou memory leak) pour "triggering unit, center of playable map area, picked unit, etc." lorsque tu les utilise, ceux qui font de la programmation objet ou ont déjà utilisé les pointeurs comprendront facilement (c'est la même chose).
Une variable de type entier va stoquer directement en mémoire le nombre, les données des variables dites "objets" pouvant être variable dans le sens de la mémoire utilisé on a en fait ce qu'on appelle un pointeur: il s'agit d'un entier indiquant une adresse mémoire. La suppression de ce pointeur détruit l'entier mais ne détruit pas les données stoquées, et on a par la même occasion plus de possibilités de retrouver cette adresse.
 
En fait on va prendre l'exemple d'un effet spécial, car il s'agit d'une variable qu'on va dire "objet", et que pour l'exemple elle a un effet visuel.
Ainsi si tu fais l'action

Les données nécessaire à afficher cet effet sont alors mis en mémoire.
 
Pour le supprimer tu es obliger de faire

Ainsi tant qu'on n'a pas utiliser Destroy l'effet visuel prendra de la place en mémoire (la preuve est qu'on le voie toujours).
 
C'est donc comme cela que l'on produit de la mémoire non-libérée: en ne supprimant pas les variables dites "objets".
Pour tout ce qui est visuel tel que des unités ça ne pose pas de problèmes car on n'oubli pas de les supprimer. Mais pour tous les autres types il arrive souvent qu'on oubli de les supprimer.
Les variables qui ne sont pas "objets" sont les variables de base suivantes:
entier, réél, texte, boolean
 
Tous les autres types doivent être détruit une fois qu'on ne s'en sert plus. Aussi bien point que groupe d'unités.
 
A vrai dire c'est sur les groupes d'unités qu'il y a le plus de problèmes, surtout que Blizzard a oublié de mettre en GUI le DestroyGroup.
Ainsi

"Units in (Units in Région1 <gen> )" est un groupe nouvellement créer auquel toutes les unités qui sont dans la région sont ajoutées. Le problème c'est qu'à la fin ce groupe n'est pas détruit, hors si on l'utilise dans une boucle périodique la mémoire va se remplir petit à petit.
Heureusement vous n'avez pas à vous empétrez dans du code Jass pour résoudre ce problème, celui ayant conçut les fonctions jass pour le GUI a prévu la suppression des groupes, ainsi vous n'avez qu'à faire

bj_wantDestroyGroup est une variable globale, toutes les fonctions de groupe d'unité pour le GUI détruisent le groupe si bj_wantDestroyGroup est égale à true puis elles la remettent à false.
 
C'est pour cela que l'on dit que le GUI entraîne plein de problèmes de mémoire non-libérée, par exemple pour détruire un point on doit utiliser le Jass (RemoveLocation), hors le GUI utilise principalement les locations au lieu des réels X et Y.
 
 
C'est pour cela qu'en GUI il faut faire attention aux boucles et que c'est assez difficile à gérer la libération de la mémoire, c'est beaucoup plus facile en Jass.
Donc le fait d'utiliser des variables globales ou locales n'ont rien à voir., à vrai dire il vaux mieux que l'on utilse des variable locale lorsqu'il y en a besoin: ça évite les interractions indésirées entre déclencheurs.

hmm merci beaucoup ayane tu es une excellente professeur, je suis encore en train de lire.
sinon pour mes boucles en fait ce n'est pas si simple que je le croyais, les dex boucles se lancent bien le nombre de fois voulu c'est au niveau des 2 dernières action dans la boucle secondaire qu'il y a un os.
Peut être que worldedit est un un peu flemmard sur les bords, je cherches encore
 

 
j'en connais un à qui cela intéressera ....... j'avais RAISON  

Apparemment c'est la chaîne que tu as entré qui a les deux derniers segments qui ne correspondent pas à une valeur de chaine[].
 
Sinon je trouve que ton système prend beaucoup de place: 10 caractères pour stoquer l'or alors que celui-ci peut être mis sur 3 caractères: C'est beaucoup plus embêtant pour l'utilisateur et donc le jeu perd de son intérêt.

Custom script:   set bj_wantDestroyGroup = true
Ah, bien moi je ne savais pas que ça existait cette fonction là

Personnelement, étant donné que moi j'utilise les fonctions DestroyGroup, Destroylocation, DestroyForce, je ne vois pas comment on peut instaurer une variable locale là dedans avec le customscript (Quoi, DestroyGroup_Pickedunit???? LOL? ). En effet, avec ton b_wantdestroygroup = true, c'est faisable, mais c'était inconnu pour moi. Alors, oui, j'imagine que pour les groupe, utiliser des variables locales ou globales sont équivalentes. Sur le site où j'avais consulté les informations, cette information était donc manquante.

Pour les locations, (points), c'est donc évident qu'il faut utiliser des variables globales (si et seulement si la fonction bj_WantDestroyLocation n'existe pas), car sinon, on ne peut pas la détruire. Donc, sur ce point c'est MOI qui avait raison   .

Pour les Picked Player, je ne sais pas si bj_WantDestroyForce existe, alors sinon se serait encore moi.

à vrai dire il vaux mieux que l'on utilse des variable locale lorsqu'il
y en a besoin: ça évite les interractions indésirées entre déclencheurs.

Moi, je trouve que c'est le contraire. J'aime autant mieux pas prendre de chance, (tout dépend du type de map). Mais si tu as beaucoup de déclencheurs qui ont tous la même conditions, mais seulement une chose change, mais cette chose est différentes pour tous, j'aime mieux utiliser une variable globale. J'ai l'impression que mon \"casting unit\" va se promener d'un déclencheur à un autre. C'est donc pour ça que j'utilise des milliards de variables [img]\"\[/img]

Mais bon, ça reste à la discretion du \"mapeur-euse\", il faut juger la situation aussi. Mais sans le bj_WantDestroyCequetuveux, je crois que c'est quand même moi qui avait raison, car tu n'avais mentionné nul part cette fonction [img]\":lol:\[/img]!

De toute façon, on est tous là pour se donner des petits trucs entre-nous! [img]\":hello:\[/img]

 
Mon but est que le code soit le moins clair possible, afin que le joueur lambda ne puisse pas composer un code pour obtenir ce qu'il veut.
Le mieux Ayane c'est peut être que tu me montres comment tu aurais procédé. Moi au minimum je vois que la possibilité de 5 caractères pour l'or allant de 0 à 99999
 

 
Oui mais pourquoi ?
 
Sinon j'ai convertit le déclencheur en jass, même résultat
 
Lunatique : Oui, oui je sais je suis français c'est normal que je soit de mauvaise foi  

Crypter veut dire modifier les données par un algorithme sans en ajouter, ce que tu fais ce n'est pas du cryptage.
3 caractères en considérant que l'on a 36 caractères différends: ça donne 36^3=46656 possibilités
Donc on peut stoquer sur trois caractères jusqu'à 46655 en or ce que je pense est suffisant, ajouter un caractère n'est pas interressant.
on fait donc une conversion de notre or qui est en base 10 vers la base 36
 
 
CBase = "AZERTYUIOP0QSD5FGHJ1KLM7WXCVBN932684"
Base = StringLength(CBase)
Gold10 = 20000
i=0
 
// on divise euclidiennement en prenant les restes
loop
d = Gold10 / Base
c = Gold10 - d * Base
s = SubString( CBase, c+2, c+1 ) +s
exitwhen d == 0
Gold10 = d
i = i + 1
endloop
return s
 
Déjà pour la base on est pas obligé de prendre le 0 pour 0, le A pour 10... on met ce qu'on veut.
Tu peux aussi au lieu de mettre s = SubString( CBase, c+2, c+1 ) +s mettre
s = s + SubString( CBase, c+2, c+1 ) => Ainsi c'est à l'envers.
Après tu peux faire une recherche sur internet, par exemple sur codes-sources.com pour trouver des algorithmes de cryptage, un simple suffit. Ainsi lorsque tu auras un caractère qui changera dans ta chaîne: tous les caractères seront modifiés. Après tu peux toujours mettre des noms de variables bizares ainsi que des calcules illogiques mais dis toi bien qu'aucun système de load/save n'est impassable:
on ouvre la carte avec WinMPQ puis on extrait war3map.j pour avoir le code et si on arrive pas à le comprendre facilement on le modifi afin d'avoir un héros surpuissant et en jeu on fait -save.

 
Je sais bien mais telle n'est pas mon intention, ce que je voulais dire c'est que le code ne soit pas compréhensible au premier abord, qu'il faille au minimum ouvrir worldedit.
J'ai bien précisé le joueur lamda et ce que tu proposes comme solution pour comprendre le code aucun joueur lambda n'est capable de le faire

Pour les variables locales/globales, je ne sais pas si tu as parfaitement compris ce que c'est.
Déjà bj_wantdestroygroup est une variable globale.
 
Je vais prendre du code Jass (assez simple) ce sera plus claire, voici l'action d'un de tes déclencheurs:
// pour indiquer un commentaire
 
Cela c'est ce que tu veux faire, c'est le pseudocode

 
Toi tu ferais donc utiliserais donc une variable globale

Ta variable globale udg_u est un emplacement mémoire accessible de n'importe dans le script.
 
Imaginons que pendant ces 5 secondes une unité vient à mourir, le code Exécuté se résumerais à cela:
soit A le déclenchement lorsque la première unité meurt
soit B le déclenchement lorsque la deuxième unité meurt

Il en résulte que la première unité qui est morte ne sera jamais retirez de la partie.
 
Une variable locale est un emplacement mémoire créer pour chaque fonction, accessible que par cette fonction, et libéré à la fin d'éxécution de celle-ci.
Considérant que l'éxécution des actions d'un déclencheur est l'éxécution d'une fonction.

u n'étant valable que pour l'éxécution de la fonction dans laquelle elle a été créer, on a:

 
Concrétement les déclenchements A et B n'ont aucune interractions entre eux avec une variable locale.
Alors qu'avec une variable globale, ils ont celle-ci en commun: si l'un modifi sa valeur alors elle le sera aussi pour l'autre, ce qui peut entraîner le problème vu ci-dessus.
 
NB: Même sans wait un déclencheur met un certain temps pour s'éxécuter, donc un autre déclencheur utilisant cette variable globale pourrait la modifier entre temps.
 
Donc le code GUI (avec un chouya de jass pour la variable locale) de ce déclencheur se résume à ça:

Il faut créer une variable globale u, l'éditeur ajoutant udg_ devant ses variables globales (pour éviter de faire par inadvertance ce qu'on va faire). Il nous suffit de déclarer en début d'actions une variable local de type unit et de même nom que la varaible globale. Les variables locales ont la priorité sur les variables globales donc en GUI lorsqu'on fera référence à la variable globale u ce sera en réalité dans les actions de notre déclencheur à la variable locale du même nom.