Tutorial How To Convert To 1.24

[Sevion]

Done.

Left DoNothing in there but commented it out

There's still a chance it'll be in there. And if I'm off on one thing, someone'll screw up. I've had that happen before >_<

 

[Jesus4Lyf]

Much better. +rep.

 

[Sevion]

Teh lulz. I just posted a thank you on your VM

Nothing else to improve on?

 

[Steel]

DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!
DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!
DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!

if i == 1 then
    call KillUnit(u)
    return
else
    call PauseUnit(u)
endif

becomes

if i == 1 then
    call KillUnit(u)
    return
endif
call PauseUnit(u)

DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!
DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!
DO NOT DO THIS. THIS IS CATASTROPHICALLY WRONG!!!
quraji pointed this out too...change your initial post.


You're saying if you had...

function test takes nothing returns nothing
local unit u = GetTriggerUnit()
local boolean killunit = true

if killunit then
call KillUnit(u)
else
call ReviveUnit(u)
endif

...that would translate to....

function test takes nothing returns nothing
local unit u = GetTriggerUnit()
local boolean killunit = true

if killunit then
call KillUnit(u)
endif
call ReviveUnit(u)

Yea ok, kill the unit then immediately after we exit the if statement, revive it regardless of a boolean check. NO.

 

[Sevion]

Whoops. I removed that part >_<. Sec, let me fix it.

I had it in there. But removed it on accident.

Edit: I believe I've fixed it, hopefully to your satisfaction.

 

[Jesus4Lyf]

>But wait, what about the part of else(if)'s that does something only if the first statement is false?

The example above and below this line are useless as they do not feature return statements in if statements, which is the only bug there is in the first place.

In fact, returning nothing doesn't bug, I believe. Only when the function returns a value of some sort does any of this apply at all...

In the example above that line, the return is at the end so it is not a problem. In the example below, there are no returns at all. An "else" statement should be used.

The rule of thumb is right: "If you use return in an if, follow it immediately with an endif. Anything after endif is else anyhow."

Please let your examples reflect it.

 

[Sevion]

The example above goes with the line above the example:

Another way of fixing this is having a local variable of return type then in the if/then/else instead of returning, you can set the local to the value to be returned then returning that after all your stuff.

Tip from Renendaru.

Second one, will fix.

I think I understood what you were going at, so I've edited it. Please correct me if I'm wrong.

 

[Ouguiya]

Great

Aboluto-friggin great.

A good manual, totally foolproof. Even I think I can get my map working now

One last question: Is this now completely working and not messing up anything?

Thanks in advance.

Yours,

Ouguiya

 

[Troll-Brain]

You may want to know there is a new jasshelper version, which fix the false return positive with an extra function call, as a temp fix, if blizzard doesn't fix it the (soon ...) next patch, he will handle better theses cases.

 

[Crusher]

This is a really nice tutorial.

+rep.

 

[waaaks!]

return 0.
call DoNothing()
return 1.

in this code, does vex's wc3 optimizer removes the call DoNothing() line?

function test takes nothing returns nothing
local unit u = GetTriggerUnit()
local boolean killunit = true

if killunit then
call KillUnit(u)
endif
call ReviveUnit(u)

I don't get this, in the first example, if killunit is true, the unit will be killed and never be revived, but in this translated code (to be compatible with 1.24), killunit is true, which kills the unit, but after the if statement, it revives the unit again, do I really need to follow that? while there are some cases like this (or I don't know if they are the same):

function act takes nothing returns nothing
local unit c = GetAttacker()
local unit t = GetAttackedUnit()
if GetWidgetLife(t) < 500 then
call KillUnit(t)
else
call UnitDamageTarget(c,t,200,true,false,ATTACK_TYPE_NORMAL,DAMAGE_TYPE_NORMAL,null)
endif

"If you use return in an if, follow it immediately with an endif. Anything after endif is else anyhow."

so only for if statements with returns? then how about this?:

function test takes nothing returns nothing
local unit u = GetTriggerUnit()
local boolean killunit = true

if killunit then
call KillUnit(u)
endif
call ReviveUnit(u)

 

[Joker(Div)]

New JassHelper has a temporary work-around for the false-positives.

 

[Tyrande_ma3x]

And reports for return bugs so you can trace and remove them. I think you should suggest getting the latest jasshelper so people can quickly spot their mistakes if they don't know where they are. Of course the bug with the false positives still remains as long as there is no jasshelper enabled but it's a fine option for now... I hope 1.24b fixes that.
(God, people are fixing the game company's bugs instead of the employers... :/ )

 

[UndeadDragon]

if i == 1 then
    call KillUnit(u)
    return x
else
    call PauseUnit(u)
endif

becomes

if i == 1 then
    call KillUnit(u)
    return x
endif
call PauseUnit(u)

That is not the same, because if "i==1", it will do KillUnit(u), return x and PauseUnit(u), whereas the first one did either "KillUnit(u) and return x" or "PauseUnit(u)".

 

[Rainther]

Um... return ignores the rest of the function (which means it won't pause). So those 2 is the same deal, really.

 

[Steel]

You people aren't following this properly. Read my post again, it quotes Sevion's original message. Sevion has since changed the original post to reflect what I pointed out.

 

[Sevion]

>New JassHelper

Mine broke '

I kept getting I/O error 105 whenever I save. I've been since using the version before. 9.0.I.0 or whatever.

>Inlining DoNothing

Not sure. :-/ Someone ought to test that.

>People who commented before reading the entire tutorial (as in all words included in the tutorial...)

Please, stop doing that -_-'

 

[quraji]

Just to clarify for people about the if statements.

You only need to edit your if statements if the return keyword is inside:

if (u == null) then
    return false
else
    call KillUnit(u)
    return true
endif

You would change the above to:

if (u == null) then
    return false
endif
call KillUnit(u)
return true

Remember that the function ends whenever it hits the return keyword! Thus, anything after the endif is essentially an else.

If you find this confusing, you can use a variable to store your return value:

if (u == null) then
    return false
endif
call KillUnit(u)
return true

becomes:

if (u == null) then
    set b = false
else
    call KillUnit(u)
    set b = true
endif
return b

 

[Sevion]

>quraji

Quoted and linked into main post.

 

[13lade619]

umm.. dont forget about inlined if's with returns within other stuff like loops and such..

because i saw a few of those in some systems i recoded.