HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Do Conditions Leak?

08-03-2007, 10:41 PM#1
botanic
I have heard that they do...

if they do leak is it worth the trouble of cleaning of not?
08-03-2007, 10:43 PM#2
Daxtreme
Do you mean conditionfunc? (and boolexpr)

If yes then they don't.

Trigger conditions don't leak.
08-03-2007, 11:29 PM#3
botanic
conditions in the GUI not in JASS
08-03-2007, 11:48 PM#4
Naakaloh
The GUI ends up doing a lot of weird things with conditions, but I don't think they end up leaking.

Edit: I'm fairly certain they don't leak, as I think they only create one handle and reuse it and they don't make any assignments that need to be nullified.

Also, the conditionfunc and boolexpr are what end up being created regardless of whether you're using the GUI or not.
08-04-2007, 06:42 AM#5
cohadar
They don't if you don't make boolexpr local variables.

Pass them directly as arguments and all will be fine.
08-04-2007, 08:52 PM#6
botanic
i think they would because like if i use
Trigger:
Condition
((Triggering unit) is in (Units in (Playable map area))) Equal to True

wouldn't that create a unit group???
08-04-2007, 09:22 PM#7
cohadar
There is nothing special about a condition,
it is just another function.

so the GUI conditions of that kind do leak.
but I guess you figured that out already.
08-04-2007, 09:40 PM#8
botanic
so then to clean those up it would require me to set all the conditions like that into an if then statement ;/ well least i know that it does leak...
08-04-2007, 11:27 PM#9
Earth-Fury
Quote:
Originally Posted by cohadar
There is nothing special about a condition,
it is just another function.

so the GUI conditions of that kind do leak.
but I guess you figured that out already.
http://wc3campaigns.net/showthread.p...ondition%28%29

boolexprs do NOT leak, as the functions employ some sort of caching.
08-04-2007, 11:50 PM#10
botanic
ok but would a NON boolean condition leak?
08-05-2007, 12:37 AM#11
Earth-Fury
... GUI conditions are held withing a functionthat returns boolean.... the function is then passed to Condition() as an argument... Condition() returns a boolexpr which is used as a triggers condition... this booexpr does not leak, unless you only intend to use it once... and if you want to fix such a leak, you will have to use JASS. (as in fully converted, not just a few lines)

and, all condition statements, eg:
1 greater then 0
resolve to true or false. (boolean)
08-05-2007, 12:41 AM#12
SFilip
Yes, conditions can contain a leak (regardless of which comparison you do), works pretty much the same way as with actions.
((Triggering unit) is in (Units in (Playable map area))) Equal to True
Bold=leak.

Problem is...you can't fix these in GUI. However a solution would be wrapping your whole trigger inside one If..Then and thus simulating conditions.
For example instead of
Trigger:
Trigger
Collapse Events
// your events here
Collapse Conditions
((Triggering unit) is in (Units in (Playable map area))) Equal to True
Collapse Actions
// your actions here
you would use
Trigger:
Trigger
Collapse Events
// your events here
Conditions
Collapse Actions
Set g = (Units in (Playable map area))
Collapse If (All Conditions are True) then do (Then Actions) else do (Else Actions)
Collapse If - Conditions
((Triggering unit) is in g) Equal to True
Collapse Then - Actions
// your actions here
Else - Actions
Custom script: call DestroyGroup(udg_g)

Edit: Just saw post #8, guess you already knew this, sorry
08-05-2007, 02:09 AM#13
botanic
its amazing to me how there is the yes AND the no answer so definitely from so many ppl ;P
08-05-2007, 03:40 AM#14
Naakaloh
That's because people thought you were talking about two different things.

So it's not a definite yes or no answer to a single question, but rather a definite yes to one question and a definite no to a different one.

Just to reiterate what has already been said in case it isn't clear; boolexprs and conditionfuncs are fine and the handles they use will not leak when using the GUI, but there may be things assigned inside those functions that might leak like groups or regions because there is no way to clean them up using the GUI other than doing something like what SFilip suggested..