given that inventory listeners are no longer allowed to fiddle with the outcome of changing contents, it's now possible to allow having multiple listeners receiving events.
It's likely that this will be used for network inventory sync in the near future.
there is nothing that these events do that can't be fulfilled by transactions. They complicate the internal implementation and produce unexpected behaviour for plugins when cancelled.
TL;DR: Use transactions. That's what they are there for.
the checks removed here should never be hit under normal circumstances. If they were hit, they'd just conceal bugs which would cause a crash to happen later anyway.
there's nothing that can be done with this event that can't be done with EntityTeleportEvent. Having this extra event needlessly increases system complexity.
This has been a pain point for a long time due to the misleading nature of the name "level". It's also confusing when trying to do things like getting the XP level of the player or such, and also does not translate well to other languages.
This transition was already executed on the UI some time ago (language strings) and now it's time for the same change to occur on the API.
This will burn a lot of plugins, but they'll acclimatize. Despite the scary size of this PR, there isn't actually so many changes to make. Most of this came from renaming `Position->getLevel()` to `Position->getWorld()`, or cosmetic changes like changing variable names or doc comments.
This opts _not_ to expose item "age" a la #2753 because "age" is a misleading term for it. In addition, further inspection of the problem led me to realize that exposing control of that AND despawn timeout was more complicated than simply having a despawn delay timer exactly like the pickup delay one. Everyone knows a countdown timer stops at 0, so this way we don't need any method to control the limit.
Closes#2667Closes#2753
This is similar in nature to 646fea5a4ecbbdf3f0cbfc590d874dedc1a7bfc0.
On a side note: Migrating this way is a pain in the ass due to lack of types. What the heck is int supposed to mean?!?!?!?! At least if we wanted to go _back_ to magic numbers, it would be easy to locate everything with an Enchantment typehint...