GetUnitArmor

[Malhorne]

Hi everyone,

library GetUnitArmor initializer init
/****************************************************************************************************************
*           ~How to configure
*               - Copy the ability
*
*           ~How to use
*               - call GetUnitArmor(unit)
****************************************************************************************************************/

    globals
        //The ID of the item
        private constant integer ITEM_ID = 'A000'
        //Half the amount of life the ability adds to allow for both positive and negative damage
        private constant integer ITEM_STRENGTH = 50000
        //The armor constant on gameplay constant
        private constant real ARMOR_CONSTANT = 0.06
        //The factor for Ethereal and Magic Damage
        private constant real ETHEREAL_FACTOR = 1.66
        //The test value, the higher the more precise (too big can bug and instant kill on negative armor unit)
        private constant real TEST_VALUE = 1000.
    endglobals
    
    globals
        private constant real E = 2.718282
        private constant real INV_E = 1/E
        //Cache for the Ln armor constant used to compute negative armor.
        private real ARMOR_NEGATIVE_LNCACHE
    endglobals
    
    //Thanks to looking_for_help !
    private function internLn takes real r returns real
        local real sum = 0.0
        local real sign = 1.0
        if r < 1.0 then
            set r = 1.0/r
            set sign = -1.0
        endif
        loop
            exitwhen r < E
            set r = r*INV_E
            set sum = sum + 1.0
        endloop
        loop
            exitwhen r < 1.2840254
            set r = r*0.778808
            set sum = sum + 0.25
        endloop

        return sign*(sum + 0.125*(r - 1.0)*(1 + 9.0/(2.0 + r) + 4.5/(0.5 + r) + 1.0/r))
    endfunction
        
    function GetUnitArmor takes unit u returns real
        local real lold
        local real llost
        local real mul = 1
        
        set lold = GetWidgetLife(u)
        call UnitAddAbility(u, ITEM_ID)
        call SetWidgetLife(u, ITEM_STRENGTH)
        
        if (IsUnitType(u, UNIT_TYPE_ETHEREAL)) then
            call UnitDamageTarget(u, u, TEST_VALUE, true, false, ATTACK_TYPE_MAGIC, DAMAGE_TYPE_NORMAL, null)
            set mul = ETHEREAL_FACTOR
        else
            call UnitDamageTarget(u, u, TEST_VALUE, true, false, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_NORMAL, null)
        endif
        
        set llost = (ITEM_STRENGTH - GetWidgetLife(u))/mul
        
        // apply armor type and damage type corrections here
        call UnitRemoveAbility(u, ITEM_ID)
        call SetWidgetLife(u,lold)

        if llost > TEST_VALUE then
            return -internLn(2 - llost / TEST_VALUE) / ARMOR_NEGATIVE_LNCACHE
        endif
        return (TEST_VALUE - llost) / (ARMOR_CONSTANT * llost)
    endfunction
    
    
    private function init takes nothing returns nothing
        //Generate cache
        set ARMOR_NEGATIVE_LNCACHE = internLn(1 - ARMOR_CONSTANT)
    endfunction
endlibrary

 

[Cokemonkey11]

Why don't you make the dummy unit a global singleton?

 

[Malhorne]

Why do you mean ?
I need the armor_constant too
I'll do

 

[Nestharus]

http://www.hiveworkshop.com/forums/...type-v8-225031/?prev=search=armor&d=list&r=20

already exists

 

[edo494]

will this even give correct values? because afaik, for negative armor you need Logarithm, and also negative armor will always use 0.06 no matter what constant you use ingame

 

[PurgeandFire]

Also, if the unit has less than 10 hp he'll de.

 

[Daffa]

Basically it does detect the armor, but what about reducing armor after detection, would that need BonusMod?

 

[Malhorne]

Ah yes it already exists. OK so you can gy this if this exists already.

Btw, it works if it was the question.

@Purge : Correcting to make it survive ^^

@Everybody : Nevermind just gy this the one Nestharus linked is better.
I just posted it because I often see people asking how and I didn't know thiis resource.

 

[Magtheridon96]

To be honest, that thing in the Spells section is the reason I cry at night.

It was so tedious to moderate and write reviews for.

 

[gorillabull]

To be honest, that thing in the Spells section is the reason I cry at night.

It was so tedious to moderate and write reviews for.

^^

i see no reason why you shouldnt make a vjass version although thats the only thing that could be updated i think

 

[Malhorne]

Oh if you think it worth a try for me to do this here wait untill I completely rewrite it ^^

 

[TriggerHappy]

Sending to graveyard with authors permission.

 

[looking_for_help]

Un-GY'ed on author request.

I'm curious about the new update.

 

[Malhorne]

Updated.

Made it work. Use an ability to add max life to prevent the death of the unit tested.
More concise code.
Added an attached map.

 

[Ezekiel12]

You might want to add that this can fail a thousand different ways, returning a wrong value and making it a potential danger for everyone using it.

 

[looking_for_help]

Updated.

So, tbh I don't really see the big change in this resource? Especially since this was already GYed, the improvements should be significant.

I didn't find this function so I submit it there

Nestharus already posted one, right? GetUnitArmorType v8.

I see several heavy problems here, especially that even in your testmap this system doesn't deliver correct results: Blood Mage has 2 armor, your system says 2.2, Paladin 4 vs 3.9 and Mountain King 51 vs 51.3. So the system fails even in the testmap under ideal conditions already.

Furthermore:

• It will potentially break DDS and at least trigger "wrong" damage events
• It is armor table dependent and not configurable to at least work around that point
• It won't work on invulnerable units
• It will break if someone modifies the units life in an onDamage handler
• Calling GetUnitArmor in an onDamage handler will cause an infinite recursion and therefore crash the thread
• It won't work with ethereal units

So, there has to be done a lot more work before this might get approved eventually...

 

[Malhorne]

The link you posted shares the problem with this ressource but you're right about it being better than mine ^^'.
By the way, it was GYed because I didn't want to work on it one year ago.
And actually the 2.2, 3.9 and 51.3 are the REAL values.
In the Gameplay Constants screen I attacked you can see that every Agility point add 0.3 armor. You can also see that there is -2 armor before applying Agility armor bonus.
Now we go to the Object Editor.
Paladin has 2 base defense and 13 agility points = 2 + 13*.3 - 2 = 2 + 3.9 -2 = 3.9 !
Blood Mage has 0 base defense and 14 agility points = 0 + 14*.3 - 2 = 2.2 !
Mountain King has 50 base defense and 11 agility points = 50 + 11*.3 - 2 = 51.3!
So the values are the good ones.

But since the link his better you can gy this again sorry for the disappointment and the time loss.

EDIT : Lol mine doesn't work for negative values.
I lost the formula ahah. Definitely worth to be GY a second time.

 

[edo494]

I was about to ask, specifically, how you imagine the formula to work? You need the logarithm to compute armor from negative value

 

[Malhorne]

I had one which worked :s

 

[edo494]

the current ones for sure dont work.

Lets say Unit has 6000 life and -5 armor, which is -26% reduction, you store 6000 inside life, hit it for 1000, store life2 as 6000 - 4733.900[6000 - 1000*1.26] which is 1266.1 when you round it.

Now since life2 is bigger than 1000, you compute (-(1000-1266.1))/(1266.1*0.06) which computes to 3.05, which is very far from -5.

You need logarithm, because you need to reverse power function, and inverse to power is log

 

[Malhorne]

Yeah I understand why you need it don't worry.
But I had one which came close.
Anyway this topic is lost ^^'

 

[Ruke]

Yeah I understand why you need it don't worry.
But I had one which came close.
Anyway this topic is lost ^^'

dont let it die . i encourage you to fix it

 

[Laiev]

dont let it die . i encourage you to fix it

We do

Really hoping to see a updated version of GetUnitArmor

 

[Malhorne]

Whoooo thanks for the support!
There is a link http://www.hiveworkshop.com/forums/...type-v8-225031/?prev=search=armor&d=list&r=20 which works (I assume it does).

 

[looking_for_help]

The link you posted shares the problem with this ressource

Thats right, but that doesn't mean you can't do better, right?

The resource from the link is also from the spell section, where different rules apply compared to the Jass section. Since the spell section is more about specific spells/systems, its ok there that the system is not 100% adaptable to all maps. In the Jass section however, this is quite important.

but you're right about it being better than mine ^^'.

Then improve yours until it is better than this system.

And actually the 2.2, 3.9 and 51.3 are the REAL values.
...
So the values are the good ones.

Alright, thats nice then, my fault.

But since the link his better you can gy this again sorry for the disappointment and the time loss.

I'm not disappointed

Its just a list of things that have to be improved, it doesn't mean the system has no potential in general. From the last posts you can see that there is an interest in the community for such a system, so it makes totally sense to keep updating it.

 

[edo494]

the v8 thing is not recursive safe, if you happen to fire it inside damage detection system callback, it will hang, much like yours.

 

[Dr Super Good]

You should really test stuff more. The health restoration logic is completely wrong and will full heal units. Additionally it will probably still kill units at low life since I recall the item ability retaining the same relative life when added (so If you had 1 HP before you will likely have less than 1,000 after).

I am working on a fixed version, but it may take some time (stupid lack of ln in JASS).

EDIT: Here.

library GetUnitArmor initializer init
/****************************************************************************************************************
*           ~How to configure
*               - Copy the ability
*
*           ~How to use
*               - call GetUnitArmor(unit)
****************************************************************************************************************/

    globals
        //The ID of the item
        private constant integer ITEM_ID = 'A000'
        //Half the amount of life the ability adds to allow for both positive and negative damage
        private constant integer ITEM_STRENGTH = 50000
        //The armor constant on gameplay constant
        private constant real ARMOR_CONSTANT = 0.06
        //The test value, the higher the more precise (too big can bug and instant kill on negative armor unit)
        private constant real TEST_VALUE = 1000.
        //Constants required for Ln approximation.
        private constant real LN2 = 0.69315
        private constant real LN_PRECSION_M = 9
        private constant real LN_CONVERGE = 0.0001
        //Cache for the Ln armor constant used to compute negative armor.
        private real ARMOR_NEAGITVE_LNCACHE
    endglobals
    
    //Function which approximates the natural log function. Required for negative armor computation.
    private function LnAprox takes real x returns real
        local real gx = 1
        local real gy = Pow(2, 2 - LN_PRECSION_M) / x
        local real tempr //Temporary storage real.
        loop
            set tempr = (gx + gy) / 2 
            set gy = SquareRoot(gx * gy) //Geometric mean.
            set gx = tempr //Arithmetic mean.
            
            //Check M convergence.
            set tempr = gx - gy
            exitwhen tempr <= LN_CONVERGE and tempr >= -LN_CONVERGE
        endloop
        //Compute and return the approximation.
        return bj_PI / (2 * gx) - LN_PRECSION_M * LN2
    endfunction
    
    function GetUnitArmor takes unit u returns real
        local real lold
        local real llost
        set lold = GetWidgetLife(u)
        call UnitAddAbility(u, ITEM_ID)
        call SetWidgetLife(u, ITEM_STRENGTH)
        call UnitDamageTarget(u, u, TEST_VALUE, true, false, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_NORMAL, null)
        set llost = ITEM_STRENGTH - GetWidgetLife(u)
        // apply armor type and damage type corrections here.
        call UnitRemoveAbility(u, ITEM_ID)
        call SetWidgetLife(u,lold)
        if llost > TEST_VALUE then
            return -LnAprox(2 - llost / TEST_VALUE) / ARMOR_NEAGITVE_LNCACHE
        endif
        return (TEST_VALUE - llost) / (ARMOR_CONSTANT * llost)
    endfunction
    
    private function init takes nothing returns nothing
        //Generate cache
        set ARMOR_NEAGITVE_LNCACHE = LnAprox(1 - ARMOR_CONSTANT)
    endfunction
endlibrary

It does not alter unit current life and also does support negative armor. With negative armor the calculation is only an approximation so there will be some error (less than 0.1). This error could be corrected with some kind of rounding function if desired.

Also do note that the minimum effective armor a unit can have is -20. Below that amount there is no alteration to damage reduction. Hence the minimum armor the system can detect is -20. Even though units can have below -20 armor it still acts as if it was -20.

 

[Malhorne]

Holy Moose!
Such support.
Thanks guys and specifically DSG !

Furthermore:
It will potentially break DDS and at least trigger "wrong" damage events
It is armor table dependent and not configurable to at least work around that point
It won't work on invulnerable units
It will break if someone modifies the units life in an onDamage handler
Calling GetUnitArmor in an onDamage handler will cause an infinite recursion and therefore crash the thread
It won't work with ethereal units

I don't really know how to prevent it from fire DDS events :s

The configuration will be done.

Yeah I'll fix it.

How will it break if someone modify life?

Yep sadly but it shares the same as the first point.

Woaps.

 

[Malhorne]

EDIT : Now works for ethereal units.
Still far from everything asked.

 

[Dr Super Good]

How will it break if someone modify life?

It has a potential to clash with damage shield systems. They add large amounts of life in response to a damage event and then run a 0 second timer so they can correct the unit life (as damage events fire before the damage is dealt to the unit).

The solution is to simply disable such systems (turn off all damage detection systems/triggers) before dealing the damage and enable them after the damage is dealt.

 

[Malhorne]

Yes but how can I turn off those system :/ ?

 

[edo494]

you can also check if some boolean is true, and if it is, run the code while setting it to false(set back to true at the end). Now it will not be true next time this thing runs, if run recursivelly, and since the only real thing that can cause callback in the middle of your code is Damage so you are basically done

 

[looking_for_help]

Yes but how can I turn off those system :/ ?

You can implement the functionality with conditional compilation for the most common DDS. Something like:

library GetUnitArmor uses optional DamageEvent, optional SomeOtherDDS
    // ...
    static if LIBRARY_DamageEvent then
        // Use library DamageEvent methods to disable the DDS
    else if LIBRARY_SomeOtherDDS then
        // Use library SomeOtherDDS methods to disable the DDS
    else
        // and so on
    endif
endlibrary

For that of course, the DDS have to provide some kind of API to disable them temporary. At the moment, PDDS doesn't have this because nobody requested it until now. If you want to implement that feature for PDDS, I can extend the API by a new method to activate/deactivate the system.

You might also consider things like mana shield (at the moment I guess it completly breaks the system) and spirit link (don't know if that is even solvable at all).

You will need to perform some research on the topic and make tests to overcome as much of these kind of problems as possible.

 

[Dr Super Good]

The damage detection systems should all share a standard API for enable and disable. Since more than 1 DDS might be in a map it would need to be some sort of broadcast messaging kind of API (not sure if static linking would work).

 

[edo494]

2 DDSs in one map? Thats basically asking for trouble

 

[looking_for_help]

The damage detection systems should all share a standard API for enable and disable. Since more than 1 DDS might be in a map it would need to be some sort of broadcast messaging kind of API (not sure if static linking would work).

Easy. Then instead else if just use a new if on every DDS:

static if LIBRARY_DDS1 then
    // Disable DDS1
endif
static if LIBRARY_DDS2 then
    // Disable DDS2
endif
// and so on

// do stuff 

static if LIBRARY_DDS1 then
    // Enable DDS1
endif
static if LIBRARY_DDS2 then
    // Enable DDS2
endif
// and so on

But yeah, I think edo is right, 2 different DDS in the same map is not the kind of code one wants to maintain and work with...

 

[Malhorne]

Okay but I need one function in each DDS to disable the DDS.
And I also need it for Shield System ^^'

 

[Laiev]

Can I suggest another way instead of tons of if's?

So people should configure by itself.

//! textmacro DisableDDS()
// Put your disabling function of DDS
//! endtextmacro

//! textmacro EnableDDS()
// Put your enabling function of DDS
//! endtextmacro

Or (I know, another callback, but we're here for tons of nanoseconds?)

private function DisableDDS takes nothing returns nothing
// Disabling function of DDS
endfunction

private function EnableDDS takes nothing returns nothing
// Enabling function of DDS
endfunction

And implement before-after the damage itself.

The best IMO would be the textmacro, but it is ugly by itself (but, no callbacks and no extra codes and no extra stupid statics ifs).

 

[edo494]

what about the boolean thing?

Also, you could just say it doesnt work with shielding abilities, or you could create copy unit, give it all the abilities, all the items, all the boosts(you would have to hook multiple functions to make it idiot-proof) and hit that unit

 

[looking_for_help]

Okay but I need one function in each DDS to disable the DDS.
And I also need it for Shield System ^^'

Correct, then I will update PDDS soon to support that.

Mana shield should be solvable by something like:

// Pseudo code
1. Save unit mana
2. Set unit mana to zero
3. Deal damage and restore health
4. Reset unit mana to previous value

EDIT:

Can I suggest another way instead of tons of if's?

It will be about 3 or 4 ifs in total (that get compiled away), so thats not really an argument.

A strong argument for the static if solution however is, that its done automatically by the compiler and the user doesn't have to implement enabling/disabling calls himself.

or you could create copy unit, give it all the abilities, all the items, all the boosts(you would have to hook multiple functions to make it idiot-proof) and hit that unit

That would probably be a good solution, but I'm not sure if its possible... can we even iterate over all abilities/buffs a unit has?

 

[Ruke]

Correct, then I will update PDDS soon to support that.

i would say that the authors of the approved dds talk to each other and come up with an interface so resources facing this scenario can work without any problem.

 

[Dr Super Good]

The problem is that there should be a common call to disable all DDS systems. Having to link each specific DDS implementation to turn off is a maintainability nightmare as you then couple the code to specific DDS implementations.

The only real solution is that all DDS systems should implement a standard interface. This will solve the "multiple DDS" problem as now users choose one. It also solves coupling and maintainability as you can replace DDS systems without needing to change any code.

 

[Ruke]

as dr points out, an alternative to an interface could be a wrapper (https://en.wikipedia.org/wiki/Adapter_pattern)

 

[looking_for_help]

The problem is that there should be a common call to disable all DDS systems. Having to link each specific DDS implementation to turn off is a maintainability nightmare as you then couple the code to specific DDS implementations.

The only real solution is that all DDS systems should implement a standard interface. This will solve the "multiple DDS" problem as now users choose one. It also solves coupling and maintainability as you can replace DDS systems without needing to change any code.

That won't be possible because not all DDS are really maintained anymore and relying on a specific API is also just convention but not a perfect solution ...

as dr points out, an alternative to an interface could be a wrapper

Just provide an optional module users can implement whenever they have to deal with a DDS thats not recognized by the system itself:

library GetUnitArmor
	private struct DDSDisabler extends array
		implement optional DDSDisableModule
	endstruct
	function GetUnitArmor takes unit u returns real
		static if DDSDisabler.DisableDDS.exists then
			call DDSDisabler.DisableDDS()
		endif
		// ... do stuff
		return 0.0
	endfunction
endlibrary

module DDSDisableModule
	static method DisableDDS takes nothing returns nothing
	endmethod
endmodule

Advantages:

• The user can add whatever enabling/disabling mechanism he wants for any custom DDS
• Basicall no overhead (neither runtime nor space) since enabling/disabling should be inlined
• The module can be placed in a different trigger, so the user does not have to modify the system code
• It also plays nice together with static ifs for the most common DDS

So just add the most used DDS with seperate static if's. That should be sufficient for >90% of all users, so they don't have to care about anything.

If someone really wants to use a "special"/custom DDS, then he can just implement the module.

 

[Ruke]

^ a wrapper should take care of those tasks, not this resource

library DDSWrapper
public function Enable takes nothing returns nothing
    static if (DDS_1 exists) then
        call <dds1 function to enable>
    endif

    static if (DDS_2 exists) then
        call <dds2 function to enable>
    endif

    //...
endfunction

// same for disable, do damage, get target, get source & get amount
endlibrary

edit: this is quite simple, i'm gonna submit the snippet in a moment

 

[looking_for_help]

^ a wrapper should take care of those tasks, not this resource

No, because the module solution can be extended by the user himself without touching any other existing code.

With the wrapper you showed you still have the same problem that you have a fixed list of systems which has to be maintained.

 

[Ruke]

the wrapper will provide support for a few known dds just to avoid a little bit of work if you do use one of them. if you use a non supported one, just add support for it by modifying the wrapper, there is nothing wrong on doing it. this is a practical way of solving this issue (the module is kinda hacky).

 

[looking_for_help]

the wrapper will provide support for a few known dds just to avoid a little bit of work if you do use one of them. if you use a non supported one, just add support for it by modifying the wrapper, there is nothing wrong on doing it. this is a practical way of solving this issue

Yes, there is something wrong with that.

A wrapper can make sense just for a single purpose, namely to make the conditional compilation reusable. As such, the wrapper would be a seperate library that other libraries can use to have a uniform interface for a given set of DDS.

Since the wrapper would be a library itself, it should not be modified by every of its users individually because otherwise the wrapper isn't reusable anymore which kills its purpose in the first place.

(the module is kinda hacky)

Why?

Thats exactly how modules are meant to be used: to provide a clean method to extend existing code.

 

[Ruke]

Since the wrapper would be a library itself, it should not be modified by every of its users individually because otherwise the wrapper isn't reusable anymore which kills its purpose in the first place

the purpose of the adapter, is to give a common interface to the client. its fine if it gets modified by the user as long as the api remains the same.

Why?

Thats exactly how modules are meant to be used: to provide a clean method to extend existing code.

having to use <x> exists directly on the resource is kinda shitty from my point of view.

 

[Malhorne]

Yes so we should spread the message to every DDS.
By the way I face a problem. How could I make this configurable with the type of armor since I can't detect type of armor ^^'

IMO I like textmacro and module.. but I'm a weirdo