Avoid Bj functions

[8uY_YoU]

Why we should do that?

 

[WolfieeifloW]

BJ's call upon "natives".

Doing something like:

call AddSpecialEffectLocBJ() //BJ version, we'll call this (1)

Is the same as doing:

 call AddSpecialEffectLoc() //Native version, we'll call this (2)

Except for the fact that doing the BJ one(1) just calls upon the native one(2).
So instead of calling upon a function(1) that calls upon another function(2);
Why not just call upon (2) itself.

 

[GooS]

Except for the fact that doing the BJ one(1) just calls upon the native one(2).
So instead of calling upon a function(1) that calls upon another function(2);
Why not just call upon (2) itself.

Indeed, as few functioncalls as possible is a good thing!

Some BJ's even call other BJs, or as some BJs that call multiple BJ's that call BJ's themselves, now that is not efficient!

//==GooS

 

[WolfieeifloW]

There are some BJ's that are okay though;
Or that are just easier since the native version has like 50 lines.

Although if you're just starting out that may get confusing so I won't say anything .

 

[GooS]

There are some BJ's that are okay though;
Or that are just easier since the native version has like 50 lines.

Although if you're just starting out that may get confusing so I won't say anything .

Such as events, people will tell you that some, if not most, events aren't worth removing from a BJ.

//==GooS

 

[TriggerHappy]

Short and simple.. Their slower. Some also leak.

 

[Viikuna]

Yep.

You dont know what they exactly do. They usually do some useless stuff you dont need to be done, some of them even leak or do something really harmful.

Not all of them are bad ofc, TriggerRegisterAnyUnitEventBJ and BJDebugMsg are most common good ones.

Just never ever use a BJ function without first checking what it really does. ( You can use NewGens function list for that )

 

[Dinowc]

yeah one of the most funniest BJs is "IsUnitAliveBJ" function...

it goes something like this:

function IsUnitAliveBJ takes unit u returns boolean
     return not IsUnitDeadBJ(u)
endfunction

function IsUnitDeadBJ takes unit u returns boolean
     return GetUnitState(u, UNIT_STATE_LIFE) <= 0
endfunction

it just keeps calling another BJ, so you could just use GetUnitState(u, UNIT_STATE_LIFE) > 0 to check if the unit is alive :thup:

 

[wraithseeker]

Oh no, you use GetWidgetLife(whichUnit) <= 0.4xxx to check whether if the unit is dead or not.

 

[T.s.e]

The funniest BJ has to be this one:

function DoNothing takes nothing returns nothing

endfunction

And Wraithseeker, this works just as well as GetWidgetLife. Not sure about the efficiency though.

IsUnitType(u, UNIT_TYPE_DEAD) == false

 

[Romek]

> The funniest BJ has to be this one:
Actually, DoNothing has uses.
In single-line If/then/else blocks in GUI, a function has to be in the else part. If nothing is wanted, DoNothing is the only candidate.

It's more useful than the swapped-argument BJs.

I don't see any uses for this though:

function UnitId2OrderIdBJ takes integer unitId returns integer
    return unitId
endfunction

 

[WolfieeifloW]

Yeah...
It's weird.
In Conditions (Function conditions) I use "IsUnitType(u, UNIT_TYPE_DEAD)" but then if it's just an 'if' statement I use "GetWidgetLife(u) <= 0.405" .

 

[Azlier]

The funniest BJ has to be this one:

function DoNothing takes nothing returns nothing

endfunction

No, I found the funniest one like a month ago.

function CommentString takes string commentstring returns nothing
endfunction

 

[8uY_YoU]

Hey...
What kind of BJ function that cause leak

I'm new jasser since last week

 

[Romek]

PolledWait is one.

 

[WolfieeifloW]

It's the same as GUI pretty much.
Locations, unit groups, player groups, etc.