View Single Post
Old 10-24-2009, 07:02 PM   #21
Procrastination Incarnate

Development Director
Join Date: Feb 2004
Posts: 8,190

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner


Originally Posted by grim001
Would it be possible to only do this when you know the damage will be fatal?
I'd need to change how the core works. Right now, it doesn't care if the damage will be fatal at all, it just modifies the unit's life by the damage modifier and makes sure it remembers if there are any leftovers (since it can't set the life above the unit's maxlife or below 0.406 which would kill the unit), if another damage event occurs in response then those leftovers are carried over and added to the new event's modifier. It also keeps track of the total damage dealt, if that exceeds the unit's max life then the survival ability is added. This explanation is too long. it just makes sure the modifiers are applied to the unit's life correctly without killing the unit in the process. Actually tracking what the unit's life should be and whether the damage will kill it would be a lot more complicated and less robust. It probably is technically possible, but I really don't want to go down that road.

However, you can change the design a bit to get around this by calling RunDamageModifiers from within DamageModifiers using a function registered with any damage detection system. The only problem would be that the final modified damage value wouldn't be passed through to other events, however how can correct that for IDDS by using the SetDamage function it includes. LLDD relies on the native event responses, but you could make a function that returns the modified damage value.
That would be an uglier solution in my opinion. I want the modifiers to be distinct from the regular event responses, rather than just being another one of them, which brings me to your next point:

No, delegate can't be used for event handling....
Extends is not supposed to be used just to add events to units,...
Hey, I agree, but:
A damage modifier is not anything but a unit event that returns a value.
And has a priority. And the returned value modifies the damage. It's a lot more complicated than just a simple event listener; if you want that then use DamageEvent. I consider DamageModifier much more a part of an event than a response to it, and a more complicated object than a mere response, that's why responses are a function interface and modifiers are an interface.

Besides, there's no functional difference, it's just syntax. You could still easily write a wrapper library that would provide a modifyIncomingDamage module and a modifyOutgoingDamage module while using DamageModifiers internally.

Edit: Okay, I fixed up DamageEvent, now it's a single library. I still need to consider whether to join the two versions of DamageModifiers in a similar fashion, when I decide that I'll also fix up the other errors (ability preloading, objectmerger call, method names). Also, I removed the ADamage compatibility library, I'll post it in the ADamage thread instead once this gets approved and that gets graveyarded.
Anitarf is offline   Reply With Quote