[Solved] Damage Detection [WURST]

[Lake]

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:

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.

 

[Frotty]

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.

 

[Lake]

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

 

[Frotty]

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.

 

[Lake]

The doc can surely be expanded. Actually we want a new dmg system but trokkin didnt finish yet.

Yeah, I saw that something was underway on GitHub

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.

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

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

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:

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:

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?).

 

[Cokemonkey11]

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

 

[Lake]

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

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.

 

[Wareditor]

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).

 

[Frotty]

The package in the standard library isn't up to date with the new native.

Issue, PR?....

 

[Wareditor]

@Frotty As I said, it's not ready to submit for PR.

 

[Lake]

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).

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

 

[Wareditor]

@Lake DamageEvent.addListener() does that. You can wrap it as you want.

 

[Frotty]

@Frotty As I said, it's not ready to submit for PR.

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.

 

[Lake]

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

Yeah, I'll try and look at it this evening

 

[Wareditor]

@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.

 

[Frotty]

Yeah, I'll try and look at it this evening

Nice, thanks

@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.

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

 

[Lake]

@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

 

[Frotty]

@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

Alright then I will hope for @Wareditor 's PR to solve this :S

 

[Cokemonkey11]

The package in the standard library isn't up to date with the new native.

What is changed in the new native?

 

[Wareditor]

@Cokemonkey11 You can change the damage amount directly before its applied without using the old tricks