🛠 Fix keep inv/exp and other bugs related to death event

[AyhamAl-Ali]

Description

This bug was due to the change of how isCurrentEvent works (no super class support)
A simple change in init method to use EntityDeathEvent (super class) instead of PlayerDeathEvent while keeping the check for PlayerDeathEvent in execute method

---

Target Minecraft Versions: All
Requirements: None
Related Issues:

• Can't use 'keep inventory' or 'keep experience' #5657

[TheLimeGlass]

Well it does this because the death event Skript registers is the entity death event. I don't know if this is the correct approach to this fix.

If no player is even involved in the event, it'll be misleading. Like on death of pig and attacker is not a player. This will not error at parse time, but will not work at runtime leading people to believe it may be broken.

[AyhamAl-Ali]

Did it error at parse time before with the case you mentioned?
If you have another solution let me know.

[TheLimeGlass]

Did it error at parse time before with the case you mentioned? If you have another solution let me know.

It wasn't a default expression before, so it never had to grab from the event.

A solution could be reading from the event, it's all a literal so it'll be able to figure out if the entity type "should" be that literal.
Another could be actually getting Skript to use the PlayerDeathEvent rather than EntityDeathEvent when it comes to a player.

[AyhamAl-Ali]

default expression

How is it a default expression now? nothing has changed except the check in init method

As for the event check it didn't error at parse time before because the event is indeed registered as EntityDeathEvent and the code can't know if it's PlayerDeathEvent until runtime.

In addition to that, you can't know if the victim is player in init, even if you check for event params, it means nothing because users might use inner conditions to check for victim is player

The current simple check for PlayerDeathEvent in execute method is enough to not throw any errors.

[TheLimeGlass]

I find #5663 to be a superior solution.

[AyhamAl-Ali]

I find #5663 to be a superior solution.

I agree with Pickle's comment, therefore this solution (this PR) is better, is not a breaking change and more reliable that hardcoding exceptions

[Moderocky]

Good