[JASS] [System] DamageDetectSystem

[looking_for_help]

The best/cleanest solution would be probably to make this as a seperate resource (a LifeChangeDetection library) and then use that system in a DDS to handle spell damage inverting. Then it would be maybe possible to detect heals and such too, plus on- and after-damage events.

 

[Kazeon]

I won't continue this debate. It could be endless. I don't need the fame of creating new DDS, honestly, I just want to ease my own life lol. Even if you want the fame by changing author name to somebody else, it's totally total okay, but guess it would be disrespectful. My Illusion snippet is just one concrete example how successful is this DDS to fulfill my needs. If you still believe that this DDS is "worthless", perhaps, just read the code by yourself. If you really can prove that this DDS is really "nothing better" or just simply "negligibly faster", then it's very fine for me to GY this c: That's all I can say.

Btw, still struggling to fix one nasty bug.

 

[chobibo]

I think if you do this to just ease your own burden then this defeats the purpose of a general purpose resource. I am not trying to antagonize you, it's just that I think that it is obvious that submissions should be designed considering the userbase of the hive due to it being publicly available and not just your own because if that were so then you could just tailor this script to fit your needs since you are capable of doing so, right?

 

[Cokemonkey11]

I won't continue this debate. It could be endless. I don't need the fame of creating new DDS, honestly, I just want to ease my own life lol. Even if you want the fame by changing author name to somebody else, it's totally total okay, but guess it would be disrespectful. My Illusion snippet is just one concrete example how successful is this DDS to fulfill my needs. If you still believe that this DDS is "worthless", perhaps, just read the code by yourself. If you really can prove that this DDS is really "nothing better" or just simply "negligibly faster", then it's very fine for me to GY this c: That's all I can say.

Btw, still struggling to fix one nasty bug.

Who are you addressing?

 

[Kazeon]

So here is an update. Last spotted bug has fixed. Including some improvements. And it's renamed to DDD.

Any further complain about the existence of this DDS will not be replied, again, just read the code, prove it's not better at all, GY, simple as that. I have been sick with these negativities which always happen around my stuffs. I wonder why even after trying to be nice person but still hatred always haunting everywhere lol.

 

[Tal'Rarity]

Don't be paranoid, it'll be troublesome if you can't accept feedback/comments on your work. This has been done over and over, you should have been ready. So is it the fastest yet?

 

[looking_for_help]

If you still believe that this DDS is "worthless", perhaps, just read the code by yourself. If you really can prove that this DDS is really "nothing better" or just simply "negligibly faster", then it's very fine for me to GY this c: That's all I can say.

Actually you were the one that said "this DDS is slow" without any prove, right?

I just gave my opinion about such micro optimizations, but you can of course disagree. The thing is you say a lot about the existing DDS which is wrong like

• Too slow (without providing any benchmark/example)
• Damage blocking to difficult (its just one variable assignment)
• Damage reflection not/only with "tricks" possible (which is already supported out of the box)
• Installation difficult (while you have to do just the standard steps as in every DDS)

I would say, its just fair to let an author rectify such points, right? Especially since you never responded to questions what exactly was so problematic for you with the existing DDS. Also, do some research on things you can easily answer yourself.

About your system itself, you fixed a lot of bugs and it don't think its bad. It needs more testing, but IMO it offers enough difference to the other DDSs to be approved eventually.

 

[edo494]

while we are at microoptimizations:

        // Remove health bonus
        if GetUnitAbilityLevel(u, DDD__Ability_2()) > 0 and UnitRemoveAbility(u, DDD__Ability_2()) then
        endif

-->

        local integer abil2 = DDD__Ability_2()
        // Remove health bonus
        if GetUnitAbilityLevel(u, abil2) > 0 and UnitRemoveAbility(u, abil2) then
        endif

since it always returns constant value, there is guarantee that it wont change during runtime

 

[Kazeon]

while we are at microoptimizations:

        // Remove health bonus
        if GetUnitAbilityLevel(u, DDD__Ability_2()) > 0 and UnitRemoveAbility(u, DDD__Ability_2()) then
        endif

-->

        local integer abil2 = DDD__Ability_2()
        // Remove health bonus
        if GetUnitAbilityLevel(u, abil2) > 0 and UnitRemoveAbility(u, abil2) then
        endif

since it always returns constant value, there is guarantee that it wont change during runtime

And because it's constant one-liner function, it's going to be in-lined on vJass compilation or map optimizer. So don't worry about that one.

@lfh:
I'm sorry, I was at worse mood yesterday because my house was flooded and we don't have any electricity for 3 days, and bunch of other embarrassing things like no water for bath, etc, etc. Such disaster.

I will do some benchmarkings later, anyway I didn't say anything about "faster" after you wanted me prove about the speed difference. Yeah, that was my bad for saying too slow without prove.

 

[chobibo]

That is if they use jasshelper to compile it, what about those guys who use vanilla editor? How about them?

 

[edo494]

since your code is pure Jass and even variables are GUI-confronting, there is no guarantee that the end user of this DDS will actually have JassHelper enabled

 

[looking_for_help]

I'm sorry, I was at worse mood yesterday because my house was flooded and we don't have any electricity for 3 days, and bunch of other embarrassing things like no water for bath, etc, etc. Such disaster.

No problem, thats ok. I'm very sorry for your house and wish you the best for this situation.

I will do some benchmarkings later, anyway I didn't say anything about "faster" after you wanted me prove about the speed difference. Yeah, that was my bad for saying too slow without prove.

Alright, that will be interesting. And try out locust swarm in your test map

 

[Kazeon]

it's going to be in-lined on vJass compilation or map optimizer

There

 

[Bribe]

I get the feeling that PDDS supports everything this does, and more efficiently with more features and less bugs. Graveyarding in 7 days.

 

[edo494]

6. Turn on/off the damage detection.

this currently isnt supported by PDDS, but it is trivial to update

 

[Bribe]

Yeah, sounds like a minor patch to implement. Better to not have a whole different system just for that.

 

[Kazeon]

I get the feeling that PDDS supports everything this does, and more efficiently with more features and less bugs. Graveyarding in 7 days.

Feeling? I didn't make this without effort. It feels really disrespectful to me, that you simply use your feeling based on quick looks to graveyard this, without having a good look at everything.

At least you need mention which part of this system is less efficient, or which part is bugged.

If what you mean PDDS has more feature because it allows you to get a unit's life then..... I really don't know what to say.
_______________________

As I have programmed more things I can spot some things to be improved in the code. I will update this later.

 

[Wietlol]

I didn't make this without effort.

At least you need mention which part of this system is less efficient, or which part is bugged.

At least tell us why this one should be used over any other DDS.

Mine for example is designed to revert damage taken to the damage that is placed in the object editor.
Lets say I do 100 damage with my firebolt but you have 50% spell damage reduction, then I will see amount = 100 but you see amount = 50.
And mine tries to keep normal bracers etc in the game.
Mine also allows you to easily create additional stuff to the DDS witout having to modify the code of the system (you could but dont have to).
It also has the difference between 0 damage taken and blocked damage.
It also has an event for when a unit takes fatal damage and is able to block it.
It has 100% GUI Support (even with Damage area) and doesnt need object editor data (still testing this).
It also can tell the difference between coded physical spell damage and basic attacks and can have basic attacks that deal magic damage.

There is only one thing that has to be finished which requires a new update of vJASS and it is heavy... but it is worth to pay that price imo.

So... what does your DDS do compared to other DDS like lfh's for example?

 

[Kazeon]

Mine is designed to do as least actions as possible in the damage event part, because it's the most fired event when a DDS is implemented in a real map. It gives you ability to filter out which kind of units in your map which do not need a damage detection, as well as turn off detection for a specific unit or the whole, to avoid unneeded detections.

And Wietlol, no matter how many fancy features you added into your DDS, if yours cause any kind of spike when it's implemented in a huge maps, then it's still a failure. And people doesn't judge whether a DDS is new or not based on how many features there is in the system, currently I can't say yours is an "acceptable variation" yet as well. I can add all of those features you mentioned in 5 minutes if I want, but I'm trying to create a perfect DDS with as least feature as possible, not a bloated one.

Lets say I do 100 damage with my firebolt but you have 50% spell damage reduction, then I will see amount = 100 but you see amount = 50.
And mine tries to keep normal bracers etc in the game.

That doesn't explain yours is superiorly different enough from the other DDS, just upload it here and let's see how people will criticize you.

I don't want to compare my DDS's strengths against the other DDS's weaknesses because it will only trigger another debate. But surely I have some points of those.

 

[Wietlol]

Mine is designed to do as least actions as possible in the damage event part, because it's the most fired event when a DDS is implemented in a real map. It gives you ability to filter out which kind of units in your map which do not need a damage detection, as well as turn off detection for a specific unit or the whole, to avoid unneeded detections.

So you want to create a Plain DDS?

And Wietlol, no matter how many fancy features you added into your DDS, if yours cause any kind of spike when it's implemented in a huge maps, then it's still a failure.

That is not really true... and you know it.
If I want to focus on extremely powerfull systems and do out-of-the-box stuff, I can assume that the systems that I use are a bit heavier than the regular ones.
However none of the existing DDS are ABLE to make my upcoming AoS run glitchless. NONE are ABLE to do so.
Except mine... ofcourse this is a bit unfair, because mine is designed for my AoS and Dungeon map so ofcourse mine is favoured to work well with them
So no offense to any other DDS out there.

And people doesn't judge whether a DDS is new or not based on how many features there is in the system, currently I can't say yours is an "acceptable variation" yet as well. I can add all of those features you mentioned in 5 minutes if I want, but I'm trying to create a perfect DDS with as least feature as possible, not a bloated one.

Ow you mean a plain DDS?
Why bother creating it?

That doesn't explain yours is superiorly different enough from the other DDS, just upload it here and let's see how people will criticize you.

I guess you missed a spot.
I did upload it, and it got criticized.
Now, I only have to test out the Object Editor Extraxtor to complete it for other people's usage.

Also, that means that only mine (as it is the only one that reverts the damage amount) is able to make the right calculations when you change the damage amount.
(100+20) / 2 = 60
100/2 + 20 = 70
Some things just are not meant to be.

I don't want to compare my DDS's strengths against the other DDS's weaknesses because it will only trigger another debate. But surely I have some points of those.

You shouldnt compare your DDS' strengths against other's weaknesses.
You should compare your DDS' strengths and weaknesses to a Plain DDS.
And compare yours to the strengths and weaknesses to one of the usual used DDS.
Then you can see if it is worth making yours and using yours.

 

[Bribe]

Quilnez, I have updated Damage Engine to version 3. I recommend checking it out.

This DDS has many bugs which I can identify for you if you like.

 

[Kazeon]

This DDS has many bugs which I can identify for you if you like.

Yes, please, if you don't mind. So I can patch this.

I will also check yours what's new

 

[Bribe]

In recursive events, your system will not fire the events a second time because you did not set the damage event variable to 0 before re-triggering it.

Before checking if damage is physical or spell, rule out a zero damage event

The method for which you detect how to modify life looks ofd. Why are you setting the unit's life to the damage amount?

Instead of having a boolean to disable the DDS, simply turn off the trigger.

You should only add the protect ability if the unit actually will die from full physical damage at full health. Otherwise, just add the unit life after the damage was dealt.

The user should be able to detect if it was spell damage AND be able to set a custom damage type to the damage before dealing it. This way, you can manually trigger damage you want to be physical or spell without worrying about not being able to track the user-defined damage type on top of that.

 

[Bribe]

I'm looking over this a bit more to see your motives behind some design choices.

I am most curious why the "bucket" technique is used by you and Nestharus. My sole contribution to Nestharus' DamageEvent was to use a "wasted events" variable and refresh the trigger when the variable hit a certain threshold. He messaged me a couple of years ago saying that buckets should be used from now on.

Here's why I don't like it: Normally, the damage event trigger has all the events. If you want to disable damage detection, disable the trigger and you've dealt your damage. With buckets, you can either set a boolean to assess if the engine should run (as you use here) or lookup the trigger the unit is registered to and disable it (as Nestharus does). First way adds a lot of overhead, second way adds more of lines of code.

Both methods require more code and more handles than a single trigger, and require a steeper learning curve. The "inefficiency" of smashing and rebuilding a single trigger is a joke. It's called so infrequently that it would have such indiscernible run time that you couldn't find it even if you were looking for it.

 

[Kazeon]

(Took from your DDS)

 Custom script: loop
 Custom script: exitwhen udg_UDex == 0
 If (All Conditions are True) then do (Then Actions) else do (Else Actions)
 If - Conditions
 UnitDamageRegistered[UDex] Equal to True
 Then - Actions
 Trigger - Add to DamageEventTrigger the event (Unit - UDexUnits[UDex] Takes damage)
 Else - Actions
 Set UDex = UDexNext[UDex]
 Custom script: endloop

Using your method, the trigger refreshing could be quite costy depends on how many units are there in the map, isn't that right? Let's say there are 1000 indexed units, then you need to iterate through all of those units and re-register them. Using buckets, if you call it so, you don't really need to worry about how many units there are. You just need to iterate through units which are included in the trigger group (bucket). In Nest's code it's called BUCKET_SIZE iirc, so let's say it's 32, then you just need to iterate through 32 units, even tho there are a million of units. It takes exactly the same cost no matter how many units there are.

I'm not saying buckets are absolutely better. But in case there are lots of units, I think it is better. Perhaps, just like what everyone said, Nest' DDS wants to achieve the best performance when dealing with lots of units. And I tend to do the same.

 

[Bribe]

You wouldn't even feel an op limit crash if the operations were so light (and this would not hit the op limit with 1000 units).

What I could do is gradually build a (disabled) replacement trigger if there are more than X units needing to be indexed, and then when all events are filled destroy the old one and point the variable to the now-ready new trigger, and even that would be a better approach than buckets.

BTW, I call them that since that is how Nes introduced them to me.

 

[Wietlol]

I used simple Group enums from the entire map (filters out locusted units but those cant really be damaged anyway) and use FirstOfGroup iteration and add the units to the DDS.
It works in a blink of an eye with 3k units.

 

[looking_for_help]

PDDS also just uses a periodic timer to refresh the trigger. I did some benchmarks back then and the refresh "spike" was hardly even measurable. With thausands of units the frame dropped from 60 to 59 during the refresh - however that happens even during normal gameplay. And if there are several 100 units on screen the game has a very low performance anyway, so the scenarios where it would matter are purely theoretical...

But I think its also ok to use more complex algorithms (like the bucket technique) if one wants too. I don't think its neccessary, but I also don't see anything bad about this.

 

[Bannar]

Exactly. In order to provide healthy game experience, mapper usually needs to take into consideration many factors. Unit count is one of the major ones. Warcraft3 wasn't made to enjoy battles of hundreds of units. Maps which do enable such features (e.g Azeroth Wars) are usually very laggy towards the end.

None wants that. If the given system achieves its goals while also not harming player's experience, then there is nothing wrong with its approach.

 

[Almia]

sooooo...... what's going on here

 

[Kazeon]

Since I need this DDS on one of my resource, I'm going to work on this again.

Before checking if damage is physical or spell, rule out a zero damage event

Is it a must? User can easily use DamageAmount == 0 to detect it. The DDS does not particularly support that feature.

The user should be able to detect if it was spell damage AND be able to set a custom damage type to the damage before dealing it. This way, you can manually trigger damage you want to be physical or spell without worrying about not being able to track the user-defined damage type on top of that.

Do you mean to allow the user to assign a custom damage type? I saw it on your DDS and I think it's a nice feature. I will add it later but it's rather optional I think.

I will fix the rest.

 

[edo494]

so anything done about this?

Also, I dont know if this can ever be successful, because we already have:
GUI DDS, 2 actually
Jass DDS
vJass DDS(3)
Overly complex and shitton of dependencies in vJass

The domain is overfilled at this point, so unless this provides some magic that nothing did before, I dont know if its "needed". Why dont you contact one of the creators of one of the other DDSs and ask or suggest how to implement features you want in them, but they dont have?

 

[IcemanBo]

The work together with indexer seems a good point, and to allow single unit events.

The/one after damage registration is not there? As I understood it should be part of modern dds systems as the user can easy have functions to manipulate damage, and then other functions to only correctly (for example display/texttag) getting damage, or make reactions, related on damaged amount.

I respect that it's GUI friendly, but I from my opinion it doesn't really fit the JASS section so good, just already because it mainly works with "udg_"s. From jass section the resources should be more straight forward to use, usually being technicaly able to just copy the code for usage (if you dont wanna test the demo or so). But working with udg_ primaly here, I don't know, hm. It makes me more the feeling for Spells Submissiona next to Bribe's one, too.

What was with this locust swarm discussion, btw? Can't see a post related to it after mentioning, or no note to change a value.

I know this all comes very late, sorry. I'm also back (as reviewer) for like a half year in jass section, and there were just also very much other things back then. ;s : )

 

[MyPad]

Oooh, subbing to this..

 

[IcemanBo]

@Quilnez , could you chip in how your relation to this is, at the moment? In case, we should also have Flux's [vJASS] - DamagePackage as one reference.

 

[IcemanBo]

Quilnez seems busy, gy for now.