ATTACK_TYPE and DAMAGE TYPE testing.

Ok I thought it would be a good idea to make a new thread for this instead of polluting Dusk's system thread.


me? how do we do this exactly.
And I think that making just the test and than providing results in a table is a very good idea.
Interpretation can be done later by anyone.

Just need to take this:
damagetest.zip

Modify writetofile.j so it uses grimoire's stuff that writes to file.

Take the map, compile and do test map.

Takes few seconds to get the table.

I don't mind my thread being used for such discussion, but this is likely the better choice regardless. I'm going to force this to become a tutorial once it's all figured out, just a heads up.

Would this be the correct output?
Edit: 7-zip attached

ouch forgot to left justify the damage value.
Thanks for attaching the compressed file after I downloaded the big one.

Just noticed:
ATTACK_TYPE_SIEGE,DAMAGE_TYPE_FIRE both spell immune and ethereal are immune to this combination.

I am attaching the final table, you got to love text editors that support regexps.

How to read it? That's a good question. Well, every unit tests something different, most of the normal units are just variations in armor types. The paladin is just your average hero, The Archmage is a hero with 'medium' armor, this was to verify that the hero classification had something to do with damage, seems not. The captain is a normal unit with hero armor, as it turns out the hero armor is almost never ignored. Archimonde(Warlock) is kind of useless, it tests for divine armor, but the "divine footman" is probably better there since archimonde also got spell immunity. The firelord has runed bracers so it tests for "magic resistance", it apparently is some sort of armor since it seems to depend only on attacktype.

The panda and the mountain giant were attempts to test hardened skin and resistant skin, I've been searching through the table and I am yet to find a case in which those mattered.

Every unit gets 100.0 damage without armor and 100.0 damage with a value of 1 for armor. Since it is 100.0 the values in the tables are damage percentages.

Edit: Know what would be awesome? To apply a decision tree to the table...

Sorry about that, I was a bit slow on realising how big it was.

It's looking good, I just hope the analysing won't be too tedious.

It looks like there is absolutely no way to achieve a combination that does 100% damage to every possible unit. Not even ATTACK_TYPE_CHAOS+DAMAGE_TYPE_UNIVERSAL. It is lame that ethereal seems to depend more on attacktype than damagetype ...

I can understand that. DAMAGE_TYPE_UNIVERSAL is only used to ignore Spell Immunity and Resistant/Hardened Skin. It's what most of the ultimates that do damage/healing use.

Doesn't Chaos damage (by default) just deal 100% damage to every armor type, including divine?

Seems DAMAGE_TYPE_NORMAL changes the rule for no reason.

Looks like ATTACK_TYPE_NORMAL+DAMAGE_TYPE_UKNOWN/UNIVERSAL is the only way to ensure possitive damage, the problem is that it will consider Hero, divine armor and runed bracers. The second chance is CHAOS+UNKNOWN/UNIVERSAL however CHAOS attacktype will never be able to hit ethereal units.

And if anyone can find a case in which Hardened/Resistant skin made a difference, I'll appreciate it, cause it looks like the damage native blatantly ignores them.

Wait.. so that means you cant insta kill ethreals if you use the above damage via trigger.

Also does "Ethereal" Include banished units?

Well the first thing that needs to be done with this table is downsizing.

There are a lot ATTACK/DAMAGE type combinations that give absolutely same results. (mostly because some DAMAGE types basically behave the same)

For example DAMAGE_TYPE_UNKNOWN == DAMAGE_TYPE_1, DAMAGE_TYPE_2, DAMAGE_TYPE_3, DAMAGE_TYPE_6...
(at least when using ATTACK_TYPE_NORMAL, did not check other combinations.)

This downsizing task is also something that can be automated.
Recreating decision logic would be much easier if we didn't have to mess with redundant cases.

So what we are doing here is basically reverse-engineering UnitDamageTarget function....

So, no voluntaries to decipher the stuff?

Could you make it in a .slk automatically with a little software ?
Like that it's pretty ugly.

Btw constants have the same value for a roc (.w3m) and a tft (.w3x) map ?

As far as I was aware, the game worked like this:

Armour applies to any type of Physical Damage that isn't Demolitions or Enhanced.

Ethereality stops any attack type except Spells (NORMAL), and Magic (MAGIC). ATTACK_TYPE_NORMAL must deal Magical or Universal damage.

Spell Immunity prevents damage from any magical damage type - FIRE, LIGHTNING, etc. It also stops ATTACK_TYPE_MAGIC.


The problem is that Blizzard switch up Attack and Damage types when determing resistances and immunities - ethereal / banished units, for example, are immune to specific damage types if the attack type is spells, and spell immune units are immune to Attack Type: Magic regardless of damage type (in addition to taking no damage from the magical DAMAGE_TYPE's).


So, basically, the only way to damage any unit in the game is by using:

ATTACK_TYPE_NORMAL, DAMAGE_TYPE_UNIVERSAL

But this will apply Hero Resistance / Runed Bracers unless the armour table is changed.


...unless I'm missing the point of this conversation :/.



Edit:

Just noticed something with WorldEdit. One of the problems is that Channel won't let you target Spell Immune enemies unless you choose Universal Spell, or the Required Level is greater than 6.

How it should be:

<Normal Spell> - Can target Ethereal, but not Spell Immune.
<Physical Spell> - Can target Spell Immune, but not Ethereal.
<Universal Spell> - Can target everything.

How it is:

<Normal Spell> - Can target Ethereal, but not Spell Immune.
<Physical Spell> - Cannot target Spell Immune, nor Ethereal.
<Universal Spell> - Can target everything.

Irritating, since physical spells (ATTACK_TYPE_NORMAL, DAMAGE_TYPE_NORMAL/ENHANCED/DEMOLITIONS) can damage Spell Immune targets.

But you guys probably already knew the WE thing.

Well for starters you can make that output in a little more programming friendly format.
I mean it is hard to parse it the way it is now.

Make it look more like table values and please no names with spaces in them.

Preferably make it in mysql or postgre text format.
Once that data is loaded into database it is simply a matter of writing a couple of smart SQL queries.