It's not guaranteed that objects provided are the same as those in the enum registry, so they can't be directly compared.
Implementing comparison with === would require some kind of __equals() implementation or an extension to hook into such functionality.
these functions belong in the network session, and they are currently just proxies for them. In the future we might have players who don't have IPs at all depending on how they connected (for example Specter) so this stuff shouldn't be in here.
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.
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.
For many years, this has been the cause of many users (particularly plugin devs) confusion. The reality is that /reload has little to no practical value. It does not reload plugin source code (contrary to popular belief).
This introduces static getters for every currently-known effect type. At some point in the near future, the magic number constants (which are really network IDs, by the way) will disappear.
Migrating:
- If you used constants (like any sensible person would): for the most part it's just a case of adding a () anywhere you used an Effect constant.
- If you hardcoded magic numbers: ... well, have fun fixing your code, and I reserve the right to say "I told you so" :)
This achieves multiple goals:
1) creating an EffectInstance for application is much less verbose (see diff for examples, especially the Potion class)
2) plugin devs cannot use magic numbers to apply effects anymore and are forced to use type-safe objects. :)
This is a warning shot for plugin devs who use magic numbers. More changes like this are coming in the not-too-distant future.
