1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. The 15th Mini-Mapping Contest came to an end. The Secrets of Warcraft 3 are soon to be revealed! Come and vote in the public poll for your favorite maps.
    Dismiss Notice
  3. The 12th incarnation of the Music Contest is LIVE! The theme is Synthwave. Knight Rider needs a song to listen to on his journey. You should definitely have some fun with this theme!
    Dismiss Notice
  4. Join other hivers in a friendly concept-art contest. The contestants have to create a genie coming out of its container. We wish you the best of luck!
    Dismiss Notice
  5. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

[Solved] Damage Detection [WURST]

Discussion in 'Triggers & Scripts' started by Lake, Mar 18, 2019.

  1. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    I'm getting some "interesting" results, when I make use of the GetEventDamage() together with the pretty cool damage libraries in Wurst.

    The problem seems to be that the DamageTypes library, sometimes makes extra damage calls, which are also being registered by the DamageDetection. It results in my personal function, which is triggered by the DamageDetection, to detect these damage events with insanely high damages.

    Anyone knows of a way to reliably get the amount on damage on a damage event? I feel like I'm missing something crucial here... Otherwise it seems to me that the DamageTypes system breaks most of the functionality of the DamageDetection libarary.



    Extra...
    I believe these are the sources of the extra high damage:
    upload_2019-3-18_21-42-2.png

    I could of course just filter out these super high damages for a temporary solution, but it just seems a bit like a "duckt tape"-solution.

    Any help or ideas would be lovely.
     
  2. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    Did you read the damage type doc? Once you import DamageType, it applies runes bracers to units to detect spell damage.
    It also means, that in every other time you are listening to damage events, you need to check for the type. There are some quirks, like spell damage being negative. If you check the type and ignore null and other unwanted sources, you shouldn't get any weird values.
     
  3. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    Yes, read it several times, to see if I was missing something. All I could see was the mentioning of importing detection if you use types.
    Didn't see that it was mentioned that you should check for the damage types if you make use of the library. Perhaps it's just me...
    But it seems like this will fix all the weird troubles I've been running into with this - then I can happily keep using the library

    I'll try and implement it tomorrow and see how it goes - heading off for now.

    Oh, and btw: when using the dealCodeDamage() method, it doesn't seem possible to get the damage amount. It's always just 0? Perhaps this will be solved by the other fixes as well. Ill look into it tomorrow
     
  4. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    The doc can surely be expanded. Actually we want a new dmg system but trokkin didnt finish yet.
    Not sure what other fixes you mean. If you think something isn't working, please provide a reproducible example.
    So far I am using DamageType in a map and did not experience what you described.
     
  5. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    Yeah, I saw that something was underway on GitHub ;)

    Yeah, sorry about that :D I made a replicable example here:

    So I just created a completely new map, and put this code in there:

    Code (Text):

    package Hello

    import UnitIndexer
    import DamageType
    import DamageDetection
    import Assets


    let source = createUnit(Player(0), UnitIds.rifleman, vec2(-1000,-1000), angle(0))
    let target = createUnit(Player(0), 'hfoo', vec2(-1000,-1000), angle(0))

    function dealDamage()
        dealCodeDamage( source, target, 50. )
     

    function unit.getIndexName() returns string
        return this.getName() + " " + this.getIndex().toString()

    init
        CreateTrigger()
        ..registerPlayerChatEvent(Player(0), "test", true)
        ..addAction( function dealDamage )

        addOnDamageFunc() ->
            if getDamageType() == DamageType.CODE
                let damage = GetEventDamage()
                print( GetEventDamageSource().getIndexName() + " dealt " + damage.toString() +" damage to "+GetTriggerUnit().getIndexName() )
     
    Intuitively this would print that the rifleman damaged the footman for 50 damage. However, this happens:

    upload_2019-3-19_7-48-2.png

    The damage is working alright, but the GetEventDamage() returns 0, which is a bit inconvenient. The source of the problem is pretty apparent, when seeing this:

    upload_2019-3-19_7-49-5.png

    It's not actually "damaging" the target, but rather adjusting it's HP and doing a 0 damage call, to trigger the on-damage-actions.
    The fix seems pretty simple, so if it's not the case that I've missed something, then I'll make a pull request on a quick fix ;)

    EDIT:
    So I've just realized that it would make sense, if the deal code damage wasn't meant to be used outside the library. Because then you would only face scenarios, where you'd deal negative damage (spell) or postive damage (basic attack?).
     
    Last edited: Mar 19, 2019
  6. Cokemonkey11

    Cokemonkey11

    Wurst Reviewer

    Joined:
    May 9, 2006
    Messages:
    3,224
    Resources:
    18
    Tools:
    1
    Maps:
    5
    Spells:
    3
    Tutorials:
    2
    JASS:
    7
    Resources:
    18
    I haven't touched this in a very long time, but I suspect your intuition might be right.

    Possible bug source is just: no one using code damage ever needed to check event damage.

    And possible explanation for bad code is: double protection against accidentally registering code damage as DamageType.ATTACK
     
  7. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    I reckon you're right. I tried to look into it, and see if I could make a simple implementation of a getDamageAmount() function, but the code is pretty intertwined and I think it would be too much effort. But I figured a work around in my map design, such that I can use the current system. So I'm not going to bother coming up with a fix, if the entire system will be updated any way. :)
     
  8. Wareditor

    Wareditor

    Joined:
    Jan 16, 2009
    Messages:
    679
    Resources:
    2
    Maps:
    2
    Resources:
    2
    The package in the standard library isn't up to date with the new native.
    I am using this instead. it's not yet properly finished to submit it but it works just fine if you don't care about detecting native spells (you can implement that if you want - the code is pretty simple).
     
  9. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    Issue, PR?....
     
  10. Wareditor

    Wareditor

    Joined:
    Jan 16, 2009
    Messages:
    679
    Resources:
    2
    Maps:
    2
    Resources:
    2
    @Frotty As I said, it's not ready to submit for PR.
     
  11. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    Cool, thanks for sharing your work! Though, I think I'll try and run with this somewhat akward solution I've got going on now. If it ends up failing, I'll fall back to yours, definitely!

    May I, btw, I'd suggest some simple functions to make use of your use of you system (such as addOnDamage()) using closures). It'd make it simpler to use I reckon. That is of course of even intend for others to use it
     
  12. Wareditor

    Wareditor

    Joined:
    Jan 16, 2009
    Messages:
    679
    Resources:
    2
    Maps:
    2
    Resources:
    2
    @Lake DamageEvent.addListener() does that. You can wrap it as you want.
     
  13. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    Yea you wrote that. It doesn't need to be ready to make an issue about the current package.
    Also WIP PRs are very common practice? Seems pretty selfish to say "oh yeah, I know it's broken, but not gonna report"..

    Anyway, it seems like the fixes already were made in the DmgModify PR but since part of big PR never merged.
    @Lake can you try this version of DamageType: wurstscript/WurstStdlib2
    If it works I will merge that part.
     
  14. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    Yeah, I'll try and look at it this evening :)
     
  15. Wareditor

    Wareditor

    Joined:
    Jan 16, 2009
    Messages:
    679
    Resources:
    2
    Maps:
    2
    Resources:
    2
    @Frotty We already talk about the issue a few months back so I thought it was common knowledge but I should have made an issue.
     
  16. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    Nice, thanks :)

    Alright, maybe I missed out on that or forgot. No prob.
    Are you interested in committing a PR though, or is it more private lib?

    Cheers
     
  17. Lake

    Lake

    Joined:
    Mar 5, 2015
    Messages:
    135
    Resources:
    0
    Resources:
    0
    @Frotty I didn't work. Tried to apply it to the replicable example above, and it didn't fixe the problem. I can see there is a difference in the code, but can see where that difference is. No difference in the outcome
     
  18. Frotty

    Frotty

    Wurst Reviewer

    Joined:
    Jan 1, 2009
    Messages:
    1,397
    Resources:
    11
    Models:
    3
    Tools:
    1
    Maps:
    5
    Tutorials:
    1
    Wurst:
    1
    Resources:
    11
    Alright then I will hope for @Wareditor 's PR to solve this :S
     
  19. Cokemonkey11

    Cokemonkey11

    Wurst Reviewer

    Joined:
    May 9, 2006
    Messages:
    3,224
    Resources:
    18
    Tools:
    1
    Maps:
    5
    Spells:
    3
    Tutorials:
    2
    JASS:
    7
    Resources:
    18
    What is changed in the new native?
     
  20. Wareditor

    Wareditor

    Joined:
    Jan 16, 2009
    Messages:
    679
    Resources:
    2
    Maps:
    2
    Resources:
    2
    @Cokemonkey11 You can change the damage amount directly before its applied without using the old tricks