Le sujet du topic résume bien la situation. Vous voyez Polar Escape 3, les deux derniers niveaux ? C'est ça que je suis en train de faire. (exactement, puisque que je refais la map de LimiteR). Les monstres apparaissent, vont à un endroit, puis disparaissent. Donc il devrait y avoir un nombre constant de monstres sur la map. Or la mémoire monte, monte, monte. Voici mes triggers de spawn :
 

Voila qui prouve que je n'ai pas totalement cerné le leak.
 
 
 

Et voici les triggers de déspawns :

Je ne releaserai po de map qui leak (contrairement à d'autres), donc il faut absolument que je sache d'où viennent les leaks

Au fait ça :

Ca sert juste à faire apparaître le point des monstres sur la minicarte (comme ils ont infestation)

  1. function Trig_lvl7_Troll_spawn_Actions takes nothing returns nothing
   2.
   3.     local unit troll
   4.     local integer noTrollInd = GetRandomInt( 0, 3 )
   5.    
   6.     local integer i = 0
   7.     loop
   8.         exitwhen ( i > 3 )
   9.         if ( i != noTrollInd ) then
  10.             set troll = CreateUnitAtLoc( Player(11), 'n000', udg_lvl7_monster_spawn_pos[ i ], 270 )
  11.             call ShowUnit( troll, false )
  12.             call ShowUnit( troll, true  )
  13.             call IssuePointOrderLoc( troll, "move", udg_lvl7_monster_remove_pos[ i ] )
  14.         endif
  15.         set i = i + 1
  16.     endloop
  17.
  18. endfunction
  19.
  20. //===========================================================================
  21. function InitTrig_lvl7_Troll_spawn takes nothing returns nothing
  22.     set gg_trg_lvl7_Troll_spawn = CreateTrigger(  )
  23.     call DisableTrigger( gg_trg_lvl7_Troll_spawn )
  24.     call TriggerRegisterTimerEventPeriodic( gg_trg_lvl7_Troll_spawn, 4.50 )
  25.     call TriggerAddAction( gg_trg_lvl7_Troll_spawn, function Trig_lvl7_Troll_spawn_Actions )
  26. endfunction
 
Quand tu fais CreateUnitAtLoc, tu as une location, et malheureusement tu ne suprime pas ta location à chaque fois.

sauf que cette location est une variable globale, donc c'est toujours la même. Autrement dit, cette fonction ne crée pas de location. Ceci crée des locations :

Que ton point soit global ou local, tu le créé pareil; la seule différence c'est que si exemple tu fais :
 
set udg_point = GetUnitLoc(premièreunité)
suivi immédiatement de
set udg_point = GetUnitLoc(deuxièmeunité)
call RemoveLocation(udg_point)
 
Tu leaks; la première location a été mise de côté parce que tu lui as attribuée une nouvelle valeur; or, elle a été créé et tu n'a plus l'opportunité d'aller la chercher.
 
Et non, des réels (x,y) ne sont pas des leaks.  
 
#         set udg_lvl7_monster_spawn_pos[ i ] = Location( X, spawnY  )
#         set udg_lvl7_monster_remove_pos[ i ] = Location( X, removeY )
 
ça, ^ca peut le devenir si tu ne les enlèves pas.

Je ne suis pas d'accord avec toi Lunatique il crée ses points uniquement à l'initialisation, il ne fait que les utiliser par la suite il n'en crée pas (d'ailleurs ca soulage fortement le processeur cette méthode).

Je pense plutôt que la mémoire n'a pas le temps d'être libérée n'ayant repéré aucun leak , mais je peux me tromper bien sûr.

As tu testé de stopper l'exécution des triggers et de voir si la mémoire occupée diminue ?

nulle création de point dans cette fonction ou alors c'est une farce de Blizzou

Tout ce qui contient Loc dans sa fonction demande un point. Si tu fais CreateUnitAtLoc où loc est "Center of Playable map area", bien même si le point "center of playable map area" existe déjà, c'est un leak car tu créé un point. Si ses locations sont uniquements créées à l'initiation et qu'il s'en sert seulement par la suite pour ordonner des choses et qu'elles ne changent pas de valeur, non ce n'est pas un leak, c'est une bonne méthode d'ailleurs.

C'est ce qu'on te dit depuis tout à l'heure , je sais bien que location = point, mais il ne créé pas de nouveaux points  

Pour les get bien sûr que ca leak car ce sont des fonctions qui return une location ...

Ah si en fait j'ai vu un leak les strings ...
Utilise des variables strings plutôt que les strings eux même.

donc au lieu de "move" utilise une variable globale string ayant pour valeur "move"

C'est pas vrai, un string ça leak aussi!!??!!

Oui et on peut rien y faire à part éviter d'en utiliser, les remplacer par des variables quand on doit utiliser le même plusieurs fois.

Enfin c'est un leak mineur mais réel

http://worldedit.free.fr/forum/viewtopic.php?t=1959

C'est d'ailleurs la raison d'existence des string extérieurs (quand tu créé un string en gui )

C'est horrible. Mais comme c'est simplement quelques leaks mineurs, ça ne vaut peut-être pas la peine de refaire le script au complet car je m'en sert partout.
 
Mais je cherche présentement dans les natives, si on fait exemple un local string texte = "Allo", comment on le suprime par la suite? Je ne trouve pas la fonction RemoveString ou DestroyString.

D'où le " on ne peut rien faire ... "

Enfin si comme je l'ai dit si tu l'utilises ne serait ce que 2 fois dans une fonction tu peux faire cela :

On peut juste limiter la casse, evidemment pour les string tel que "move" tu peux utiliser une globale car y'a des chances que tu en auras besoin dans plusieurs fonctions

bah habituellement j'appel tout le temps mon string "nom". Sinon, tempis pour les leaks de string si il n'y a rien à faire. Ça leakera, j'ai enlevé tous les leaks mais je ne m'amuserai pas à attribuer à une variable globale et/ou un string du gamecache une valeur différente à chaque fois que je vais aller rechercher lors d'une utilisation aussi stupide que "order" ou quoi que se soit.

Rebelle  

Bien non faut pas exagérer, si il n'existe que d'autre moyen que de se servir d'un seul et unique string bah là pour les quelques octets de leaks que ça fera, faudrat vivre avec ^^!

dans une fonction périodique ca suck aussi, enfin c'est toi qui voit
 

Si je vois un jours que ça commence à ramer à cause de ça je saute en bas du pont.

Choisis bien ta saison en plein été quand la rivière est asséchée    
 

lol! ^^

**HS**
 
Je me demandais s'il était possible d'aller chercher les données stockés lorsqu'on modifie une unité dans le gestionaire d'édition. Exemple on change son attaque et son modèle du fantassin. Si on rouvre la map avec un éditeur qui peut aller chercher les fichiers a l'intérieur, dans quel fichier .txt ou bien .slk se trouve les modifications? Je crois que de cette manière, quand on créé une unité personnalisé, on peut tout simplement copier/coller les données de l'unité personnalisé à une unité déjà existante dans Warcraft III (tel le paysan) pour éviter d'avoir à créer des unités différentes de plus (pour faire un load moins long).
 
**FIN HS**

go wc3campaigns et prends le widgetizer

    Ahhhhhhhh je comprends maintenant pourquoi ils font ça. Sinon, leak mineur ? Si ça prend 4 octets à chaque création de monstre, ça fait quand mes trois triggers sont en route, 67 octets par seconde (d'après mes calculs). Euh, en effet, il y a pire comme leak.

   On m'a parlé d'un autre leak : lorsque l'on utilise des variables locales qui sont en fait des pointeurs : unités, régions, points...  Si le pointeur n'a pas la valeur nulle à la sortie de la fonction, il reste en mémoire. S'il a la valeur nulle, la variable est alors supprimée. (pour les points, je pense que lorsque l'on fait 'call RemoveLocation( xxx )', le pointeur passe à la valeur nulle)
 
Il me faut donc ajouter ces trois lignes à la fin de mes déclo :

Uniquement la première pour le déclo du lvl7 bien sûr.
 

Je viens de le faire et malheureusment (ou plutôt heureusement), la mémoire diminue légèrement suite à la suppression des monstres. Mais elle est très loin de revenir à l'état initial. Manquerait plus que la mémoire n'ait pas le temps de se libérer. Ouf.

Un petit peu de mesure physique :
 
     tests sur 660 secondes (mémoire en ko)

 
leak variables locales non supprimées : 23,5 - 21,7 = 1,8 ko/s
leak des chaines "move" : 21,7 - 21,6 = 0,1 ko/s
 
    Bon je crois qu'on peut se détendre, il faut vraiment y aller pour faire des leaks conséquents avec les chaînes de caractères. Par contre, le leak des variables locales non supprimées n'est pas négligeable. Même si le leak des "move" et des variables non supprimées est présent, on voit bien que c'est autre chose qui provoque la majeure partie des leaks.

Je me demande si le Register event pour une unite entrante/sortante d'un région en gui leak a chaque utilisation de l'évenement ou simplement à l'enregistrement de l'event.

Enfin je pense pas quand même, mais tente de remplacer par le register natif en créant au préalable des regions pour tes rectangles

Attends.......... une région c'est un ensemble de rect ?
Et le 3ieme paramètre de TriggerRegisterEnterRegion ça correspond à quoi ?

Voila :

Mais ça leak toujours autant .

Je m'en doutais c'est juste à l'enregistrement de l'event mais je vois toujours pas d'autres leak alors ...
Poste ta question sur wc3campaigns.net

Est-ce que quelqu'un aurait l'amabilité d'expliquer à un noob, entre paraenthèses moi (je préfère le préciser), ce qu'est le spawn et le leak SVP ?

le spawn c'est la création d'unités sur la map, le leak ce sont des fuite de memoire, de la memoire non liberee qui n'a plus d'utilité

O^k je passerai moins pour un con maintenant. Ô merci mon Dieu, alias troll-brain, pour bien avoir voulu augmenter mon intelligence aujourd'hui !!

nan même pas j'ai juste augmenter ton savoir, mais c'est vrai qu'en société l'apparence est trés importante, souvent plus que le fond >.<

Bon bin apparemment mon trigger est parfait . Le leak viendrait uniquement des unités qui, lors de leur suppression, ne seraient pas supprimées totalement. -.-