What does the colored text in JASSNewGen mean?

[Kamikazzee]

This is more of a curiosity than a true problem. I'm wondering what it means when a function is colored purple or red in Jass NewGen, even though they basically do the same thing. For example:

GroupAddUnit - Purple
GroupAddUnitSimple - Red

What does this difference mean? Is red less safe than purple? I don't understand.

 

[donut3.5]

Red - BJ call, bad for your health. Hold control and click onto them to see how you can derive the natives.
Purple - Natives, make you and your map happy.
There are many other ones, like green is comments, blue is strings, integers, reals, booleans, etc. and tan is operators (parenthesis, *, /, +, -)
--donut3.5--

 

[Need_O2]

there are good red BJ's too
IsUnitInRect is my favoruite

 

[donut3.5]

I suppose some are useful, but I still try to split it up and optimize.
--donut3.5--

 

[Kamikazzee]

Ah, thankyou Donut. Is there any reason why, specifically, the non-BJ calls are better?

 

[Rui]

Non-BJ calls are better because they are natives. You'd have to know JASS to understand this though.
Some BJ calls do nothing else other than call their native counterpart, that's why they are useless. They just run functions in a useless way.

 

[PitzerMike]

Well, if you're going for JASS they're useless.
In GUI they make a lot of sense in two ways:

1. They ofter re-order the arguments so in the GUI the description can actually be a valid English sentence and not just gibberish.

2. They add another level of abstraction. If one of the functions was broken they could add additional code in the bj-wrapper to fix it, without having to invent a new function. This also ensures that older maps are still compatible with newer/fixed editor versions.

 

[Kamikazzee]

So in a noobish-style wrap-up of this conversation, Non-BJ calls are usually better than BJ calls?

 

[donut3.5]

Read PitzerMike's post for a general trend. Very few ones are useful though.
--donut3.5--

 

[Need_O2]

Look
each time you run a function it uses CPU
more functions more CPU usage more lag
all BJs contain functions inside them so you call BJs and functions inside it
when you call a native you call a native
when you call a BJ you call BJ and natives inside it

 

[Kamikazzee]

Ah, thanks O2. +rep. I now know what is going on and what to use.

 

[PurgeandFire]

In a simple way, natives are faster.

Some BJs like quest BJs offer easy configuration though. But natives are always > than BJs. (BJ stands for BlizzardJASS or Blizzard.j [where all BJ functions and globals are found {but bj_globals are actually useful at times}])

 

[Need_O2]

Umm btw what Ive said is only for bj functions
bj globals are awsome
examples: bj_DEGTORAD, bj_PI

 

[donut3.5]

Quick question, does anyone know which is faster,
UNIT_STATE_LIFE or ConvertUnitState(0), or anything like those?
--donut3.5--

 

[PitzerMike]

Quick question, does anyone know which is faster,
UNIT_STATE_LIFE or ConvertUnitState(0), or anything like those?
--donut3.5--

Doesn't matter. It's clear that UNIT_STATE_LIFE is the only valid choice here for other reasons.

 

[Rui]

1. They ofter re-order the arguments so in the GUI the description can actually be a valid English sentence and not just gibberish.

True, but they could also change the sentence in order to fit the function's order.
Anyway,
~Problem Solved