[vJASS] [System] Physical Damage Detection

[Nestharus]

Your trigger refresh will bug up on locust units.

If you use my trigger refresh, your damage event will run 2x for spell damage. You disable the damage event trigger, but that doesn't have anything to do with the TriggerRefresh macro.

Your init also still runs with or without the macro, meaning that your damage event will run a total of 3x, once for your stuff and 2 for trigger refresh.

Consider a map like Risk with 1000s of units. Whenever you do your simple trigger refresh, it'll do 1 trigger evaluation for every single unit... that'll make the map unplayable every 30 seconds. Hardly cool : p.

The cost of having complex and efficient trigger rebuilding, like my little macro, is that you have to run spell damage 2x to fix the damage. The benefit is that you don't have major performance drops with simple trigger refreshing ;D.

 

[looking_for_help]

I will take a look into it.

Consider a map like Risk with 1000s of units. Whenever you do your simple trigger refresh, it'll do 1 trigger evaluation for every single unit... that'll make the map unplayable every 30 seconds. Hardly cool : p.

So this happens only when using optional TriggerRefresh, right? Because in my tests (without TriggerRefresh) with 1000 units the refreshing was absolutly imperceptible even with a very low refresh rate... But I wil make some tests, thanks for the feedback.

 

[Nestharus]

Your system doesn't run at all on init -.-

 

[looking_for_help]

Your system doesn't run at all on init -.-

It registers all units on map init so what do you mean?

I don't understand any of your latest arguments... You talk about timers in your system that run even when they don't have to, you say my DDS doesn't handle nested damage events which is not true and now this...?

Be more specific or don't post at all, these word snippets don't help anyone. -.-

 

[Nestharus]

Lol, run it yourself

I ran a damage event on init and it didn't run (at init, I did UnitDamageTarget). Your on damage w/e didn't even run, I had a display timed text in there. When I delayed it on a timer, it ran.

Other people have been experiencing map crashes when modifying damage with nested damage events using your system

edit
And my updated DDS stuff doesn't run timers 100% of the time, so meh

 

[looking_for_help]

Lol, run it yourself

I ran a damage event on init and it didn't run (at init, I did UnitDamageTarget). Your on damage w/e didn't even run, I had a display timed text in there. When I delayed it on a timer, it ran.

Ok, now thats a sentence one can understand. Next update will fix this with a module initializer.

Other people have been experiencing map crashes when modifying damage with nested damage events using your system

Link?

I was in contact with some people lately that had problems like map crashes with my DDS and it turned out in all cases that they just didn't read the documentation properly and used the standard UnitDamageTarget instead of UnitDamageTargetEx inside of a damage event -> trivial to fix and not fault of the system.

So give me an example that breaks the system or don't claim things here.

 

[Nestharus]

Oh, I was just passing it from what Almia told me =D.

Oh btw, here are the benchmarks for the DDS systems

Physical Damage Detection Limit: 9
StructureDD Limit: 77
StructureDD Damage Type Limit: 23
DDS Damage Event Limit: 38
DDS Damage Event Modification Limit: 28
DDS Damage Event Archetype Limit: 19

Yea, I thoroughly improved mine :\. I was seriously getting scores of 3 on archetype with this update. I had to get creative to get it up to 19.

 

[looking_for_help]

Oh, I was just passing it from what Almia told me =D.

Ok, I talked to Almia and it was exactly the problem I assumed.

Use the safe function UnitDamageTargetEx as stated in the documentation and nested damage events (modified or not) get treated 100% correct.

Yea, I thoroughly improved mine :\. I was seriously getting scores of 3 on archetype with this update. I had to get creative to get it up to 19.

Hm, interessting. How do you define "Limit" in your benchmark setup?

 

[Nestharus]

Limit is when it drops to like 0-3.

I count it as when it holds steady at a value for like 15 seconds.

The others were stopped at 3 fps. Yours was stopped at 0.

 

[Cokemonkey11]

DDS Damage Event Archetype Limit: 19

Have you included both Archetype and Modification in this test?

 

[Nestharus]

Archetype required Modification, so yes

 

[looking_for_help]

Update as HammerFist132 found a little bug with the in-built bracer item, thanks for that. Also a module initializer is now used to fix problems with spell damage on map init.

UPDATE Version 1.0.0.2:
- Fixed a minor bug with the in-built bracer item
- Now using a module initializer to fix bugs with damage on map init

 

[Ruke]

Will this:

// Set damage variables  
set source = GetEventDamageSource()
set target = GetTriggerUnit()

cause recursion problems?

edit: It does:

    private function OnDamage_Actions takes nothing returns nothing
        set prevTarget = target
        
        call UnitDamageTarget(target, source, 10, false, true, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_NORMAL, null)
        
        if (prevTarget != target) then
            call BJDebugMsg("RECURSION PROBLEM")
        endif
    endfunction

It doesn't if you use UnitDamageTargetEx.

But, it can be easly fixed. Take a look at this: http://www.hiveworkshop.com/forums/jass-ai-scripts-tutorials-280/custom-event-data-187478/

 

[looking_for_help]

It doesn't if you use UnitDamageTargetEx.

But, it can be easly fixed. Take a look at this: http://www.hiveworkshop.com/forums/jass-ai-scripts-tutorials-280/custom-event-data-187478/

It doesn't need to be "fixed" because you should just use UnitDamageTargetEx. The function is there for a reason lol.

 

[Ruke]

It doesn't need to be "fixed" because you should just use UnitDamageTargetEx. The function is there for a reason lol.

Yes, but with that small fix you can avoid that extra function .

 

[looking_for_help]

Actually using this function was a very conscious decision. First of all I don't need to use any ifs in the onDamage handler, I can just put in one single line UnitDamageTargetEx -> shorter and better to read.

Second it avoids problems as described here automatically. I see nothing bad here, it was a design decision.

 

[Ruke]

Actually using this function was a very conscious decision. First of all I don't need to use any ifs in the onDamage handler, I can just put in one single line UnitDamageTargetEx -> shorter and better to read.

Second it avoids problems as described here automatically. I see nothing bad here, it was a design decision.

I see. Well about that, the only I can say is that, if the event is not fired, it will be for a reason :\.

Have you considered to make source & target readonly variables?. If you want to keep open the possibility of modify those variables, it can be done by function, so you are able to fire events like "target changed" or something like that.

 

[looking_for_help]

I see. Well about that, the only I can say is that, if the event is not fired, it will be for a reason :\.

Well, the reason is that the unit is already dead at that point.
Thats why an allocated attack shouldn't fire either, so allocated attacks on about-to-be-killed units should get filtered out.

Have you considered to make source & target readonly variables?. If you want to keep open the possibility of modify those variables, it can be done by function, so you are able to fire events like "target changed" or something like that.

Yes, I will make them readonly with the next update.

 

[Cokemonkey11]

lfh, you should consider using Table instead of manually instanciating a hashtable.

Either way you'll be using a hashtable, but with Table you can share one hashtable with many other systems, greatly reducing the initialization time for your client's maps.

Edit: You should use global variables here:

local real DUMMY_DAMAGE = 100
local real DUMMY_FACTOR = 0.01

 

[looking_for_help]

lfh, you should consider using Table instead of manually instanciating a hashtable.

Ok, I think I will make it optional in the next update.

Edit: You should use global variables here:

Thats right, will make them constant globals in the next version.

Thanks for the little review,
lfh

 

[Almia]

How about looking up inside Bribe's DDS for a recursion safety.

 

[looking_for_help]

How about looking up inside Bribe's DDS for a recursion safety.

The system is 100% recursion safe, Bribe's DDS bugs on modified allocated damage.

 

[Almia]

The system is 100% recursion safe, Bribe's DDS bugs on modified allocated damage.

You are right.
The recursion safety is one Im suggesting.

 

[looking_for_help]

Hm, I don't really understand what you are suggesting.

The system is recursion safe as long as you only use the function UnitDamageTargetEx from OnDamage handlers, not the native UnitDamageTarget, but this is stated clearly in the documentation. Why I used this function is explained here. IMO it is the superior approach, but of course thats only my opinion and there are others that also work fine. For example Nestharus system uses a fundamentally different approach to realize damage allocation, which is also fine.

 

[HammerFist132]

For me this is DC work, I dont know why we only see vjass/jass stuff in there when they are useless for great part of creators (except dynamic indexing).
While this (comparing with other damage engines), is much betters.)
Nesherus(i will never learn his nick), I never know how to use it, his blank map on start gives me hell no idea what it does, that system is DC but it is totaly gui unfriendly and useless work us (guiers)
Bribes, it is gui frendly and really useful, but know we can detect spells damagge with this and thats why I like it better.

I really feel bad because this is not DC work.

 

[Nestharus]

The code itself, the design, and the documentation were rated. The GUI portability was also included in the rating I believe.

The thing that was submitted was the GUI port, and it got the rating that it got. If this was submitted, this resource specifically, this one would have likely gotten a lower rating due to a variety of factors.

Making it easy to use for GUI users is just one small thing that is considered. The overall design, modularity, cleanliness of code, efficiency, algorithm choice, API, documentation, presentation, and presence of examples are also considered ; ). One GUI port and a few features aren't enough to make a DC ;p.


It was also quite difficult to get DDS to DC. Furthermore, for vJASS users, DDS is very easy to use, but this one is too. What sets them apart is the API, the design, the cleanliness of the code, and the performance ;p. DDS beats physical damage detection everywhere except for GUI port.

You can rest assure that this resource was judged fairly by actual professional coders (mag makes money on coding now, so he's a pro. Well, I do too >.<, lol).

This was approved for its alternative all in 1 design, which some people prefer. Stuff isn't approved unless it offers something that other resources do not . For example, coke's DDS also brings something different to the table (and I actually fought for the approval of coke's DDS).

 

[looking_for_help]

I really feel bad because this is not DC work.

Thank you very much
But I have to say that I am absolutely happy with the rating of my system. I mean, 5 of 5 is really good

What sets them apart is the API, the design, the cleanliness of the code, and the performance ;p. DDS beats physical damage detection everywhere except for GUI port.

Well, everywhere is an exaggeration

There are actually some more things than the GUI port which are not as good as in PDDS, apart from dependencies. Allocated attacks can still cause invalid damage events and there are still no methods to receive a units life/max life correct from an arbitrary scope. And things like API, as long as they follow a common convention, are subjective.

 

[Nestharus]

Huh?

When does DDS have invalid damage events?

It also has a way to retrieve correct unit life/max life as it uses another resource for that.

 

[looking_for_help]

It also has a way to retrieve correct unit life/max life as it uses another resource for that.

You are right about that, I didn't noticed you fixed it
Did you post it in the DDS thread? You should mention that in the documentation of the thread of the DDS.

Huh?

When does DDS have invalid damage events?

Try this test scope. Allocated spell damage seems to bug.

struct Demo1 extends array
    private static method onDamage takes nothing returns nothing
        if (DDS.archetype == Archetype.PHYSICAL) then
            call DisplayTimedTextToPlayer(GetLocalPlayer(), 0.0, 0.0, 60.0, R2S(damage)+" physical damage!")
        elseif (DDS.archetype == Archetype.SPELL) then
            call DisplayTimedTextToPlayer(GetLocalPlayer(), 0.0, 0.0, 60.0, R2S(damage)+" spell damage!")
        else
            call DisplayTimedTextToPlayer(GetLocalPlayer(), 0.0, 0.0, 60.0, R2S(damage)+" code damage!")
        endif
        
        if (archetype != Archetype.CODE) then
            set damageCode = sourceId
            call UnitDamageTarget(source, target, 5000, true, false, null, DAMAGE_TYPE_UNKNOWN, null)
        endif
    endmethod

    implement DDS
    
    private static method onInit takes nothing returns nothing
    endmethod
endstruct

 

[Nestharus]

I'll check it out

 

[PurplePoot]

Unless this system has more debugging than its GUI counterpart, it's seriously flawed.

 

[Cokemonkey11]

The UnitAlive native is the recommended use for checking if a unit is alive because setting a dead unit's life to > 1 has other applications.

Does this problem exist in the other DD systems that use damage reduction? DamageType, DamageEvent, etc

 

[BPower]

In GUI dead/alive check is IsUnitAliveBJ --> IsUnitDeadBJ --> GetUnitState(whichUnit, UNIT_STATE_LIFE) <= 0.

I'm quite sure this DDS is frequently used, because we only have two GUI-friendly DD-systems in our spell data base. An update is necessary if major flaws exist.

 

[looking_for_help]

Unless this system has more debugging than its GUI counterpart, it's seriously flawed.

Ok, first of all thanks for reporting this bug, it is fixed now.

But appart from that I have to tell you that I don't like your behavior. You reported this bug just a few hours ago(!) so you can't vote for an "unapproval". Its normal that even approved systems might contain bugs, but then just report them and give its creator the chance to fix them in time.

Does this problem exist in the other DD systems that use damage reduction? DamageType, DamageEvent, etc

I made a quick test with your DamgeType and Nestharus DDS which are the only other DDS with type support and both systems do contain this bug too. However the solution is easy, just set the units life to zero after applying max damage to it after a spell damage event (compare my DealFixDamage function).

I'm quite sure this DDS is frequently used, because we only have two GUI-friendly DD-systems in our spell data base.

And only this one of those two supports damage type detection

However, the bug is fixed now. Other approved DDSs have much more critical bugs and that for years now...


UPDATE Version 1.1.0.0:
- Fixed a bug that made functions like GetWidgetLife return invalid values after killing a unit with spell damage

 

[BPower]

Nice, I was hoping you're up for an hotfix . I'll run some tests later.

 

[PurplePoot]

Ok, first of all thanks for reporting this bug, it is fixed now.

But appart from that I have to tell you that I don't like your behavior. You reported this bugs just a few hours ago(!) so you can't vote for an "unapproval". Its normal that even approved systems might contain bugs, but then just report them and give its creator the chance to fix them in time.

I didn't mean any offence, but that bug was serious enough to break any GUIer's map and this is the damage detection system that they'll find on THW if they look for a GUI-friendly one. Figured it was better to be safe than sorry as we saw in the other thread.

 

[looking_for_help]

Yes, thats true and I'm glad you found this bug, especially as other DDS contain it too. But next time just report the bug, it will get fixed in time

 

[Cokemonkey11]

I made a quick test with your DamgeType and Nestharus DDS which are the only other DDS with type support and both systems do contain this bug too. However the solution is easy, just set the units life to zero after applying max damage to it after a spell damage event (compare my DealFixDamage function).

Thanks for checking! I may fix it later but it's not really a priority (I don't even support GUI)

 

[looking_for_help]

Yeah well, its not only a GUI problem because it will bug in vJass too. So without the fix the GetWidgetLife function is basically not reliable anymore.

But fortunatly the fix is very easy

 

[PurgeandFire]

Do you know if Bribe's uses it too? He might want to be notified as well since his DDS is so common.

 

[looking_for_help]

He might want to be notified as well since his DDS is so common.

I don't think so.

I reported several grave bugs in his DDS more than one year ago and until now nothing happend. So I don't think he is really supporting his DDS anymore.

 

[Bribe]

The reason why I haven't touched modding in so long are because of the bugs when I try to get Jass NewGen Pack installed on my Windows 8.1 machine. The auto-cleanup of the built-in scanner is obliterating the Jass NewGen files and makes it impossible to install. As for my GUI damage system, the reason I haven't touched IT is because I don't know where the problem is. The system looks perfect to me, I can't reproduce the bugs people have mentioned.

 

[looking_for_help]

The system looks perfect to me, I can't reproduce the bugs people have mentioned.

Seriously?

I mean all the bugs I mentioned above are really so easy to reproduce that I can't believe you even tried. I even gave detailed instructions on how to reproduce them. But ok, I upload a test map were one can observe those bugs. Those are the main points:

• Increasing the damage of an artillery unit doesn't explode killed units. In the testmap take the orc destroyer and attack the grunts. They will die but not explode. This is not an acceptable behavior for a DDS because it changes the game mechanics.
• Decreasing the damage totally breaks everything if there are multiple damage instances running at the same time. And you will nearly always have that problem, even with native spells. In the testmap, take the Mountain King and attack the enemy grunts. You won't even be able to deal any damage to them because his Bash skill runs two damage instances at the same time (one Spell and then one Physical). This can result in spontanous heal instead of damage and in the worst case (like in the testmap) lead to a hero that deals essentially no damage at all. For any map maker, this is a nightmare to debug.
• The health bars of attacked units flicker very strong if they have full HP and one blocks all damage for them. In the testmap, take all the Wyverns and attack the Orc destroyer. They don't deal damage, but its health bar will flicker very strong.

There are more issues, but those are really the main points and before they are not fixed it doesn't make sense to go more into detail.

Sorry, but "perfect" looks different for me

 

[Bribe]

- I know about the artillery bug, with the way the system is set up there is no way to avoid it. It doesn't detect if the damage was siege. I mentioned that you had to trigger siege damage and set ExplodeUnit to true.
- The flickering health bars was a glitch in the wc3 engine, because Timers set to 0 seconds still aren't instant.
- I will look into the issue that you mentioned with some units not dealing any damage. That's not something I came across.
- As far as the features this library goes into, I will never update the GUI system to take advantage of it. I just want to fix the bugs with my current system that you and others have mentioned. Thanks for the test map. I will do my best to find out what the f*k is happening with the system.

 

[looking_for_help]

- I know about the artillery bug, with the way the system is set up there is no way to avoid it. It doesn't detect if the damage was siege. I mentioned that you had to trigger siege damage and set ExplodeUnit to true.

Well but thats very bad because triggering all siege is a lot of work. You also don't need to detect whether the damage was siege or not. Recent damage systems like Physical Damage Detection explode units correctly without detecting siege.

- The flickering health bars was a glitch in the wc3 engine, because Timers set to 0 seconds still aren't instant.

Same here, try the thing with the Wyvern in Physical Damage Detection. You won't be able to cause any health bar flickering although the system uses 0 second timers too.

It is possible to avoid these issues, so they should be avoided. No one wants to recode all siege abilities

- I will look into the issue that you mentioned with some units not dealing any damage. That's not something I came across.

Yes, however not dealing any damage is the worst case which I constructed extra for this testmap. The "standard" behavior is that units get healed unpredictable. Compare the link I posted before.

- As far as the features this library goes into, I will never update the GUI system to take advantage of it. I just want to fix the bugs with my current system that you and others have mentioned. Thanks for the test map. I will do my best to find out what the f*k is happening with the system.

You're welcome

 

[Kazeon]

> GUI Version available here <

please! it's Jass, not GUI :/

 

[looking_for_help]

It is a GUI version because you can use it with a GUI interface and the vanilla editor.

For the user of the system its important that he can use it without any Jass knowledge and GUI only, nothing else. And this is exactly what the GUI version is for.

Neither Weeps DDS nor Bribes DDS (which basically are the other GUI DDSs out there) are coded in GUI, so this comment is kinda pointless...

 

[Bannar]

Give Dalvengyr some room for error, he is still learning.

Meaby GUI-friendly would be more appropriate, however, Dalvengyr, GUI trigger after conversion is basically jass script so writing a jass version of lib where user does not need to understand any part of system nor enter the script code except for configuration part allows you to use it with GUI and unmodified editor.

 

[Kazeon]

GUI-friendly

that's what I meant, whatever the reason is, it's still coded in JASS, not GUI.. but GUI friendly..

EDIT:
nuff said :>

 

[edo494]

its impossible to create any DDS without using custom script, and at that point you can just write it in Jass