System Damage Struct

[Dirac]

Why you should use this above Damage? Ok a few reasons.
-Instead of coding a bunch of checks in order to know whether you would like to register and change some unit's damage (because of a damage modification ability or something similar) You can just enable the damage recognition for the unit using this system, then disable it after using timers (If approved i'll fix the issue that doesn't let you disable it during damage event firing)
-The event responses variables are now globals and you no longer need to declare them each function as a local. (Damage.dealt, Damage.source, etc.)
-Damage by J4L bugs when trying to prevent AoE damage. (Or any kind of damage done simultaneously
-You don't have to declare triggers in order for the system to function (i really hate this about J4L's damage)
-This (similar to Nestharus's damage library) cleans up the leaks generated by events after a certain amount of units are removed or deindexed. Otherwise unused events would stack and stack over the trigger.

-Gives you the extremely useful DamageMod extension if needed.
-Allows you to retrieve unit armor and unit armor reduction
-Gives you the useful custom DamageType extension if needed.
-Keeps recount of all damage given by all sources or by specific sources (should be an extension)
-Allows you to perfectly attach data to unit damage events, this way you can easily access your ability's instance through damage detection

Fixed the documentation.

 

[GFreak45]

This resource needs to be modular.
GetUnitArmor can be it's own resource.

i think he means that armor is the only module that you have implemented in the core, and that you should have that as optional as well, idk i might disagree with him but just depends on the situation

 

[Dirac]

Yea the GetUnitArmor function only adds a few lines of text to the system, it would harm to take it away. And i can't submit it for people who don't want to use this damage system because it has to disable the current damage system their map has, and use the custom ability life bonus their map has, if they want a function like that they might as well code it themselves.

@Mag
You do realize that the UnitIndexStruct module does the same thing i'm doing here? It registers functions to the INDEX and DEINDEX events of the trigger, no need to implement it, plus it would make compability with AIDS much harder.

@tooltiperror
I know what you mean when you say i'm reinventing the wheel, why should you approve this resource? So happens that you run on a bad wheel, J4L's damage system isn't completely safe to use, has lots of unnecessary coding, lacks of tools this system (even without the extensions) has, bugs with damage prevention when damage is done simultaneously, LEAKS events on triggers, and it's considerably slower. I'm inclined to think that it was approved because there was no other resource that would do the same thing. After that Nes came out with his DamageEvent library, which was J4L's with all the bug fixed but lacking of tools. I find this the ultimate Damage library with everything the user needs, and if it needs even more there are extensions to it.
I haven't been able to come with a new update because honestly i find nothing to fix / tweak. However i'm extremely open on developing new extensions for it.

 

[Switch33]

You could make a damage over time module- for when an damage type like poison or fire does damage over time.

Also if your gonna keep the armor system in then at least do the fix for ethereal units(that i talk'd about with GFreak45 a few posts back). It'd make more sense if it work'd for even ethereal units since I can't think of any reason anyone would need to re-code that part then.

 

[Magthridon96]

You do realize that the UnitIndexStruct module does the same thing i'm doing here? It registers functions to the INDEX and DEINDEX events of the trigger, no need to implement it, plus it would make compability with AIDS much harder.

I know, but implementing the UnitIndexStruct would make your code look shorter.

Modularity is very important. By combining your GetUnitArmor function with something totally unrelated (Damage detection), you've made this resource un-modular.
Who would expect to find a GetUnitArmor function in a damage detection library?
It's like adding timer recycling inside a Spell struct.

All you have to do is make another library called GetUnitArmor and place your function there :3

 

[Dirac]

Ok i'll try to fix the modularity regarding the armor part, but the new "Armor" library would require this library.

ethereal may not be attainable with chaos, but it only takes one damage type and that damage type isnt reduced by armor, so how do you get the armor of a unit without the armor having any effect at all?

Not entirely true, i've been testing ethereal damage done to units and armor DOES affect their spell damage taken (though they only take spell damage, any other type of damage is prevented) and i came up with a solution to fix it, now there's an accurate way to detect ethereal armor without having to specify the unit's amor is ethereal.

EDIT:
v2.0.1
-Removed the GetUnitArmor and GetUnitDamageReduction as they now have their own resource "Armor"

 

[Laiev]

Dirac, I suggest you round up the the returned value of [ljass]GetUnitArmor(u)[/ljass], because is what Warcraft do.

While I'm with 235 armor (value by Warcraft), your function return 234.906.

When I active your ability (+100 armor) we got 235 + 100 (value by Warcraft), while your function return 334.211 (my DisplayFunction is inside the AgilityShield, so we have 2 inaccuracy value here)

I did a little function to test if my theory is right, and, in fact, it is ^_^

function RoundUp takes real r returns real
    return R2I(r + 0.5) + 0.
endfunction

This little stupid function fix the inaccuracy value of [ljass]GetUnitArmor[/ljass], but I don't know how it'll work on negative armor :/

 

[Dirac]

I can't round up armor, it would bug hero armor increased by bonus agility (which gives armor with decimal values).
The fact that the armor returned isn't completely accurate isn't really my fault, there's nothing i can do about it.
Negative armor has the same issue and the maximum negative armor the unit can have is -20 (if the unit has -40 it would increment damage taken as it had -20)

 

[Laiev]

How this can bug the armor increased by bonus agility, since it's just rounded when you get the final value?

Like this:

function RoundUp takes real r returns real
    return R2I(r + 0.5) + 0.
endfunction

function GetUnitArmor takes unit whichUnit returns real
    local real reduction=GetUnitDamageReduction(whichUnit,ATTACK_TYPE_CHAOS,DAMAGE_TYPE_NORMAL)
    
    //*********************************************************************
    //  (armor)*0.06/(1+armor*0.06) = reduction
    if 0==reduction then
       set reduction=GetUnitDamageReduction(whichUnit,ATTACK_TYPE_MAGIC,DAMAGE_TYPE_NORMAL)
       return RoundUp(((1-reduction)/(ARMOR_REDUCTION*(reduction)))/ETHEREAL_ARMOR_REDUCTION) //there's nothing interfering the math
    endif
    if reduction<=1 then
        return RoundUp((1-reduction)/(ARMOR_REDUCTION*(reduction))) //neither here
    endif
    
    //*********************************************************************
    //  Ln of 0.94, w3's magic number for negative armor.
    return -(Ln(2-reduction)/-0.061875)
endfunction

or you could do this

function RoundUp takes real r returns real
    return R2I(r + 0.5) + 0.
endfunction

function GetUnitArmor takes unit whichUnit returns real
    local real reduction=GetUnitDamageReduction(whichUnit,ATTACK_TYPE_CHAOS,DAMAGE_TYPE_NORMAL)
    
    //*********************************************************************
    //  (armor)*0.06/(1+armor*0.06) = reduction
    if 0==reduction then
       set reduction=GetUnitDamageReduction(whichUnit,ATTACK_TYPE_MAGIC,DAMAGE_TYPE_NORMAL)
       return ((1-reduction)/(ARMOR_REDUCTION*(reduction)))/ETHEREAL_ARMOR_REDUCTION
    endif
    if reduction<=1 then
        return (1-reduction)/(ARMOR_REDUCTION*(reduction))
    endif
    
    //*********************************************************************
    //  Ln of 0.94, w3's magic number for negative armor.
    return -(Ln(2-reduction)/-0.061875)
endfunction
function GetUnitArmorEx takes unit whichUnit returns real
    return RoundUp(GetUnitArmor(whichUnit))
endfunction

PS: sorry for post this here instead of Armor thread... I first post that looking at the demomap :/ anyway...

 

[Dirac]

This belongs in the actual Armor resource thread but w/e.

If the unit has 5 armor it returns 5.3, if rounded up would return 6, when 5 was the armor
If the unit has 235 armor it returns 234.9 if rounded up would return 235

No way around it, the function just isn't accurate and there's no way to fix it.

 

[Laiev]

>>If the unit has 5 armor it returns 5.3, if rounded up would return 6, when 5 was the armor

Wrong >.>

If unit has 5 armor, and if it returns 5.3, if rounded up, would return 5, because it's not rounded up 100%, it just rounded if armor .XX > 50

[ljass]return R2I(real + 0.5)[/ljass] R2I don't round things

 

[GFreak45]

pretty sure even if it isnt accurate, you could just convert it to a substring using that digit (just after the decimal) and call another function taking that number and returning a true or false where if its 5+ it returns true if not it returns false, and if its false chop off the digits after the decimal, otherwise, do that and add 1 to it

 

[Dirac]

pretty sure even if it isnt accurate, you could just convert it to a substring using that digit (just after the decimal) and call another function taking that number and returning a true or false where if its 5+ it returns true if not it returns false, and if its false chop off the digits after the decimal, otherwise, do that and add 1 to it

Why on earth would you do that, didn't you see Laiev's function?
That's by far the weirdest and more over complicated method you can use to round up a number.

Remember this:
[ljass]R2I[/ljass] takes away the decimal part of a number, if the number was 9.7 it would return 9
If the number is 9.7 and you add 0.5 to it it would look like this
[ljass]R2I(9.7+0.5) = 10[/ljass]
So because the number's decimal part was above 0.5 now it's rounded up to 10.
[ljass]R2I(9.2+0.5) = 9[/ljass]
Now the number was below 0.5 and returns 9

 

[GFreak45]

hmmm derp i didnt, i thought you were saying he was using a defualt rounding function rather than that

 

[Dirac]

Updated to 2.0.5
-Instead of Alloc it now uses LinkedListModule
-Removed the Overkill and Overheal constants and fixed issues related to them
-Changed the philosophy on how the "dealt" variable works (it takes into account prevented damage and can't go below 0)
-Added support for the DamageId extension

 

[Sevion]

Confused as to how you find that 5.3 will round to 6.

function RoundUp takes real r returns real
    return R2I(r + 0.5) + 0.
endfunction

[ljass]R2I(5.8)+0.[/ljass] will return 5.

 

[Dirac]

It was a brief confusion moment for me, i'll fix it soon.

 

[Switch33]

This needs an update. It broke compatibility with latest LinkedListModule.

 

[Dirac]

You're right, the reason i haven't updated it is because i was working on some updates and the version that works with LinkedList is ready, thus i was working on maybe adding Advent as a requirement
Anyways now it works with linked list module properly.

 

[Magthridon96]

edit
Nevermind.