Several damage causes compare incorrectly

[jaylawl]

Description

Damage cause enums get mixed up with other stuff (poison, wither, thorns, unknown)

Steps to Reproduce

Simply put this in skript and reload it

on damage:
    damage cause = contact
    damage cause = attack
    damage cause = sweep attack
    damage cause = projectile
    damage cause = suffocation
    damage cause = fall
    damage cause = fire
    damage cause = burning
    damage cause = melting
    damage cause = lava
    damage cause = drowning
    damage cause = block explosion
    damage cause = entity explosion
    damage cause = void
    damage cause = lightning
    damage cause = suicide
    damage cause = starvation
    damage cause = poison
    damage cause = potion
    damage cause = wither
    damage cause = falling block
    damage cause = thorns
    damage cause = dragon's breath
    damage cause = unknown
    damage cause = hitting wall while flying
    damage cause = magma
    damage cause = cramming
    damage cause = dryout

Errors / Screenshots

https://snag.gy/O6Cr8n.jpg

Server Information

• Server version/platform: paper 1.13.2
• Skript version: 2.3.6

[TPGamesNL]

I think this is the same as #551

[TheBentoBox]

Given this one is much newer, more specific, and uses the issue template, I'll close #551 in favor of this.

[ShaneBeee]

I think this also ties in with #1832

[TheBentoBox]

It does relate to the same root issue with comparators but I think it's best to track the different resulting issues separately.

[TheLimeGlass]

Problem is Skript doesn't check names of ClassInfo's like %entitydata%, just the ClassInfo's class. I talked about this in the dev chat https://discordapp.com/channels/138464183946575874/358658268341731329/620373491660881920

[FranKusmiruk]

@TheLimeGlass as I have responded before, the only issue here is the fact that Skript is parsing the objects independently. So, when Skript parses both event-damage cause and thorns; one is of course a damage cause and the other is a literal, when Skript tries to parse this literal the first match is an enchantment, thus the comparison failing since they're not of the same type.

If I had to guess, a fix for this would be implementing a special parsing when it comes to comparison, it could be done by handling the expressions used at initialization, so, something like a beforeInit API would do it.

[ShaneBeee]

Closing this in favour of #2637
There are many issues on the tracker all stemming from this one big issue, so I wanted to condense this into one larger issue.