[JASS] About Natives?

[SA Dashie]

Well considering that I have been in attempt to getting used to trying to go fully into jass, I have come to a little error in my knowledge.. Natives. I would like to know as much as I need to know about them, whats the advantage, and to know of an example in actual code to know of how to use natives.
I've tried to look for tutorials about them although I couldn't find any. Any small bits of small help would be highly appreciated. ^^

 

[ap0calypse]

Natives are the driving force behind any trigger. In GUI, they're the events and the actions but then in a cleaned form.
To use a native, write "call", then the native name, open a bracket, write whatever it is the native takes (separated by comma's) and close the bracket. A bit like this: call NativeName( integer, real, real, unit )
An actually working example would be native CreateUnit takes player id, integer unitid, real x, real y, real face returns unit
To use this native, you can do:

call CreateUnit( Player(0), 'hfoo', 0., 0., 0. )

The JassHelper found in JNGP has an autocomplete-function and it also tells you which values the native takes.

All (?) natives can be found in common.j (in war3.mpq/Scripts).
Alternatively, JNGP also has a native-list.

 

[SA Dashie]

Oh ok, I guess that clears up the random natives that I find in that sort of data that just have the kind of random string that just start with a native call in Jass Newgen.
Any other kind of add-on to ap0calypses post would be highly appreciated.^^
I can't give anymore rep out to you as it appears that I need to spread more. :|

 

[Spartipilo]

Well.. it's hard to add something. Natives are the "roots" of JASS. In the end, it's all reduced to natives.

The good thing about JASS is that it lets you go directly to them, avoiding most of the BJ's madness GUI represents

 

[ap0calypse]

The good thing about JASS is that it lets you go directly to them, avoiding most of the BJ's madness GUI represents

That's actually a good point, maybe I can go into further detail here (though it'll probably be more about BJ's than natives ).


When going from GUI to JASS, you're probably going to convert a lot of GUI-triggers to JASS (this is normal, you want to know how stuff is done after all).
The problem is that GUI isn't really good with stuff like that. Almost all actions in GUI are BJ's.
The difference between a native and a BJ is that a native directly runs some code, while a BJ is a compilation of natives (and sometimes other BJ's).
Directly running code is always faster than taking a detour, that's why many people (rightfully) claim that BJ's are bad (note that not all of them are).

So the advantage of natives is that they're fast (compared to the other option, BJ's).
There is no real disadvantage to natives. Well, sometimes it does take a lot of natives to do something, but that's pretty much how programming works sometimes .
You can also create your own function with natives if it does something repeatedly, so you can at least shorten it.

I can't give anymore rep out to you as it appears that I need to spread more. :|

Don't worry about that, I've got plenty already and you have given me quite a bit of rep in the past

 

[Linaze]

Might be worth mentioning not all BJs are shit, though. TriggerRegisterAnyUnitEventBJ is a good example of that.

But yes, most of the time you should avoid them alltogether.

 

[Spartipilo]

TriggerRegisterAnyUnitEventBJ is a lot better replaced with a "Pick Every player" and "Trigger add event" on map Init, else, it creates Event leaks.

 

[Tirlititi]

Event leaks of initialisation triggers are hardly a problem.

All (?) natives can be found in common.j (in war3.mpq/Scripts).

There is another file, common.ai, that contains AI script's natives. Since the AI scripts are less or more the same thing than jass, you can use few of those AI natives inside a jass script.
Example :

native GetUnitGoldCost      takes integer unitid                        returns integer

However, you have to declare them in the common.j. The JNGP handles that well : you just have to declare the native inside your script and jasshelper import a common.j in your map with that native to make it usable.

 

[PurgeandFire]

TriggerRegisterAnyUnitEventBJ is a lot better replaced with a "Pick Every player" and "Trigger add event" on map Init, else, it creates Event leaks.

I wouldn't really consider them to be leaks. Leaks in Warcraft III are often defined as (1) objects you lose reference to, or (2) useless memory that can be removed. In case (1), you technically don't have reference to them but you still have reference to the trigger, so if for whatever reason you don't want your events anymore, you can just destroy the trigger. (there is no native to destroy an event directly) As for (2), it is not useless, you need it to fire the triggers throughout the game.

Now, I suppose one could argue that it will register the events for ALL players and not just the ones you want to register it for. That is true. However, this is necessary to prevent any breaking. Imagine if you just registered it for a select players, then you spawn a unit of a different player. Suddenly, it won't register for them. Therefore, using TriggerRegisterAnyUnitEventBJ() is fine. You can inline it but it isn't really necessary.

 

[Almia]

Here are the list of natives by Mag:
http://www.hiveworkshop.com/forums/pastebin.php?id=3abweo

 

[mckill2009]

Take note that BJ's are only bad when calling 'one' direct native, like this:

function UnitAddAbilityBJ takes integer abilityId, unit whichUnit returns boolean
    return UnitAddAbility(whichUnit, abilityId)
endfunction

instead of UnitAddAbilityBJ, just use UnitAddAbility coz it's faster...

now if a wrapper calls a native like in TriggerRegisterAnyUnitEventBJ, it's logical coz it enumerates/registers all players...