System Damage Struct

[Dirac]

This dynamic approach to damage detection seems to only make sense in games like tower defenses(or where only some units need damage detection/modification). Though I really do like the style of this it's much easier to deal with full encompassing where all units are effected on default like using Purge's Damage Control with Damage Event than this for when you need damage detected for every unit. I mean this dynamic approach doesn't seem useful for rpgs where every unit needs damage detection/modification in my opinion.

This system provides global damage detection as well, just use the RegisterGlobalDamage function or get DamageMods which are much more useful.

Also I don't like that you implemented the Armor checks in this because you are basically using an single damage and check reduction approach. The problem arises with varying damage like a unit deals 50-100 dmg the unit hit may get like 60 dmg or 80 dmg and it could still be the same armor value. The only right way to deal with armor and armor value would be to store unit's armor values in tables; but that gets kinda ugly as well.

You might want to recheck how Armor is calculated, it's now very accurate and dosn't use unit specific damage. The "Armor" resource i submitted should be graveyard as now the armor can be adquired throgh the function GetUnitArmor this system provides.

 

[Switch33]

You might want to recheck how Armor is calculated, it's now very accurate and dosn't use unit specific damage. The "Armor" resource i submitted should be graveyard as now the armor can be adquired throgh the function GetUnitArmor this system provides.

Yeah, your right. I guess I was a bit mistaken looking at it. Can't wait for a test map then; I am considering using this but the API is a bit confusing not for the DamageStruct; but for using DamageStruct in combination with the other libraries like Amplify Damage etc. somewhat with the priority stuff there.

Also you should just flat out say as a note; You can only detect to around -20 armor using triggers like this; and it's not really a limit of this system since it's more of a limit that wc3 only factors in -20 armor as the max negative armor reduction.

 

[Dirac]

Please post any doubts you have on this thread.

v1.11
-Changed entirely the API of the DamageStruct module
-Added new 2 public functions: "RegisterUnitDamageDealt" and "RegisterUnitDamageTaken"
-Damage type modding now goes before DamageMods

 

[tooltiperror]

I think my problem with this is that it has large errors that I am just not okay with.
1. You decoupled this system, at the cost of making me search for a bunch of libraries. Despite what people will tell you, you do NOT need to decouple everything, for the sake of decoupling. This library is MISSING core features.

DamageMod should be a part of this library. It is foolish for it not to be.

While Shield and Armor sound cool, they're better off left to users to code themselves, or they should be implemented right in Damage.

Dampen/Raw/Amplify are more things that should be incorporated as parts of this library, not modifications.

2. There needs to be a way to modify all damage. Making me do everything based on unit-per-unit basis is insane.

3. Your documentation is still poor at best. The *s looks like they were put in random positions, you have a "--->" in there that I don't understand. It is traditional of WC3 to prefix lines with "//" rather than using block comments, but I will not force you into doing that. You should have Pros and Cons of this system right at the top. The globals should be below the API. Your demo is shoddy, and doesn't really explain anything, you should make realistic demonstrations and post them in the thread.

4. The demo map should be attached to this post, not linked.

5. You're still missing a non-OOP interface. Jass is not OOP, OOP is just some fluff.

 

[Dirac]

1. You decoupled this system, at the cost of making me search for a bunch of libraries. Despite what people will tell you, you do NOT need to decouple everything, for the sake of decoupling. This library is MISSING core features.

>I beg to differ, this library functions perfectly on it's own, apparently you haven't read the full API yet because from some of what i read from post indicates that this system lacks of a method to register all damage done. Did you notice the RegisterGlobalDamage function?
DamageMod exists only for people who are interested in damage modification by priority. If you aren't interested in that you might as well use the RegisterGlobalDamage call
I do agree, shield should be coded by users, but it's nice to have something that does it so easily
Armor should be graveyarded (GetUnitArmor is now part of this system)
Dampen/Raw/Amplify are no different from Shield, they should be coded by the user, although this saves some work.

2. There needs to be a way to modify all damage. Making me do everything based on unit-per-unit basis is insane.

>Wrong, RegisterGlobalDamage or even DamageMods can do this

3. Your documentation is still poor at best. The *s looks like they were put in random positions, you have a "--->" in there that I don't understand. It is traditional of WC3 to prefix lines with "//" rather than using block comments, but I will not force you into doing that. You should have Pros and Cons of this system right at the top. The globals should be below the API. Your demo is shoddy, and doesn't really explain anything, you should make realistic demonstrations and post them in the thread.

>I'll look into the documentation, the arrows mean that the following indentation block is part of the stated above (struct ---> methods).
The demo map is highly outdated because the helper's upload system seems to be broken and i can't upload anything into this part of the forum.

5. You're still missing a non-OOP interface. Jass is not OOP, OOP is just some fluff.

If by that you mean "Damage.target" the user isn't forced to use my globals, if he likes to bloat his code i suggest to use the w3 natives inside it's coding [ljass]GetEventDamageSource()[/ljass]

After reading your post i'm left with very little to change, since damage mods are so easily executed now i might add them into this system, but it sounds equally as foolish to have them and not to use them.

 

[Dirac]

Thoughts on the 2.0 update:
-I was thinking of removing the DamageStruct and DamageData module since they are prompt to cause issues when it comes to calling the methods they provide inside any struct, because you have to implement it below any damage handling method and above any calls of their methods it's almost impossible to avoid trigger evaluations. Therefore a global system to register and unregister unit damage will be developed (so far with the RegisterUnitDamageDealt/Taken calls)
-Currently the DamageData module doesn't support MUI, why? Because it attaches data to the unit's custom value, if the same unit were to have data attached to it twice, it would cause bugs. A solution to this? Adding Table as a requirement to the system in order to provide perfect data retrieval through damage events, the downside would be that every unit would have a linked list of evaluation triggers and each one of it with data attached (this would be because there's no way to determine how many conditions have been evaluated for a trigger in the same thread), but this sounds like a separate optional resource. I'll also look into that.

I really need some feedback on this to start working on the new version.

 

[Switch33]

-I was thinking of removing the DamageStruct and DamageData module since they are prompt to cause issues when it comes to calling the methods they provide inside any struct, because you have to implement it below any damage handling method and above any calls of their methods it's almost impossible to avoid trigger evaluations. Therefore a global system to register and unregister unit damage will be developed (so far with the RegisterUnitDamageDealt/Taken calls)

Makes sense.

Currently the DamageData module doesn't support MUI, why? Because it attaches data to the unit's custom value, if the same unit were to have data attached to it twice, it would cause bugs. A solution to this? Adding Table as a requirement to the system in order to provide perfect data retrieval through damage events, the downside would be that every unit would have a linked list of evaluation triggers and each one of it with data attached (this would be because there's no way to determine how many conditions have been evaluated for a trigger in the same thread), but this sounds like a separate optional resource. I'll also look into that.

This isn't a problem if you add the damage detection to the units only on indexing but then again that's not really "dynamic"(being able to add damage events whenever you want etc). Using Table would make it more heavy of a system on events i think and kinda wrecks some of the whole "dynamic" approach. Hmmph
Maybe the damage detection should be non dynamic but the modding of the damage like AmplifyDamage, DampenDamage etc should be dynamic (I mean this approach might work. . .)?

 

[Dirac]

Well i've been testing Damage v2.00 with Table and Alloc for perfect damage data retrieval and it works like a charm.

Pros:
-Perfect data attachment to each event. Doesn't conflict anymore
-You can disable registration of damage inside damage handling methods (currently causes a w3 internal bug)
Cons:
-Very slow (iteration through trigger evaluations of values inside of a hashtable)

static method fire takes thistype unitId returns nothing
    local integer  i = unitId.inst //times to iterate
    local thistype this
    loop
        exitwhen 0==i
        set this=unitId.list<i> //value inside of hashtable (list)
        set currentData=this.data //data retrieval
        call TriggerEvaluate(this.trig) //trigger evaluation.
        set i=i-1
    endloop
endmethod</i>

 

[Laiev]

Cons:
-Very slow but safe

 

[Switch33]

-You can disable registration of damage inside damage handling methods (currently causes a w3 internal bug)

How is this a pro if it causes a w3 internal bug? Does the internal bug cause game crashes and if it does do you have a way to fix this?

 

[Dirac]

What i meant is that currently (as version 1.12) if you try to disable damage registration for a unit inside a handling method it would cause a bug (if you remove a condition from a trigger during the evaluation of that same trigger it would stop the whole thread), but 2.0 fixes this (works differently, but slower)

EDIT: Pulled off a version that doesn't use a hashtable, you can't exceed the array max size of when it comes to specific unit registration, but i don't think that would be a problem.

updated to v2.0 and i really hope no one is yet using this since i've changed the API so much
-The DamageStruct and DamageData modules are gone
-Introducing the new DamageDealtEvent and DamageTakenEvent structs, with some additional wrappers for better understanding
-Reworked a whole new way to attach data to damage events. Now it doesn't cause conflicts in any way
-Unregistering damage events inside damage handling methods is now safe
-Changed the API of some of the functions

 

[Switch33]

Your armor check doesn't consider the armor type of a unit which is sorta impossible unless you attach data of armor types to units. So I think it is still a better idea to remove the armor part. I feel like it just doesn't feel right to have that in the same library if it's gonna have such inaccuracy in giving true values.

You could code some seperate library like ArmorUtils that considers armor types of units which might be useful as an add-on library and a requirement for RawDamage.

 

[Dirac]

Your armor check doesn't consider the armor type of a unit which is sorta impossible unless you attach data of armor types to units. So I think it is still a better idea to remove the armor part. I feel like it just doesn't feel right to have that in the same library if it's gonna have such inaccuracy in giving true values.

You could code some seperate library like ArmorUtils that considers armor types of units which might be useful as an add-on library and a requirement for RawDamage.

Where do you get this info? Are you testing it?
The GetUnitArmor function returns the armor value of the unit, ignores the type (doesn't matter if the unit has 20 "unarmored" type armor or 20 "divine" type armor, it returns 20)

 

[Switch33]

Yeah your right. However this is related;

Attack_Type_Chaos is treated as Normal(unable to effect ethereal units)? Source: http://www.wc3c.net/showthread.php?p=1030046

It's still a bit wrong since the attack type chaos cannot be used to damage ethereal units. Bleh, i'll just end up coding ethereal anyway so I guess it doesn't matter. But if you want to fix it. . . You can add a check for if the unit is ethereal before checking the armor and using a different damage method using ATTACK_TYPE_NORMAL might get the result.

 

[GFreak45]

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?

 

[Switch33]

According to that thread; DAMAGE_TYPE_NORMAL , ATTACK_TYPE_NORMAL should work to get an ethereal unit's armor value. (Though u'd have to include data based on gameplay constants the extra dmg rule or wtever ethereal units get from banish/ethereal to get the right result.)

Though this would make users have to trigger Spell Damage Reduction which is fine.

 

[GFreak45]

its 1.8, i believe, so if you want to do the math for it, you would just need to deal 1 dmg, multiply it by 5/9 and then apply the number you get to the algorithm for armor

 

[Magthridon96]

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

If you're supporting UnitIndexer, you should at least implement the
UnitIndexStruct in your DamageStruct (static ifs) and change the
method names to "index" and "deindex" (with static ifs)

Also, I'd recommend using 2.0.0.0 as a version number instead of 2.00 so we can tell when:
- Backwards compatibility is broken
- Bugs are fixed
- Optimizations are done
- Miscellaneous fixes are done

 

[Dirac]

I'm not sure of what you mean by modular
GetUnitArmor is just a single function that only fires if the user wishes to call it, causes no kind of conflict with the system, so is GetDamageReduction

 

[tooltiperror]

Could you please again explain why this is better than Damage? I'm trying to assess this resource perfectly.