[JASS] Non Understood Syntax :P

[CrueIIntentions]

Ive been trying to figure this out for a little while now, while I know this is kinda getting redundant, I'm really not sure why this syntaxed.

    local unit u = GetTriggerUnit()
    local player p = GetOwningPlayer(u)
    local group g = CreateGroup()
    local real array x
    local real array y
    local location array t
    set x [0] = (GetRandomReal(GetRectMinX(gg_rct_Start_2), GetRectMaxX(gg_rct_Start_2)))
    set x [1] = (GetRandomReal(GetRectMinX(gg_rct_End_2), GetRectMaxX(gg_rct_End_2)))
    set y [0] = (GetRandomReal(GetRectMinY(gg_rct_Start_2), GetRectMaxY(gg_rct_Start_2)))
    set y [1] = (GetRandomReal(GetRectMinY(gg_rct_End_2), GetRectMaxY(gg_rct_End_2)))
    set t [0] = Location(x[0],y[0])
    set t [1] = Location(x[1],y[1])
    if udg_Lives[GetPlayerId(Player(1))] > 0 then
        if p != Player(1) then
            call SetUnitPositionLoc(u, t[0])
            IssuePointOrderLoc( u, "move" , t[1])//<<<<My Syntax (My Location Syntaxed)
        elseif p == Player(1) then
            call SetUnitPositionLoc(u, t [1])
        endif
    endif

I have not posted the entire trigger, due to the fact that the syntax has already appeared. The variables have been nullified.

Another question : It was said that reals dont leak. Does that include coordinates for Rects?

 

[watermelon_1234]

You forgot call. =P

Also, If I were you, I would not use locations since reals are faster.
Reals wouldn't leak for coordinates of rects.

 

[CrueIIntentions]

so if I used:

 CALL IssuePointOrderLoc( u, "move" , Location (x,y))

Would be faster and would not leak a location?

 

[watermelon_1234]

so if I used:

 CALL IssuePointOrderLoc( u, "move" , Location (x,y))

Would be faster and would not leak a location?

Oh no, that would cause a leak because Location creates a location.

Do this:

call IssuePointOrder(u,"move",x,y)

Similarly

call SetUnitPosition(u,x,y)

or even SetUnitX/SetUnitY though that's slightly different since it ignores unit pathing.

 

[CrueIIntentions]

Your the best! Thanks alot! +rep

 

[Axarion]

You should not use arrays as locals just use 2 variables instead.

 

[Bribe]

Yeah, in the scale of vJass, there is 99% of the time no need for local arrays. I find that GUI users like to make a location array so that they don't need to keep making new ones.

Which... is fine for GUI.. but terrible when you consider the consequences in performance.

 

[Adiktuz]

so if I used:

 CALL IssuePointOrderLoc( u, "move" , Location (x,y))

Would be faster and would not leak a location?

well first of all you need the call otherwise it will have syntax error...

 

[Axarion]

Yeah, in the scale of vJass, there is 99% of the time no need for local arrays. I find that GUI users like to make a location array so that they don't need to keep making new ones.

Which... is fine for GUI.. but terrible when you consider the consequences in performance.

Well GUI and performance are two different worlds

 

[Anachron]

Tell me one situation in which you should use local arrays, since global arrays make more sense and are faster?

 

[Mechanical Man]

To create less mess in variable editor and easier to import in case you forgot some variables. Also is better order having only local variables if used only once in that trigger.

 

[Anachron]

Who uses the variable editor nowadays?

 

[Bribe]

Local array has a use in Anitarf's Cinematic System. He uses like 27 real variables locally, so instead of declaring a whole mess at the top he just has that.

 

[dardas]

well, its a much bigger mess with locals.. i guess its shorter,
but i still find it a mess..

 

[PurplePoot]

Or if you want to do, say, sorting, although that isn't as relevant in a language like JASS.

That said, arrays are not a very significant performance hit but they are certainly bad form from a readability perspective when you are just using them instead of two or more independent variables. If you aren't at least sometimes accessing an array element with a non-constant index then you shouldn't be using an array.