Snippet PeriodicDamage

[Flare]

Nono, I mean since he used 0.03, it is fine to use struct stack.

He used it in his latest post - again, nothing more than an example to justify why he made the system. How often will a normal damage-over-time spell tick every 0.03 seconds? That'd just be stupid.

Generally, damage-over-time stuff would tick once every 1 to 3 seconds, so a struct stack is a poor solution (since all the ticks for active DoT's would occur together, regardless of when the DoT's were actually started...

 

[Larcenist]

It isn't really hard to count ticks in order to make the damage occur every X seconds.

 

[Flare]

It isn't really hard to count ticks in order to make the damage occur every X seconds.

It is a tad unnecessary - why execute a timer 32 times a second (for anything up to 5 seconds, perhaps) when you could execute it only when necessary. 32-160 executions for the sake of 1 vital execution, or 1 vital execution and no unnecessary junk?

TimerUtils is just fine for this, and I don't see any reason to change it.

 

[Larcenist]

While I stated that it's fully possible and not hard at all, I never stated that it's to be prefered over what it currently is. The reason I brought up struct stacks to begin with was to state how unnecessary kingking's linked list suggestion really was.

 

[Jesus4Lyf]

Struct stacks should pretty much never be used as linked lists are faster (see T32) but granted, harder to understand. The exception is firing one instance of something more than once on the same period (which means you're doing it wrong xD). Oh, and the speed difference is one subtraction or something, so I wouldn't go approving resources based on whether or not they are optimised that tiny extra amount.

Using a low period to simulate a high period in the way you suggested, Larcenist, is generally likewise a poor choice. Sometimes I do it anyway, though.

TimerUtils is the right choice for this system.

 

[TriggerHappy]

Updated, all the UnitDamageTimed... functions now return the struct instance.

 

[TriggerHappy]

bump.

 

[GetTriggerUnit-]

You could add UnitDamagePointTimed, no?

 

[duckne55]

Umm forgive me but cant you do this easily with poison?

 

[GetTriggerUnit-]

It would be way easier with a periodic damage function..

 

[TriggerHappy]

Umm forgive me but cant you do this easily with poison?

Triggering is more dynamic.

 

[TriggerHappy]

Bump.

 

[GetTriggerUnit-]

UnitDamagePointTimed does not exist?

Why don't you create a new Handle type (with a struct) and use this in every function.
Wouldn't it be easier to use it this way?

Like

local PeriodicDamage pd = CreatePeriodicDamage(duration, instances, damage AT, DT, WT, etc...)

Then you apply it to a unit...

call UnitApplyPeriodicDamage(pd, GetTriggerUnit())

// Also

call DestroyPeriodicDamage(pd, GetTriggerUnit())

// etc...

 

[TriggerHappy]

Why don't you create a new Handle type (with a struct) and use this in every function.
Wouldn't it be easier to use it this way?

Check the system again.

Then you apply it to a unit...

One line is better than two.

 

[GetTriggerUnit-]

UnitDamagePointTimed!

 

[Jesus4Lyf]

create a new Handle type (with a struct)

I just want to make this one thing clear, sir.

Structs. Aren't. Handles.
Neither are they handle types.

In regards to this system, I don't think it's useful enough to approve.

What do other people think? Would anyone opt to use this?
All it seems to do to me is select your timer system for you, and write a few lines of JASS code thereafter.

Oh, and in your create function, remove the local thistype d and just use lastCreatedPeriodicDamage.
I'm pretty sure even BJs do that.

 

[TriggerHappy]

I've had a bunch of people at hive say this was useful.

 

[Jesus4Lyf]

I think it would be more useful if it could damage a point (with radius) over time. That may be approvable.

 

[TriggerHappy]

I think it would be more useful if it could damage a point (with radius) over time. That may be approvable.

I'm planning on doing that, since GetTriggerUnit- keeps hinting at it.

 

[GetTriggerUnit-]

O rly?

I still don't see it!!!! Long, long

Still waiting.