Warning for plugin developers: This is a silent BC break. It won't raise any errors.
This alters the default behaviour of event handlers to **not** receive cancelled events by default.
It is now required to opt into receiving cancelled events by using the @handleCancelled directive (or the handleCancelled parameter where it's appropriate).
The ambiguous @ignoreCancelled directive is now ignored.
Ramifications:
- The majority of handlers with `if($event->isCancelled()) return;` no longer need such checks.
- Handlers with `@ignoreCancelled true` or `@ignoreCancelled` annotations can have them removed.
- Handlers which want to receive cancelled events need to use `@handleCancelled`.
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.
the timeout was entirely useless, because:
- when shorter than 25.6 seconds (512 ticks) it would cause caches to be needlessly destroyed and regenerated
- when longer than 25.6 seconds, just made outdated caches persist for longer, even after the query info was regenerated.
This now uses a mark-dirty model to deal with caches, which means that plugin modifications to the query data will be reflected immediately, regardless of when they are made. Previously, modifying the result of Server->getQueryInformation() would have inconsistent results.
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.
This prevents plugins sending wrong packets at the compiler level (or would, if we had a compiler). It's more robust than a getter for client/server and throwing an exception since a static analysis tool can detect faults created by sending wrong packets from the server. This is also used to deny service to dodgy clients which send wrong packets to the server to attack it.
this is in preparation for clientbound/serverbound packet separation. I did this already on another branch, but the changeset was dependent on a massive refactor to split apart packets and binarystream which i'm still not fully happy with.
This is better for performance because these then don't need to be reevaluated every time they are called.
When encountering an unqualified function or constant reference, PHP will first try to locate a symbol in the current namespace by that name, and then fall back to the global namespace.
This short-circuits the check, which has substantial performance effects in some cases - in particular, ord(), chr() and strlen() show ~1500x faster calls when they are fully qualified.
However, this doesn't mean that PM is getting a massive amount faster. In real world terms, this translates to about 10-15% performance improvement.
But before anyone gets excited, you should know that the CodeOptimizer in the PreProcessor repo has been applying fully-qualified symbol optimizations to Jenkins builds for years, which is one of the reasons why Jenkins builds have better performance than home-built or source installations.
We're choosing to do this for the sake of future SafePHP integration and also to be able to get rid of the buggy CodeOptimizer, so that phar and source are more consistent.
This allows plugins to more easily control the behaviour of server-full, whitelisting and banning. A message can be assigned for each, with a plugin custom reason taking the final priority if set.
This system solves several edge case problems in the Bukkit version by allowing kick reasons to be combined, so that removing one kick reason will roll back the final reason to the next highest, instead of just allowing the player through completely.
Only one message will be shown at point of disconnection, for consistency with the old behaviour.
The message priority is as follows (for all cases, only if set):
- Plugin reason
- Server full
- Whitelist enabled
- Player is banned
This also brings us one step closer to separating Player and NetworkSession.
Previously the only way to deal with this was to cancel the PlayerKickEvent generated by lack of authentication. Now, plugins can decide whether auth should be required for a specific player. The default is whatever xbox-auth is set to in server.properties.
cc @Johnmacrocraft
