Snippet ExecuteSoon

[Jesus4Lyf]

You didn't mention TriggerEvaluate and TriggerClearConditions, the calling of stuct creating, and many set of variables, i hardly think that would be faster.

You must read the code more carefully. (Red, not blue.)

---

set Tim<i>=GetExpiredTimer()</i>

I think it unnecessary. This hardly needs to be recursive. <_< (In my opinion.) - (I will elaborate - the only thing this adds is being able to call start from within the callback. If this isn't done, the timers are fine as is, still in the array.)

>I still don't understand what you want mean, could you give an example plz ?
Instead of the single TriggerEvaluate (which is not one per instance, why I said read the code carefully) you could loop through calling the function directly, as it would always be the same function (like in Damage).

Any conclusions about the usefulness of this? Is execute soon used for anything else but damage blocking?

 

[Kenny]

Any conclusions about the usefulness of this? Is execute soon used for anything else but damage blocking?

It was pretty cool, and somewhat useful, before Damage came out. However, now I see little use in this snippet, sorry to say. But the idea behind it is still a useful one if people want to see how they can do something similar for themselves (instead of using a system to do it).

Even though it is well written, I will have to say +1 graveyard vote, just because there is now something better out there. But if someone can come up with a use for this, other than damage blocking, I may change my mind.

 

[Jesus4Lyf]

I completely agree. I'm going to graveyard this - even if another use was discovered, I'm sure someone would quickly write a system that handles it at a higher level anyway (like what happened with Damage, I guess).

 

[Troll-Brain]

You must read the code more carefully. (Red, not blue.)

---

set Tim<i>=GetExpiredTimer()</i>

I think it unnecessary. This hardly needs to be recursive. <_< (In my opinion.) - (I will elaborate - the only thing this adds is being able to call start from within the callback. If this isn't done, the timers are fine as is, still in the array.)

I wouldn't assume two timers with the same period which started in the same time would always finish in the order they were called.
But i will make a tress test about it, to be sure it will always work properly.
EDIT : Ok it works fine, code edited, i guess i've misunderstood something when someone reported a bug like that with timers.

Instead of the single TriggerEvaluate (which is not one per instance, why I said read the code carefully) you could loop through calling the function directly, as it would always be the same function (like in Damage).

I know, but again in a real world scenario how many of these timers will be running at the same time ?
I can't believe using one TriggerEvaluate would be more efficient than only few timers callbacks.
Meh i knew i should mentioned it before ...

Also could you highlight the code in Damage plz ?
Did i mentioned i don't like Damage because of struct arrays ? xD

Any conclusions about the usefulness of this? Is execute soon used for anything else but damage blocking?

Try to give a not target order when an order point event fire ?
Also like Builder Bob said, it's useful for item events, and i'm pretty sure it would have more events like these.

 

[Jesus4Lyf]

I wouldn't assume two timers with the same period which started in the same time would always finish in the order they were called.
But i will make a tress test about it, to be sure it will always work properly.
EDIT : Ok it works fine, code edited, i guess i've misunderstood something when someone reported a bug like that with timers.

Research is good. Thanks for testing that theory. I actually concluded that it didn't matter what order the timers were left in.

Also could you highlight the code in Damage plz ?

    private function RemoveBoostedTimerFunc takes nothing returns nothing
        loop
            exitwhen RemoveBoostedMax==0
            set BoostedLifeUnit=RemoveBoosted[RemoveBoostedMax]
            set BoostedLifeTemp=GetWidgetLife(BoostedLifeUnit)
            call UnitRemoveAbility(BoostedLifeUnit,LIFE_BONUS_ABIL)
            if BoostedLifeTemp>0.405 then
                call SetWidgetLife(BoostedLifeUnit,BoostedLifeTemp)
            endif
            set RemoveBoostedMax=RemoveBoostedMax-1
        endloop
    endfunction

That's the callback.

Did i mentioned i don't like Damage because of struct arrays ? xD

There's no array members in Damage... I'm not sure what you're talking about.

Try to give a not target order when an order point event fire ?
Also like Builder Bob said, it's useful for item events, and i'm pretty sure it would have more events like these.

Maybe you're right. Is it possible to use the "is IssueOrder then" bug to wait long enough in these circumstances? =/ Someone needs to look into this, I think. If not, I may approve this. The only other argument is should things like this just be hard coded like in Damage anyway. It's not hard...

 

[Troll-Brain]

Research is good. Thanks for testing that theory. I actually concluded that it didn't matter what order the timers were left in.

Yes.

There's no array members in Damage... I'm not sure what you're talking about.

You must use structs extends array with AIDS, and in the current state they are limited against structs which don't extends array.

Maybe you're right. Is it possible to use the "is IssueOrder then" bug to wait long enough in these circumstances? =/ Someone needs to look into this, I think. If not, I may approve this. The only other argument is should things like this just be hard coded like in Damage anyway. It's not hard...

I don't want a whole system just for doing theses kind of things, at least it's useful for me, i don't really try to convince you, i was just posting an alternative way that i've found, it's Builder Bob's thread anyway.

 

[Builder Bob]

I've just skimmed your comments, since I'm currently fairly inactive in map development.

Initially I only intended to write a short snippet to easily and efficiently run any code, virtually instantly, but after the triggering event had done it's work. After some forth and back with Jesus4Lyf, I changed some things necessary to make it flexible enough for public use. After those changes it became bigger, more inefficient (only blue flavor), and possibly made it graveyard fodder. The red flavor is still good, but comes with it's set of rules that I personally don't like when coding. I like to be able to forget all about what goes on inside the system and just use the functions intuitively.

I'd say this system has failed and I think it is correctly graveyarded. Someone who still wish to have this kind of functionality in the system section should create a snippet explaining how you can do this very easily for any type of event. Feel free to use everything, anything or nothing of my code.

Events which this can be useful are damage events, order events (if you want to issue a new order to a unit that triggers the order event), events where items change position in the inventory, mana events, etc.