the same behaviour can be achieved by cancelling the event and setting the held item manually. Allowing this to be changed increases the complexity of dealing with survival block picking.
* 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()`
- Separated player handling and creation from network interfaces
- Rewire disconnects to make them not be recursive
- Batching now uses sessions instead of players
- Fixed DisconnectPacket getting sent to players who disconnect of their own accord
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.
