Conditions vs. Action-ifs

[Matrixboy]

I'm sorry, I scoured the forums for the last twenty minutes (searching the word 'condition' gives quite a lot of solutions, believe it or not. =P), and was unable to find the answer to this. I may have overlooked it, or searched incorrectly, but... :/

Well, I've always been curious. I always thought skipping any extra function call would be good, so I would just have actions do the checks, however, doesn't that also make the code run more often, since the events are mostly generic? Would it be better to use conditions so it didn't bother reading the action all the time something happens?

I guess in easier terms, is it better to use Conditions, or skip them and just use an if() in the Actions?

EX:

function Trig_Selling_Actions takes nothing returns nothing
    local item checkItem = GetManipulatedItem()
    local integer x = 0
    local unit character = GetTriggerUnit()
    if (GetItemName(checkItem) == "Tournament Registration Forms") then 
        loop
            exitwhen x == 5
            if( GetItemName(UnitItemInSlot(character, x)) == "Tournament Registration Forms") then 
                call UnitDropItemTarget(character, checkItem, gg_unit_n00L_0150)
                endif
            set x = x+1
        endloop
    endif
        
endfunction

Would it be better for me to put that first If as a condition?

Also, I can't exactly find the trigger I was playing with before, but I was-- if I wanted to have two separate conditions to be filled?

function cond1 takes nothing returns boolean 
    if a == b then 
        return true
    else
        return false
    endif
endfunction

function cond2 takes nothing returns boolean
    if a != c then
        return true 
    else 
        return false
    endif
endfunction

function condcheck takes nothing returns boolean
    if And(cond1,cond2) == true then
        return true
    else
        return false
    endif
endfunction

function InitTrig takes nothing returns nothing
call  TriggerAddCondition(Trig, condcheck true)
endfunction

Or would it be better to nest the two parts of the condition like so?

function cond1 takes nothing returns boolean 
    if a == b then 
        if a != c then
            return true
        endif
    else
        return false
    endif
endfunction


function InitTrig takes nothing returns nothing
call  TriggerAddCondition(Trig, condcheck true)
endfunction

Sorry for the terrible writing of this question, but I'm not very good at explaining things. If anyone off-hand would know the answer to this, would you mind sharing? =)


Thanks in advance!


Travis.

 

[Dr.Jack]

Do excuse me if I'm wrong it has been a while since I dealt with Jass or vJass.
Anyway I believe the difference is not much of an importance. The upside with conditions is that if the condition is false it will terminate the action's execution and thus save you a function call. It is also considered more readable. With that If/Then/Else would be faster most of the time I believe (someone please verify).

Anyway it doesn't really matter unless you are executing tons of functions. Just do whatever you feel like.

 

[Zaraf]

function Cond takes nothing returns boolean
    return a == b and a != c
endfunction

That is all you need.

 

[Exide]

I always inline as much as possible.

Creating extra functions takes up a lot of space and makes it harder to read the code.
I'm not sure if it's more, less or equally effective, but I'm willing to risk it for the read-ability. (It's not like anyone's going to notice, anyway.)

Finally I would like to assume that inlining the conditions (not using a function) is more effective.

 

[T.s.e]

Conditions are more effective. But keep in mind that you cannot use any kind of wait within a condition-function.

 

[Azlier]

This isn't GUI, ya know. You can type any code wherever you want. You can put every action into the conditions to remove one function and gain some speed.

 

[jwallstone]

Yeah, writing everything together in either the condition or action does save function calls. I wonder if conditions might be slightly more lightweight than actions though, in that less functionality is enabled (TriggerSleepAction doesn't work in a condition, for instance, but you shouldn't really be using that anyway).

I think the only real reason to use both conditions and actions in Jass is for organization. It can help you keep things straight in your head. It also lets you reuse code. Always checking if the unit is hero? then write a condition and you don't worry about writing that into every function.

 

[Jesus4Lyf]

Put everything in the conditions and make the conditions return false (the last line should always be return false).

This is the most efficient and stable way to do things.

Use timers instead of TriggerSleepAction.

 

[jwallstone]

Agreed, timers are the way to do it.

For example, there's this particular timer system I've heard good things about...
http://www.thehelper.net/forums/showthread.php?t=78392

 

[Jesus4Lyf]

Mmhmm, ain't a bad one.

 

[Matrixboy]

function Cond takes nothing returns boolean
    return a == b and a != c
endfunction

That is all you need.

*smacks forehead* I forgot about doing it that method, just connecting them together.

I always inline as much as possible.

Same, I would always try and subtract the amount of function calls, despite code un-pretiness (why should it be easy to read if it's called code? )

Conditions are more effective. But keep in mind that you cannot use any kind of wait within a condition-function.

Am aware of not being able to use waits, but wasn't that _everything_ was quicker inside conditions. Thank you! Is there anything else that cannot be used in conditions other than TriggerSleepAction()?

This isn't GUI, ya know. You can type any code wherever you want. You can put every action into the conditions to remove one function and gain some speed.

Reason I was asking, since I have more control over my scripts, I'd want them to be as effecient as possible. Even if it's a not-noticable differerence, it makes me feel better.

Yeah, writing everything together in either the condition or action does save function calls. I wonder if conditions might be slightly more lightweight than actions though, in that less functionality is enabled (TriggerSleepAction doesn't work in a condition, for instance, but you shouldn't really be using that anyway).

That might be the reason! Since it uses less, or as Dr. Jack said

The upside with conditions is that if the condition is false it will terminate the action's execution and thus save you a function call.

That could be the reason too.

Put everything in the conditions and make the conditions return false (the last line should always be return false).

This is the most efficient and stable way to do things.

Use timers instead of TriggerSleepAction.

Now, I've seen that somewhere before, I asked for help with a small trigger I was making, and something acting as an action was being put in the condition, and it was giving off a false. Would you be able to explain why you return it as false? I always wondered that.

And thanks for the straight-forward answer

Also, I stopped using TriggerSleepAction after I noticed it didn't work very well (I forgot where it didn't work very well, but it really angered me =P), and started using TimerUtils. But, after reading your paper, I JUST MIGHT have to start using Key Timers 1 (or maybe 2, I need to look up the specific pros/cons of each)

Thanks for your help everyone!

 

[Jesus4Lyf]

>Now, I've seen that somewhere before, I asked for help with a small trigger I was making, and something acting as an action was being put in the condition, and it was giving off a false. Would you be able to explain why you return it as false? I always wondered that.

Trigger:
- Event
- Conditions
- Actions

If we put all the "actions" code into the conditions, and have the condition then return false, the real Actions (which will be blank) will never be run. Efficient.

>started using TimerUtils. But, after reading your paper, I JUST MIGHT have to start using Key Timers 1 (or maybe 2, I need to look up the specific pros/cons of each)

Key Timers 1 isn't publicly available as such... I'd just recommend Key Timers 2. Key Timers 2 is the best system without being hard to use for low periods, TimerUtils is better than KT2 for high periods (low and high being, lets say, <0.3 seconds is low, >0.3 seconds is high, so for spells where something is done several times a second you use KT2, but for waits and such TU is more efficient if you like).

Personally I just use KT2. Each to their own, see what you like. Both are valid.

 

[Troll-Brain]

Juts be aware that you can't do all things in a trigger condition like PauseGame.

 

[Matrixboy]

>Now, I've seen that somewhere before, I asked for help with a small trigger I was making, and something acting as an action was being put in the condition, and it was giving off a false. Would you be able to explain why you return it as false? I always wondered that.

Trigger:
- Event
- Conditions
- Actions

If we put all the "actions" code into the conditions, and have the condition then return false, the real Actions (which will be blank) will never be run. Efficient.

>started using TimerUtils. But, after reading your paper, I JUST MIGHT have to start using Key Timers 1 (or maybe 2, I need to look up the specific pros/cons of each)

Key Timers 1 isn't publicly available as such... I'd just recommend Key Timers 2. Key Timers 2 is the best system without being hard to use for low periods, TimerUtils is better than KT2 for high periods (low and high being, lets say, <0.3 seconds is low, >0.3 seconds is high, so for spells where something is done several times a second you use KT2, but for waits and such TU is more efficient if you like).

Personally I just use KT2. Each to their own, see what you like. Both are valid.

Ah, I get it. So it doesn't think of running any actions! Thank you for the explination.

And I'll then take a look at KeyTimers 2. I've been using TimerUtils for a while, but only because it was the first name I heard. I'll see whatever works better for me. Thanks