This solves the age-old issue of PlayerInteractEvent firing twice when a player clicks a block with an item in the hand.
API changes:
- Removed PlayerInteractEvent constants LEFT_CLICK_AIR, RIGHT_CLICK_AIR and PHYSICAL.
- PlayerInteractEvent no longer fires when the player right-clicks the air.
- Added new event PlayerItemUseEvent.
- Don't allow the same window ID to be used when another window is already using it
- Detect window ID collisions when selecting IDs for regular containers (should never happen, but anything is possible)
this was causing any items set into the hand during these events _at all_ to get overwritten, rather than just tools. That's a bit of a problem for buckets because buckets rely on a bad hack to handle the modified items.
This doesn't fix the tools bug, but that's a job for another time.
There's no implementation here yet, but that can come later. This lays the ground for allowing plugins to have an integrated method to send forms, as well as a solution to the ID conflict problem.
A built in implementation should not be a concretion and it should be able to be swapped for third party implementations. This enables the possiblity to do so.
Async compression and broadcasts are now reliable and don't have race condition bugs.
This features improved performance and significantly reduced bandwidth wastage.
Reduce Level broadcast latency by ticking network after levels. This ensures that session buffers get flushed as soon as possible after level tick, if level broadcasts were done.
this should never be called for a player with an empty username (because data isn't saved unless the player was spawned) and the instanceof is laughable.
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.
this should fix forms not working during PlayerJoinEvent, and also removes the spurious PlayerItemHeldEvent firing on spawn bug.
The player MUST now send this packet. Bots take note.
* 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()`
I considered renaming sendDataPacket() to dataPacket() to reduce the BC breaks, but the parameter set has changed, which might cause astonishing behaviour, so it's better to break it in a loud way. Also, this has a clearer name.
- 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
