Tutorial The Good, The Bad, and The BJ

[Sevion]

The Good, The Bad, and The BJ

By: Sevion

Contents

Introduction
What is a BJ?
What is a Native?
The Good
The Bad
Conclusion

I would make anchor tags, but they seem to have been removed.

Introduction

I am making this tutorial because there seem to be *many* misconceptions about them.

I.E.: "ZOMG! BJ! I ARE BURNING!!! AGH!!!!!!!!!!!"

Many people seem to believe that all BJ's are terrible and should be avoided at all costs. That cost usually ends up being code readability.

I hate always having to read loop loop loop.... loop.... loop.... or having a quadbillion calls just to do one thing.

Sure, it's an extra call.

ONE (usually) extra call.

Not exactly a lot.

Though, there are some BJ's that are just plain retarded.

Want to know more? Read on!​

What's a BJ?

A BJ is simply a function in the blizzard.j.

Simply put, it's a wrapper made by Blizzard to either make JASSing easier or make it easier to develop/shorter descriptions for the UI for GUI.

An example would be the swapped functions.

A BJ, in essence is a misunderstood tool.

It's like a double-bladed sword. It can both harm your code, and make it better.

It's merely a question of which BJ's to use and which to avoid.​

What is a Native?

A Native is a function programmed into Warcraft III already. They are all listed in the common.j.

All Natives are better than BJ's in terms of speed and efficiency, no arguments whatsoever.

However, BJ's are, in most cases, better for readability, and this can be used in favor over efficiency when it's not going to affect gameplay much or at all and when readability is a high priority.​

The Good

There are good BJ's.

Some are the BJDebugMsg. Yeah, that one is tehpwnagezorz.

BJDebugMsg is like Arnold Schwarzenegger yelling "GET TO DAH CHOPPAH!!!!!!!"



Another few are the math ones like RMaxBJ.

Texttag functions are tehpwn as well if you've ever tried making them with Natives.... *shivers*

Some events like TriggerRegisterAnyUnitEventBJ are alright, though you can also use TriggerRegisterPlayerUnitEvent with GetLocalPlayer()

[PSST! HELP ME LOOK FOR A BJ THAT'S BETTER (efficiency) THAN A NATIVE! I will gets a cookie ]​

The Bad

All Natives are faster than BJ's, however, who the hell can tell the difference between 0.0001 seconds of execution time and 0.0005 seconds?

Seriously?

If you can, you are not human.

BJ's are also very bad.

Consider <FunctionName>Swapped.

What's the point in that?

Well, Blizzard made them in mind that, one extra function call won't hurt and that it would be easier to make the text UI for GUI that way. Though, why they didn't just make the Native oriented that way, I don't know.

An example of this stupidity is:

function SetUnitAbilityLevelSwapped takes integer abilcode, unit whichUnit, integer level returns integer
    return SetUnitAbilityLevel(whichUnit, abilcode, level)
endfunction

Seriously, what's the point in calling a function and having that function return a function?

It does nothing else!

All it does is change the orientation of your arguments!

So, while it helps making GUI texts, it's kind of retarded

That, is a stupid thing to do.

Don't use those functions.

A good way to tell if you should or should not use a function is to check the function's code. If it looks retarded, it probably is.

If you're not sure, use the Native form. It's almost always going to be better.

But, BJ's are more safe. Blizzard made them failsafe(ish). If the Native is bugging for you, try the BJ and see what happens.​

Conclusion

What do I think?

Well, there are many pros and cons.

Let me line them up:

Pros:

• Can be same speed (Keyword: Can)
• Can have better readability

Cons:

• Can have leaks
• Will have less speed
• Can make lag
• Can teach bad habits (Keyword )
• Can get flamed for using them
• Can have worse readability [Yes, I have seen that before]

So, you're looking at this and going "Are you retarded? Cons wayyyyy outweigh the Pros!

Even so, if you know how to use them, you can cancel out a lot of the Cons.

It's all a matter of whether or not you know how to use them.

So learn.

I'm willing to bet some very experienced vJASS'ers may have something to learn here.

So, while it's true, BJ's should mostly be avoided, it depends on your situation

The more you use BJ's in submitted resources etc, the more advice you'll receive and the more you'll know about which BJ's to use, when to use them etc.

So experiment!

Learn!

You will become a BJ master! (Oh, God. That sounds dirty )​

If there is anything I've missed or royally fucked up on, please tell me. I want to make this as accurate and informative as I can.​

 

[_whelp]

BJ master? Stop watching porno. Tutorial is good, but I'm only saying that because I skimmed quickly...

 

[Sevion]

No pronz herez!!! *Hides pronz*



Don't skim Read it!

 

[_whelp]

I read it...

 

[Sevion]

Comments?

 

[_whelp]

Same, again.

 

[WolfieeifloW]

I only got to the end of "The Good".
You're trying to teach that leaks aren't bad or ?
Sure, while one leak will not affect gameplay;
If these leaks pile up (Because people think 'eh, it won't do anything') then they have to go back through and redo their code.

As for your PolarProjection thing.
I actually find the native version easier to read .

And I don't know exacts but;
Wouldn't calling upon that extra function also make the BJ slower?

Although I do agree that some BJ's are definitely useful:
CountUnitsInGroup(), TriggerRegisterAnyUnitEventBJ(), etc.
Either of those, IMO, would have made a better example.

Anyways;
It's really late here so I can't think of anymore .
Tomorrow once I get home from school I shall give this a better read-through.

 

[Sevion]

Bleh. I wrote this on a whim

Tomorrow is last day of school. I'll revise then. XD

I wrote this in the span of 10 minutes

 

[Hellohihi]

Cool. +rep.

One very lame bj i found was:
GetAttackedUnitBJ calls GetTriggerUnit()......

Never knew what was behind the scenes when using GUI.

 

[Sevion]

Told you some of them are retarded

Most of those event responses have to do with GetTriggerUnit()

Trigger Unit is the unit who makes the trigger happen. So A unit is attacked will fire and the triggering unit is the attacked unit. As him being attacked caused the trigger to fire.

 

[Exide]

<Function>Swapped = Code to English.
For example the one you mentioned: 'SetUnitAbilityLevelSwapped'. (I don't have WE with me, so I don't remember it exactly, but you will get the idea.)
SetUnitAbilityLevelSwapped = Set *Ability* for *Unit* to *Level*. (Which is readable in English/GUI.)
If they would've used the native it would be: Set *Unit* for *Ability* to *Level*. (Don't make much sense.)
-Indeed, it is retarded when coding in JASS, but quite understandable when coding in GUI.

About PolarProjectionBJ, you're forgetting that PolarProjectionBJ returns location, not coordinates. Which is fine when coding in GUI, but I don't think I've ever seen a proper JASS spell trigger that uses locations instead of coordinates..
(You already mentioned the leak, so I won't bring that up.) ^^


EDIT:

One very lame bj i found was:
GetAttackedUnitBJ calls GetTriggerUnit()......

Never knew what was behind the scenes when using GUI.

-Which is why you should always use (Triggering Unit) when possible.

 

[Romek]

function PolarProjectionBJ takes location source, real dist, real angle returns location
    local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD) // 2 calls
    local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD) // 2 calls
    return Location(x, y)
endfunction

And Location(x, y) isn't a call?

Also, in that example:

// u is a unit
local location loc = PolarProjectionBJ(u, 10, GetUnitFacing(u))

Syntax error. You need GetUnitLoc(u). Oh, wait. That's another damned function call!

Also, take into account that function calls are needed to remove the location leaks.
This isn't the case when using the 'natives'. (Cos and Sin directly, with x and y)

> [I'm going to get uber-flamed for that]
Fucking retard.

Also, about the Polar Projection. That's usually called many, many times in rapid succession. In which case, the Cos and Sin would be stored into variables. However, when using the BJ, this isn't an option. So not only is it slower as it is, but how much slower it really is begins to shine when put into real situations.

> using BJ's the same speed or even faster than Natives.
Give me an example, and you'll get a cookie.

Only the last Pro of BJs is correct. In rare cases.
The only good BJs are BJDebugMsg (very useful for debugging), and most of the Math ones. RMinBJ, RMaxBJ, etc.
They're actually useful, and certainly help with readability.

 

[Trollvottel]

also, SetUnitLoc isnt the same as SetUnitX/Y.

 

[GooS]

You will become a BJ master! (Oh, God. That sounds dirty )

IRL laughing, well as for the tutorial, it could probably help some, but so could some extra thinking and logic.

SetUnitAbilityLevelSwapped = Set *Ability* for *Unit* to *Level*. (Which is readable in English/GUI.)
If they would've used the native it would be: Set *Unit* for *Ability* to *Level*. (Don't make much sense.)
-Indeed, it is retarded when coding in JASS, but quite understandable when coding in GUI.

Are the GUI functions (Bj's) forced to have those words in between?
Set *Unit*'s *Ability* to level *Level*
And we have a decent use of English, Set *Footmans*'s *Defend* to level *1*
But I've never checked for anything like that so,, hmm whatever


//==GooS

 

[Tom Jones]

There exists only two noteable BJ functions:

call TriggerRegisterAnyUnitEventBJ(...)
call UnitDamageTargetBJ(...)

Texttags are a b**** to create using natives only, so one may be inclined to use the BJ function. However you yourself can create a more efficient function than the one Blizzard made.

 

[WolfieeifloW]

Why's UnitDamageTargetBJ() good?
Not questioning you, I'm just asking personally !

 

[Bloodcount]

This is the only BJ tut a male is ever going to need !

 

[Romek]

> There exists only two noteable BJ functions:
How on earth is the latter any good?

 

[Flare]

Texttags are a b**** to create using natives only, so one may be inclined to use the BJ function. However you yourself can create a more efficient function than the one Blizzard made.

What about creating multiboards? Probably not as hard, but would be convenient to have the one line instead of bloating code with 5 or 6 lines ^_^

How on earth is the latter any good?

You don't have to input a weapon type, or the boolean parameters?

I still don't really know what the booleans for UnitDamageTarget do

 

[Viikuna]

Allmost every map has somekind of custom DmageTarget function with nice boolean arguments, like considerArmor and maybe some custom damage types for dmage systems events and stuff like that.

( well, ok "has" is not quite true. "should have" is better. )

So I would guess that it is quite useless BJ.