JASS: blizzard.j, GUI -> JASS

05-20-2006, 10:23 PM

For better understanding I only need a short answer.
When you convert GUI to JASS, then most functions have a BJ in it and are from blizzard.j - script.
So, for the first time, I tried to change a little bit to reduce lags through those BJ-functions, and here is the question:
After converting this:

Trigger:

Unit - Set mana of (Triggering unit) to 162.00

to JASS, I got this:

JASS:

call SetUnitManaBJ( GetTriggerUnit(), 162.00 )

Now I looked up the blizzard.j and saw, that this is a function which calls something else, so I tried using directly what the BJ-function would call, and this looks like the following and got compiled without any errors:

JASS:

call SetUnitState(GetTriggerUnit(),UNIT_STATE_MANA,162)

1)
What JASS-command should I use now, the 2nd?
Or is there even a better one for setting the mana of a unit to a value?

2)
Should I set up a local integer variable for the mana value (here: 162) or is it ok to leave it so?
(I mean local integers will be cleared at the end of a trigger, but in blizzard.j for the value there stands RMaxBJ(...).
I searched for this in blizzard.j and found:

JASS:

function RMaxBJ takes real a, real b returns real

So is that now a handle which I should clean up or is it a local real or even a global real???)

05-20-2006, 10:43 PM

Jacek

Quote:

1)
What JASS-command should I use now, the 2nd?
Or is there even a better one for setting the mana of a unit to a value?

The 2nd func is one of "native" functions, BJ functions often call natives swapping parameters or doing some other unnecessary things to them. Use natives wherever possible, don't use BJs at all...

Quote:

2)
Should I set up a local integer variable for the mana value (here: 162) or is it ok to leave it so?
(I mean local integers will be cleared at the end of a trigger, but in blizzard.j for the value there stands RMaxBJ(...).
I searched for this in blizzard.j and found:

JASS:

function RMaxBJ takes real a, real b returns real
So is that now a handle which I should clean up or is it a local real or even a global real???)

Reals doesn't need to be cleaned up.

05-20-2006, 10:53 PM	#3
MasterofSickness	Thanks Most Helpful User! :)

05-21-2006, 01:29 AM	#4
emjlr3	just check through your function, as long as there are no bjs, ur good

05-21-2006, 11:15 AM

The)TideHunter(

Reals, integers, strings, booleans and code dont need to be cleaned up, they are non-handles.
Handles are things like, units, items, players, abilities etc.
If a function returns a variable, and you use the function by calling it, then you will have a leak, way to go around this is not to call it.

In this case, the PickEveryUnit returns a group, but, if we aviod calling it, and use it in a local variable, then we can destroy it later.
Calling a group function(leaks):

JASS:

    call ForGroupBJ(GetUnitsInRectAll(GetPlayableMapRect()), function SomeFunction)

This leaks a group variable, GetUnitsInRectAll is a function that returns a group.

To aviod this use this code:

JASS:

    local gruop TempGroup = GetUnitsInRectAll(GetPlayableMapRect())
    call ForGroupBJ(TempGroup, function SomeFunction)
    call DestroyGroup(TempGroup)
    set TempGroup = null

This function sets a group to the leakable function, then destroys it later.

The only other way to destroy a leaked group when calling is the globals of LastCreatedGroup etc.
But after you create 2 groups, then the first will be lost forever, perma-lag build up.

05-21-2006, 01:11 PM	#6
oNdizZ	I thought String was a handle that just couldnt be cleaned properly ^^ correct me if im wrong.

05-21-2006, 01:15 PM

MasterofSickness

Thank you for further help,
but when I compare yours posts [emjlr3 and The)Tide Hunter(]
it seems a little paradoxically to me...
emijlr3, you say that you should use functions without bj
The)Tide Hunter(, you say that it is ok to use bj functions, as long as you set the handle var to a var and destroy and nullify it afterwards.

Question:
So, in some cases you just have to use bj-functions, because there are no similiar native functions, and then you have to go like Tide Hunter said, right?

05-21-2006, 01:34 PM	#8
Tim.	Just do not use bj functions. Natives are much better to use.

05-21-2006, 01:38 PM

Anitarf

Actually, The)Tide Hunter('s post has little to do with your question, since what he said is true if you use a BJ function like GetUnitsInRectAll() or a native like GetUnitLoc(). Either way, if a function creates a handle object which you only need temporary (like a unit group), you have to properly dispose of that object.

The point about BJ functions is, as long as they do nothing except call another (native) function with the same parameters they receive, they are useless and it helps code efficiency to ommit them. Some BJ functions do more than that, though, and can be helpful by making your code shorter, for example the generic unit event.

However, some BJ functions have leaks within themselves, namely the not-set-local-handles-to-null leak, it is better to recode functions like that yourself.

So, the best advice I can give you is, always examine what the BJ functions do, what other functions they call, do they make any leaks along the way. Calling natives is generaly better, but there are some BJ functions that aren't any less optimized than what you could code yourself, and it's just quicker to use them.

05-21-2006, 03:31 PM

#10

MasterofSickness

Quote:

Some BJ functions do more than that, though, and can be helpful by making your code shorter, for example the generic unit event.

Quote:

So, the best advice I can give you is, always examine what the BJ functions do, what other functions they call, do they make any leaks along the way. Calling natives is generaly better, but there are some BJ functions that aren't any less optimized than what you could code yourself, and it's just quicker to use them.

Right, ok, so in future I will just look up the blizzard.j everytime I have a new function where I'm not sure what exactly it does.

Quote:

However, some BJ functions have leaks within themselves, namely the not-set-local-handles-to-null leak, it is better to recode functions like that yourself.

Ah, thanks for that example!
It helps understanding what you want to tell me!

Quote:

Yeah, right, you always have to clear handles as far as you get them,
now I see that my question was a bit strange.
I just didn't know that some BJ-functions are just usefull and already clear up themself.
So every BJ-function is different and I have to look them up.
With my question I ment that when you use BJ-functions, always have a look what exactly it does, and when it is one like the one Tide Hunter showed, you have to go this way he described for removing handles.

05-21-2006, 04:08 PM

#11

The)TideHunter(

To put this in final perspective, BJ's are bad. They are useless, natives are direct meaning more offiecent and less lag.
Some natives leak themselves, thats what i tried to point out, thats why you need to set them to locals

This is silly code, but it would happen

JASS:

    call CreateTextTag()

That is a great native, but if you call it, its returning a handle and not assigning it to a local.
So that texttag you created is perminantly lagging your game and will never be destroyed because you havent set it as a local to show where it is pointing in memory.

On the other hand, using this is leak free:

JASS:

    local texttag SomeTag = CreateTextTag()
    call DoSomeFunctionsOrWhatever()
    call DestroyTextTag(SomeTag)
    set SomeTag = null

Unlike the first, this is leak free.
Sorry if this is just making this thread longer, but im putting it in perspective.
Calling a function that returns a handle wether it be a BJ or Non-Bj, will leak.

Using a local or global to assign the function return to will not leak.

05-21-2006, 04:38 PM

#12

MasterofSickness

Quote:

Sorry if this is just making this thread longer, but im putting it in perspective.

No, that was good!
So it is better to also look up the common.j for functions to see what they do.
But generally I understand:
- Use natives whenever possible
- Note that a few BJ-funcs in some situations can do also a good job
- Always look up the sripts (blizzard.j for BJ-funcs & common.j for Natives)
- Assign Handles to locals, to show where they are pointing in memory
- Clearing up by destroying locals and nullifying their values

EDIT:
Wow! One question I have again!
Where are these functions declared?

JASS:

SetTextTagPermanentBJ
SetTextTagLifespanBJ

I can't find it in the blizzard.j or common.j, but it has to be in there or?

05-21-2006, 06:11 PM	#13
TaintedReality	Well of course they're in Blizzard.j, they have BJ on the end of them =P. http://jass.sourceforge.net/doc/api/...-texttag.shtml

05-21-2006, 06:24 PM	#14
MasterofSickness	Then what did I wrong? I extracted the blizzard and common.j from my Warcraft III folder from War3x.mpq and then searched for SetTextTagPermanent with and without BJ, but Notepad says that it can't find anything??? So, right, they are listed on this site (http://jass.sourceforge.net/doc/api/...texttag.shtml), but where do I have these functions declared in my WC3?

05-21-2006, 06:51 PM	#15
Anitarf	Did you look in the patch mpq? Some functions were added later with patches.