[JASS] Does TriggerRegisterAnyUnitEventBJ really leak?

[Deuterium]

Well, although as far as I know TriggerRegisterAnyUnitEventBJ does leak, I've been noticing some Jassers lately mentioning that it doesn't really leak.

So, does TriggerRegisterAnyUnitEventBJ really leak or not?

Oops I was reading rules, and I guess this should be in the World Editor Help Zone... should it?

 

[PurplePoot]

Doesn't really matter.

Oh, and

function TriggerRegisterAnyUnitEventBJ takes trigger trig, playerunitevent whichEvent returns nothing
    local integer index

    set index = 0
    loop
        call TriggerRegisterPlayerUnitEvent(trig, Player(index), whichEvent, null)

        set index = index + 1
        exitwhen index == bj_MAX_PLAYER_SLOTS
    endloop
endfunction

 

[Viikuna]

yep, it doesnt really matter. It doesnt leak as far as I know, and even if it does I would still use it.

 

[Ciebron]

can't boolexprs leak? or they are just minor?

 

[Viikuna]

They say that null boolexprs leaks with GroupEnum but not with events.

I dont know if this is true, but it doesnt really matter, since I never use null boolexprs with GroupEnum and even if every AnyUnitEventBJ actually leaks those 16 boolexprs, that would not matter at all, since that function is only called in map init anyways. ( At least thats how I use it )

 

[Deuterium]

Oh, and

function TriggerRegisterAnyUnitEventBJ takes trigger trig, playerunitevent whichEvent returns nothing
    local integer index

    set index = 0
    loop
        call TriggerRegisterPlayerUnitEvent(trig, Player(index), whichEvent, null)

        set index = index + 1
        exitwhen index == bj_MAX_PLAYER_SLOTS
    endloop
endfunction

Thanks PP I forgot to post the function code of the BJ... =)

I dont know if this is true, but it doesnt really matter, since I never use null boolexprs with GroupEnum and even if every AnyUnitEventBJ actually leaks those 16 boolexprs, that would not matter at all, since that function is only called in map init anyways. ( At least thats how I use it )

Well now it's not a matter of whether it matters or not, but I'm just curious to know if users are supposed to still use an Anti-Leak filter instead of the null in the TriggerRegisterPlayerUnitEvent or not...

It's just a matter of knowledge rather than efficiency

 

[PurplePoot]

Who cares?

 

[Deuterium]

Heh I do...

 

[Dark_Dragon]

exactly like everyone said and as i told you before. boolexpr leaks are caused when null is inserted at place of that boolexpr however many people ignore it coz its minor leak. i am one of this guys who dont ignore that leak and fix it. however i only told you about that leak so that you know it exists... but if its any problem like readability of your code then dont use it if you dont want...

Poot said it in right way! who cares? well there are some who do and some who dont! but both ways are acceptable. leak is minor and only 16 leaks on map init so...

and most important thing is like i told you before! just select your own way of coding and so.. you said that some people said it does not leak... well some of them simply ignore it and say it does not and then this who dont know read it and then they talk like they know...

it is true that its really not a big leak but i like to fix my leaks so thats why i do it.
and remember not to trust just anyone who tells you some random stuff... just ignore them if they are persistent. so just select do you want to remove it or not and if you want not to remove it and someone bothers you that it leaks just say its a minor and keep going with your coding style and skills, else if you select to remove leaks and someone tells you it does not leak just say you want to be sure nothing leaks... coz its not a leak to insert a proper boolexpr...

thats all and i hope you now fully understand boolexpr-s!
Greets!
~Dark Dragon

 

[GhostWolf]

function empty takes nothing returns boolean
    return true
endfunction

function TriggerRegisterAnyUnitEvent takes trigger trig, playerunitevent whichEvent returns nothing
    local integer index = 0
    loop
        call TriggerRegisterPlayerUnitEvent(trig, Player(index), whichEvent,wtf_is_the_syntax(empty))

        set index = index + 1
        exitwhen index == bj_MAX_PLAYER_SLOTS
    endloop
endfunction

Hurray?...

 

[Silvenon]

Passing null as a parameter sometimes leak (so I've heard). Making a boolexpr of a function that returns true is a good thing to do.

function True takes nothing returns boolean
    return true
endfunction

// ...

call TriggerRegisterPlayerUnitEvent(trig, Player(index), whichEvent,Condition(True))

Pooty has the greatest answers ever.

 

[spiwn]

Passing null as a parameter sometimes leak (so I've heard). Making a boolexpr of a function that returns true is a good thing to do.

function True takes nothing returns boolean
    return true
endfunction

// ...

call TriggerRegisterPlayerUnitEvent(trig, Player(index), whichEvent,Condition(True))

For some more personal knowledge:
Wouldn't that still create 16 boolexp? I mean, the Condition function creates a boolexp from a function.
Offcourse that is easily avoidable, by using a global boolexp variable.

Pooty has the greatest answers ever.

Indeed he does.

 

[PurplePoot]

Feel free to spend half an hour researching whether this leaks and if so in what way and then writing a solution to it if it does, and I'll spend that time doing something productive. I mean really, run-once leaks (and in that low numbers) are a joke even if they exist, and should only be avoided when it isn't an utter hassle to do so.

 

[busterkomo]

The whole "anti-leak, return true functions" are awful. The mapper should either use their own event function (like GhostWolf suggested), user BoolexprUtils, or just stick the BJ.

 

[PurplePoot]

Wouldn't that still create 16 boolexp? I mean, the Condition function creates a boolexp from a function.

Boolexprs are tabled like strings.

 

[Anachron]

RegisterAnyUnitEventBJ is one of the good BJs, if it would leak then just 16 minor leaks, which doesn't affect gameplay.

For me, I would just stick to the RegisterAnyPlayerEvent (or whatever it was called) and make my own loop, use a dummyfilter-function and clean it.

I don't really matter whether that leak is much or not, but clean scripting is my aim.

And why not?


Anyway, I would like to get a few new events, so I think I am gonna make an Event-System.

 

[Dark_Dragon]

For some more personal knowledge:
Wouldn't that still create 16 boolexp? I mean, the Condition function creates a boolexp from a function.
Offcourse that is easily avoidable, by using a global boolexp variable.

Boolexprs are tabled like strings.

thats correct! so its just up to coder to selcet does he want to use Condition(func...) or store it in variable. well storing it in variable is only a few nanoseconds faster so if u want sure do it!

call Filter(function DummyBool)
call Filter(function DummyBool)
call Filter(function DummyBool)
call Filter(function DummyBool)
call Filter(function DummyBool)
call Filter(function DummyBool)

call DestroyFilter(Filter(function DummyBool))

leaks cleared... since its bool table and it is just referenced at function ~via Filter of Condition natives... the read boolean condition from table and thats all. same table is never created twice no matter how much you call Filter or Condition of same function. DestroyBoolExpr simply destroys table so it is cleared until next time you generate it.

about null filter its like poot already said its a minor leak and it wont cause lag or delays in game if not removed...

 

[spiwn]

Feel free to spend half an hour researching whether this leaks and if so in what way and then writing a solution to it if it does...

There isn't the slightest chance for that to happen. I much more enjoyed spending a day with a friend.
I was just wondering how good is the coding of a top game(of it's day).

 

[PurplePoot]

I should note that And(), Or(), and Not() boolexprs are not tabled.

 

[Dark_Dragon]

I should note that And(), Or(), and Not() boolexprs are not tabled.

yeah they must be destroyed! ~via DestroyBoolExpr but if i remember correctly i never saw anyone else other then me using them well i used And() in fully leakless groups since it was a must...

well And, Or, Not are not taking code they take already referenced boolexpr and thats why ofc game cant know what to do other then really loading an object.. which ofc means its a must to destroy it..

ty for explaing thing to people Poot! +rep
i am having hard time sometimes explaining things to everyone who asks :S

Greets!
~Dark Dragon

 

[Silvenon]

yeah they must be destroyed! ~via DestroyBoolExpr

They mustn't be used in the first place. I can't think of a single case which would require that...well, only if you have to add a condition to a boolexpr after a while, but that could also be avoided, I think.

 

[Viikuna]

Well for example Jesus4Lyfs timer system KT2 uses And() because it allows the system run more faster and makes it pretty damn fast actually.

Those are useful, but pretty rarely yea.

 

[Dark_Dragon]

Well for example Jesus4Lyfs timer system KT2 uses And() because it allows the system run more faster and makes it pretty damn fast actually.

Those are useful, but pretty rarely yea.

thats right! and its exactly the same reason why i used them... to return false in one of them so units never gets in the group and ofc for speed since they are faster then normal loops.

 

[Viikuna]

Yep, stuff is not always useless even if you dont know how to use it.

 

[D4RK_G4ND4LF]

why don't u just go test it? it's easy! even I can do it!

well here are my results

this is the trigger:

• Test
  • Events
    • Time - Every 0.01 seconds of game time
  • Conditions
  • Actions
    • Trigger - Add to (This trigger) the event (Unit - A unit Dies)

there was another trigger shutting down this one after 60 seconds and destroying it after another 60 seconds

it never came this far
after ~ 2 mins (my cpu was at 50% very fast [dualcore] so it is at least proven that is cause lag) the ram usage had rissen from 92 to 200 mb and the game was totaly frozen so i stoped the test
i'll do the same again with smaler values now

edit:
wtf...I didn't expect that comming oO

this time the second trigger locked like this:

• turn off
  • Events
    • Time - Elapsed game time is 15.00 seconds
  • Conditions
  • Actions
    • Trigger - Turn off Test <gen>
    • Wait 30.00 game-time seconds
    • Custom script: call DestroyTrigger( gg_trg_Test )

after 15 sec the ram usage had risen from 92 to 101.7
30 seconds later after the trigger should be destroyed (is it the correct way to do? I hope so)
the lag rose from 101.7 to 102.7 :/
however there was no fps loss or anything else this time

 

[Mooglefrooglian]

uh.. your first trigger is not "leaking" as we know it, since you still can destroy it at any time..

 

[Deuterium]

Wow hehe I was expecting simple "yes" or "no" answers
Thank you all for commenting...

 

[D4RK_G4ND4LF]

uh.. your first trigger is not "leaking" as we know it, since you still can destroy it at any time..

but it seems like the memory doesn't return after the trigger is destroyed

 

[Viikuna]

Its not a problem since you hardly ever need dynamic triggers anyways.
( Cant think any situation when I would really need them )

They might be really easy and everything for damage detection or stuff like that for some one spell, but the best way is to use some generalized systems that handle all that stuff for all your spells in your map.