Event Values Fix

[Absolutionism]

Description

This PR aims to fix and update Event Values. (dev/patch branch)

• For the PlayerDropItemEvent and PlayerPickupItemEvent using event-entity was throwing a parse error of multiple entities which should not be the case. The easy solution to this was to register an Entity value directly to these classes. Though in their corresponding SkriptEvents they are paired with their Entity counterparts, inside EventValueExpression#init only the Player event was being accessed.

• Adds the #setTime into ExprEntity which utilizes EventValueExpression#setTime allowing past and future event-%entitydata% resulting in the fix of not being able to grab the future event-entity in ItemMergeEvent

• Adds a new method within EventValues, #stripConverters

/*
In this method we can strip converters that are able to be obtainable through their own 'event-classinfo'.
For example, PlayerTradeEvent has a player value (player who traded) and an AbstractVillager value (villager traded from).
Beforehand, since there is no Entity value, it was then grabbing both values as they both can be casted as an Entity
	resulting in a parse error of "multiple entities"
Now, we filter out the ones that can be obtained using their own classinfo, such as 'event-player'
	which leaves us only the AbstractVillager for 'event-entity'
 */

Though the PlayerTradeEvent could have easily been fixed by changing the valueClass of the registered event value from AbstractVillager to Entity (dont know why it's like that in the first place, as we dont register a class info for abstract villager)
However, I believe this addition can be beneficial.

• Finally, adds an EventValues.sk test which sole purpose is to look for parse errors.
  Had to fix EffDetonate.sk because EffSecSpawn.lastSpawned was being overwritten by the dropped items that spawned.

• Also changes variable names within EventValues to match what they are

---

Target Minecraft Versions: any
Requirements: none
Related Issues: none

[sovdeeth]

This sounds good and looks alright from a skim. I'm worried about the delegate function though. If a Player value is registered (assume it's the only event-value for this event), does it still allow event-entity to point to the Player?

[Absolutionism]

If a Player value is registered (assume it's the only event-value for this event), does it still allow event-entity to point to the Player?

Yes, the #delegateConverters method will only attempt if there were two or more converters found.
So in the instance that only a Player value is registered but we're looking for an Entity then it will successfully return the Player.
More than likely being because only one converter was found.

I also have it to where the method is only used after the first and second loops, as those loops are what covers the #hasMultipleConverters and relies on using the converters provided when registering an event value and not the loops that check for registered Converters.

[sovdeeth]

wonderful work