Wc3C.net

Wc3C.net (http://www.wc3c.net/forums.php)
-   Scripts (http://www.wc3c.net/forumdisplay.php?f=737)
-   -   DamageEvent & DamageModifiers (http://www.wc3c.net/showthread.php?t=108009)

Anitarf 11-03-2011 05:37 PM

I can't think of a case where I'd want to disable a response, so that feature seems useless to me. On the other hand, your implementation is missing the optional xedamage support of the original. I don't agree with these two changes.

As for other changes such as using AutoIndex, they don't change the functionality of the library so I don't mind. I don't see any advantage in implementing these changes in my version but I have nothing against them as an alternate flavour of the library.

By the way, you forgot the optional requirement(s) in the library declaration.

BBQ 11-03-2011 07:11 PM

Well, I agree that what I did was rather useless (by the way, I forgot about xedamage, didn't leave it out on purpose). The whole thing about disabling a given response was to prevent an infinite loop -- but that can be taken care of by the user rather easily by using a single boolean.

By the way, I don't see a point in interfacing with other damage detection engines. I kind of dislike IDDS -- it somehow encourages dynamic triggers, and the UnitDamageTargetEx() function is rather limited, because different kinds of attack type / damage type combinations have their own merits, something which that function doesn't allow for (for example, I might want to use DAMAGE_TYPE_ENHANCED, which is the damage type used by the hardcoded Cleaving Attack ability, but I won't be able to). As for LLDD, sure, its working principle may be the base for DamageEvent, but I fail to see anything else about it.

I firmly think that using this along with xedamage is the way to go -- without the need of using (or interfacing with) other damage detection engines.

On the other hand, I'd like to see DamageEvent being changed to use a trigger condition instead of an action (even though the speed difference is negligible, it has been proven that destroying a trigger without actions on it is rather safe -- so you can get rid of the "delay" as well). And why not use .evaluate() instead of .execute()?

Anitarf 11-04-2011 12:06 AM

Quote:

Originally Posted by BBQ
By the way, I don't see a point in interfacing with other damage detection engines.

There's not much point to it now. The point used to be to help this library gain acceptance back when those libraries were commonly used, I figured people wouldn't want to import DamageEvent if they were already using a different damage detection library.

Quote:

On the other hand, I'd like to see DamageEvent being changed to use a trigger condition instead of an action (even though the speed difference is negligible, it has been proven that destroying a trigger without actions on it is rather safe -- so you can get rid of the "delay" as well).
Well, I'm not so sure about trigger conditions being perfectly safe. I found an easy-to-reproduce example of handle stack corruption here and when I edited the code to use a trigger condition, the bug still occurred (since trigger conditions don't support waits, I had to move that part of the code to another function and run it with .execute).

Quote:

And why not use .evaluate() instead of .execute()?
I used .execute because I erroneously thought that .evaluate didn't protect the calling function from things like thread crashes in the called function. I guess I could change that to .evaluate now that I know better.

BBQ 11-04-2011 07:22 AM

Quote:

Originally Posted by Anitarf
Well, I'm not so sure about trigger conditions being perfectly safe. I found an easy-to-reproduce example of handle stack corruption here and when I edited the code to use a trigger condition, the bug still occurred (since trigger conditions don't support waits, I had to move that part of the code to another function and run it with .execute).

That's the whole point. Every possible way of causing the bug involves TriggerSleepAction() in it -- something you can't use within a trigger condition. Using .execute() means that you're still using trigger actions. Furthermore, I don't think that people still use TriggerSleepAction(). But I guess it's all up to you.

Anitarf 11-04-2011 09:41 AM

Quote:

Originally Posted by BBQ
That's the whole point. Every possible way of causing the bug involves TriggerSleepAction() in it -- something you can't use within a trigger condition. Using .execute() means that you're still using trigger actions. Furthermore, I don't think that people still use TriggerSleepAction(). But I guess it's all up to you.

Yes, but even if I switched to .evaluate users could still do an .execute in their own function and then use TriggerSleepAction. Of course, this is no argument against switching to trigger conditions, I could still do that since they're faster and all, but doing so won't prevent the possibility of handle stack corruption so I should keep the safety delay, even if it is unlikely that anyone who uses this will ever use TriggerSleepAction.

codart 11-14-2011 03:18 AM

Quote:

Originally Posted by Anitarf
I'm not sure what you mean. If you want to block damage with this system, you have to use a DamageModifier, it does not matter if you're doing it once or repeatedly. What exactly did you have in mind?

srr... my english isnt so good. another problem. let say i have 2 damagemodifier struct on a unit. the first multilpe the dam by 2 and the second try to block the damage. what is the code if i want the second alway block all the damage and ignore all other damage modifier instance?

Anitarf 11-17-2011 01:13 PM

Quote:

Originally Posted by codart
srr... my english isnt so good. another problem. let say i have 2 damagemodifier struct on a unit. the first multilpe the dam by 2 and the second try to block the damage. what is the code if i want the second alway block all the damage and ignore all other damage modifier instance?

To block all the damage, simply do this:
Collapse JASS:
    struct foo extends DamageModifier
        method onDamageTaken takes unit damageSource, real damage returns real
            return -damage
        endmethod
    endstruct

There's no way to automatically ignore all other damage modifiers, they will still run, but you can code them in such a way that they do nothing if the damage was already prevented:
Collapse JASS:
    struct bar extends DamageModifier
        method onDamageTaken takes unit damageSource, real damage returns real
            if damage<=0.0 then // If the damage was prevented...
                return 0.0      // ...then do nothing.
            endif
            // Do your stuff here.
        endmethod
    endstruct

Edit: I moved some off-topic posts to a new thread.

codart 11-18-2011 04:42 AM

damage modifier 1: piority 0;
damage modifier 2: piority 1;
Which one will be excute first?

PurgeandFire111 11-18-2011 05:27 AM

0 would execute first. It is ordered by priorities from least to greatest.

EDIT: @Anitarf: Whoops, sorry I think I misread. xD

Anitarf 11-18-2011 10:29 AM

Quote:

Originally Posted by PurgeandFire111
0 would execute first. It is ordered by priorities from least to greatest.

Incorrect.
Quote:

Originally Posted by DamageModifier documentation
The system always evaluates the modifiers on the unit dealing the damage and on the unit taking the damage simultaneously, starting with the modifiers with the highest priority.


muzk 02-01-2012 04:52 AM

Quote:

Originally Posted by Rising_Dusk
You really shouldn't do that.

Hey, what wrong with Negative Damage?

Anitarf 02-01-2012 08:01 AM

Quote:

Originally Posted by muzk
Hey, what wrong with Negative Damage?

It doesn't work?

Bribe 02-01-2012 08:42 AM

Yeah I tried healing with negative values with UnitDamageTarget before, it did 0 instead of healing.

muzk 02-02-2012 03:46 AM

I didn't know it x)
You can use AIrs to allow spells do negative damage.


All times are GMT. The time now is 11:13 AM.

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services