This was observed in a recent crashdump where a plugin triggered a recursion error, but the stack trace did not contain any sign of a recursive event call. I conclude that this must have been caused by previous event handlers triggering errors 50 times in order to make the recursion detection break, because the recursion detection did not decrement the counter in cases where an exception was thrown.
This check is completely unnecessary since handlers get unregistered when a plugin is disabled. Additionally, this is an extremely hot path and this change produces a modest 5% performance improvement to event calls.
This is dependent on the changes made in b1e0f82cbf. This now makes it possible to call events without fetching a Server reference, allowing to eliminate a vast array of Server dependencies.
* Added a new PermissionManager, remove ridiculous cyclic dependencies of Permissions on Server
Aside from all the other ridiculous design problems with the permission system, the biggest problems are its API. This is, once again, a result of poor API design copied from Bukkit.
This pull request removes all permission-related functionality from `PluginManager` and moves it to the `pocketmine\permission\PermissionManager` class.
As can be observed from the removed code in the diff, the permissions system was previously entirely dependent on the Server, because it needed to get the PluginManager for registering permissions. This is utterly ridiculous. This refactor isolates _most_ permission-related functionality within the `permission` namespace.
As mentioned above, this stupid API is a direct result of copying from Bukkit. If you look at the API documentation for Bukkit for `PluginManager` you will see that the methods I'm deprecating here are also in there.
## Changes
- Added a new `PermissionManager` class. This can be accessed via its singleton `getInstance()` static method.
- Deprecated the following `PluginManager` methods - these will be removed no later than 4.0.0:
- `getPermission()`
- `addPermission()`
- `removePermission()`
- `getDefaultPermissions()`
- `recalculatePermissionDefaults()`
- `subscribeToPermission()`
- `unsubscribeFromPermission()`
- `getPermissionSubscriptions()`
- `subscribeToDefaultPerms()`
- `unsubscribeFromDefaultPerms()`
- `getDefaultPermSubscriptions()`
- `getPermissions()`
PhpStorm can't see these or understand how they are being called, which is very annoying for bug hunting. Additionally, we already have the CodeOptimizer for this.
Totem usage can be detected using the MODIFIER_TOTEM constant of EntityDamageEvent.
This does not currently support using the totem in the offhand because offhand is not implemented yet.
The general purpose of this is to split up base damage from modifiers.
- Added methods getBaseDamage(), setBaseDamage(), getOriginalBaseDamage(), getModifiers(), getOriginalModifiers()
- setDamage() renamed to setModifier() and type is now mandatory
- getDamage() renamed to getModifier() and type is now mandatory
- getOriginalDamage() renamed to getOriginalModifier() and type is now mandatory
- Removed MODIFIER_BASE constant
- Constructors now accept: float baseDamage, float[] modifiers instead of just float[] modifiers
This commit brings in a much-needed rewrite of crafting transaction handling.
The following classes have been removed:
- CraftingTransferMaterialAction
- CraftingTakeResultAction
The following classes have significant changes:
- CraftingTransaction
- All API methods have been removed and are now handled in CraftItemEvent
- CraftItemEvent
- added the following:
- getInputs()
- getOutputs()
- getRepetitions() (tells how many times a recipe was crafted in this event)
- Recipe interface:
- Removed getResult() (individual recipes may handle this differently)
- CraftingRecipe interface
- removed the following:
- matchItems()
- getExtraResults()
- getAllResults()
- added the following
- getResults()
- getIngredientList() : Item[], which must return a 1D array of items that should be consumed (wildcards accepted).
- matchesCraftingGrid(CraftingGrid)
- ShapedRecipe
- constructor now accepts string[], Item[], Item[]
- ShapelessRecipe
- constructor now accepts Item[], Item[]
* Event handlers always handle subclass events. public static $handlerList no longer required.
* Removed $handlerList declarations
* HandlerList cleanup: Removed HandlerList->handlers and related bake methods
* Removed obsolete Event->getHandlers()
* EventPriority: Added fromString()
* PluginManager: throw exceptions on registering handlers with invalid priorities
This allows specifying a handler of `EntityDamageEvent` which will handle any instanceof it (as per current behaviour), AND also now allows specifying a handler specifically for `EntityDamageByEntityEvent`, which only handles `EntityDamageEvent`.
This was not previously possible due to limitations in the way handlers were registered.
Abstract events may not be handled unless they declare the `@allowHandle` PhpDoc tag.
This now removes the need for recursing around for structures comprised of multiple blocks. Instead, override getAffectedBlocks() to return all blocks that need to be deleted when the current block is deleted, and make sure that only one half of the block drops something. When a player breaks one of the blocks, all the blocks affected by that block will also be destroyed, creating particles and sounds where appropriate.
This fixes creative drops for double plants and beds.
* Removed broken EntityEatEvents - these don't fit the pattern since they only apply to Human entities anyway. PlayerItemConsumeEvent and PlayerInteractEvent can be used for cancellation purposes, and plugins can do custom stuff without mess.
* Restrict item consuming to Living entities only
* Added FoodSource->requiresHunger()
* Only items implementing the Consumable interface can now be consumed.
* The effects from consuming items are now generic-ized by way of the Living->consume() function. This is overridden in Human to allow applying food and hunger.
* Fixed the hardcoded mess for buckets
