Need help to get rid of these BJs.

[Geshishouhu]

Hi all. I need help to get rid of the following BJs. What are the more efficient ways?

function Trig_Begin_Survival_______uActions takes nothing returns nothing
    local integer index
    local force for
    
    set for= GetPlayersAll()
    set index = 0
    loop
        exitwhen index >= 16
        if IsPlayerInForce(Player(index), for) then
            call PanCameraToTimedLocForPlayer( Player(index), GetRectCenter(gg_rct_xiao), 0 )
            call CreateFogModifierRectBJ( true, Player(index), FOG_OF_WAR_VISIBLE, gg_rct_KJD )
            call SetPlayerFlagBJ( PLAYER_STATE_GIVES_BOUNTY, true, Player(index) )
            call SetPlayerStateBJ( Player(index), PLAYER_STATE_RESOURCE_FOOD_CAP, 120 )
        endif
        set index = index + 1
    endloop
    call CreateFogModifierRectBJ( true, Player(11), FOG_OF_WAR_MASKED, gg_rct________104 )
    call DisableTrigger( GetTriggeringTrigger() )
    call EnableTrigger( gg_trg_TZ )
    call DestroyTrigger( GetTriggeringTrigger() )
    
    set for= null
endfunction

and this:

all CreateTextTagLocBJ( "TRIGSTR_15046", udg_SDPoint, 50.00, 10, 15.00, 15.00, 100, 0 )

 

[Adiktuz]

If you're using JNGP, you could always check the function list, look for those BJ, click them and see what functions they call... then just use those functions directly... that would do the work, normally...

btw

local integer index
    local force for
    
    set for= GetPlayersAll()
    set index = 0

can be

local integer index = 0
local force for = GetPlayersAll()

 

[Geshishouhu]

If you're using JNGP, you could always check the function list, look for those BJ, click them and see what functions they call... then just use those functions directly... that would do the work, normally...

btw

local integer index
    local force for
    
    set for= GetPlayersAll()
    set index = 0

can be

local integer index = 0
local force for = GetPlayersAll()

I did that, but sometimes there are BJs inside a BJ, so what should I do? For example:

function CreateTextTagLocBJ takes string s, location loc, real zOffset, real size, real red, real green, real blue, real transparency returns texttag
    set bj_lastCreatedTextTag = CreateTextTag()
    call SetTextTagTextBJ(bj_lastCreatedTextTag, s, size)
    call SetTextTagPosBJ(bj_lastCreatedTextTag, loc, zOffset)
    call SetTextTagColorBJ(bj_lastCreatedTextTag, red, green, blue, transparency)

    return bj_lastCreatedTextTag
endfunction

 

[Adiktuz]

you would look at those BJs too until you get to the natives

for example, on that one...

Replace CreateTextTagLocBJ with those functions... then since you still have BJs in there, you then go and replace each of those BJs and so on

 

[Geshishouhu]

you would look at those BJs too until you get to the natives

for example, on that one...

Replace CreateTextTagLocBJ with those functions... then since you still have BJs in there, you then go and replace each of those BJs and so on

Alright, sounds a lot of work, LOL, but I will do that since no other options are available.
Thanks, +Rep.

 

[Adiktuz]

only at the start, once you get the hang of it, it's not really tedious... plus you can always have a copy of the BJ transformed into a native somewhere (maybe a disabled trigger) after you finish transforming it so you can just copy paste it next time...

 

[Geshishouhu]

only at the start, once you get the hang of it, it's not really tedious... plus you can always have a copy of the BJ transformed into a native somewhere (maybe a disabled trigger) after you finish transforming it so you can just copy paste it next time...

Good idea!

 

[DysfunctionaI]

Floating text happens to be one of the more extreme BJ's. Most are really easy, and you get used to it. Soon you'll just remember the natives and not the BJ's anymore. I was just there myself, not too long ago.

 

[Geshishouhu]

Floating text happens to be one of the more extreme BJ's. Most are really easy, and you get used to it. Soon you'll just remember the natives and not the BJ's anymore. I was just there myself, not too long ago.

Alright, thanks.

 

[BPower]

Just go through the function list in the Trigger Editor.
i.e.

function SetTextTagPosBJ takes texttag tt, location loc, real zOffset returns nothing
    call SetTextTagPos(tt, GetLocationX(loc), GetLocationY(loc), zOffset)
endfunction

and ofc you don't want to use locations.

native SetTextTagPos takes texttag t, real x, real y, real heightOffset returns nothing

or

function SetTextTagTextBJ takes texttag tt, string s, real size returns nothing
    local real textHeight = TextTagSize2Height(size)

    call SetTextTagText(tt, s, textHeight)
endfunction

is just

native SetTextTagText takes texttag t, string s, real height returns nothing

bj_lastCreatedTextTag --> local texttag text = CreateTextTag()

 

[Geshishouhu]

Just go through the function list in the Trigger Editor.
i.e.

function SetTextTagPosBJ takes texttag tt, location loc, real zOffset returns nothing
    call SetTextTagPos(tt, GetLocationX(loc), GetLocationY(loc), zOffset)
endfunction

and ofc you don't want to use locations.

native SetTextTagPos takes texttag t, real x, real y, real heightOffset returns nothing

or

function SetTextTagTextBJ takes texttag tt, string s, real size returns nothing
    local real textHeight = TextTagSize2Height(size)

    call SetTextTagText(tt, s, textHeight)
endfunction

is just

native SetTextTagText takes texttag t, string s, real height returns nothing

bj_lastCreatedTextTag --> local texttag text = CreateTextTag()

Thank you BPower. +Rep if I can.

 

[sethmachine]

What's wrong with using the BJ's?

 

[Adiktuz]

Well, basically, it's more efficient (performance wise) if there are less function calls... so since a BJ just calls another set of natives (+there are BJs that call a single native), it's better to just skip the BJ and use the natives themselves...

 

[PurgeandFire]

What's wrong with using the BJ's?

As Adiktuz said, but I'd like to add that there are certain BJ's which are useful. For example, TriggerRegisterAnyUnitEventBJ(), or the RMinBJ() and RMaxBJ() functions. Inlining everything is wasteful (it can increase the map size and lead to code bloat), but you should inline the BJ's that are simply swapped parameters from the original function. Just inline with a practical state of mind.

 

[sethmachine]

Well, basically, it's more efficient (performance wise) if there are less function calls... so since a BJ just calls another set of natives (+there are BJs that call a single native), it's better to just skip the BJ and use the natives themselves...

Wouldn't that make the code harder to read though?

I don't suppose vjASS could just do this automatically then when it translates it into the actual JASS script?

 

[deathismyfriend]

Wouldn't that make the code harder to read though?

Naa it is easier to read IMO.

I don't suppose vjASS could just do this automatically then when it translates it into the actual JASS script?

No it does not. It would be nice if it did though.

Also Another reason BJs aren't used is that some of them leak locals which is not acceptable in jass / vJass coding.

Most are just swapped versions of natives. Which makes no sense in why blizzard did such things when making GUI.

 

[TriggerHappy]

Most are just swapped versions of natives. Which makes no sense in why blizzard did such things when making GUI.

They did it so it could follow the flow of the description in the GUI editor.

Also, not all BJ's are useless as PurgeandFire already pointed out.

 

[deathismyfriend]

They did it so it could follow the flow of the description in the GUI editor.

Not really sure what you mean ?

Also, not all BJ's are useless as PurgeandFire already pointed out.

I know that. Never said all of them are useless just most. Very few are actually useful.

 

[Adiktuz]

yeah, it doesn't make sense to me because they could have just turned either the natives or the GUI flow in a way that they will not need those BJs right?

 

[deathismyfriend]

yeah, it doesn't make sense to me because they could have just turned either the natives or the GUI flow in a way that they will not need those BJs right?

Ya lol. I'm not sure what they were thinking.

 

[TriggerHappy]

The descriptions for GUI triggers, it needs to follow the flow of the sentence.

AddHeroXPSwapped="Add Experience"
AddHeroXPSwapped="Add ",~Quantity," experience to ",~Hero,", ",~Show/Hide," level-up graphics"

Sure they could have spent more time making it neat, however they decided to create swapped BJ's for this.

 

[Adiktuz]

I don't have any knowledge in building/implementing scripting support so this might be wrong, so correct me if it is... but isn't it easier if they just made the natives follow that flow? coz that way, they will only make 1 function instead of making 2 functions...

 

[Geshishouhu]

As Adiktuz said, but I'd like to add that there are certain BJ's which are useful. For example, TriggerRegisterAnyUnitEventBJ(), or the RMinBJ() and RMaxBJ() functions. Inlining everything is wasteful (it can increase the map size and lead to code bloat), but you should inline the BJ's that are simply swapped parameters from the original function. Just inline with a practical state of mind.

Thanks, PnF.

Edit:
Oh, didn't notice the continues discussion in this thread.
Thanks everyone.

 

[Wrda]

I don't think you need to replace all those BJs to natives, since they do all the work. I actually think those BJs are the useful ones too.

 

[Daffa]

I don't think you need to replace all those BJs to natives, since they do all the work. I actually think those BJs are the useful ones too.

As DIMF said, BJs leaks locals for most of time, that's unacceptable in Jass or Vjass coding, GUI coding is under exception of this however, because GUI uses BJ.