MS is due to remove the non-server-auth versions of all of this stuff.
Fortunately v3 server auth movement works just fine without any changes,
although we will need to start sending player tick in some packets if
someone wants to actually use the rewind stuff.
* Bedrock 1.21.80 support
* Update bedrock-data
* Add required tags to models
* Fixed biome data loading
* Support newest world format
apparently I messed up the blockstate data version last time around... it hasn't changed since 1.21.60
* always CS has to complain...
* Sync with release versions
* Ready 5.28.0 release
* this might help...
---------
Co-authored-by: Dylan T. <dktapps@pmmp.io>
This binds internal sneaking to whether or not the player is currently pressing the shift key, which fixes#5792 and fixes#5903.
However, it does introduce visual issues with sneaking, as explained in #6548. This needs to be worked on separately. For now, it's better we trade 2 functional bugs for 1 visual bug.
Support for more advanced stuff like NBT copying wasn't added in this PR, as the NBT used by PM is currently an inconsistent mess and doesn't play nice with vanilla. In the interests of avoiding this mess propagating, it's been left for another time.
Adds PlayerEntityPickEvent a la PlayerBlockPickEvent
and Entity->getPickedItem().
This allows, for example, banning the usage of spawn eggs, without preventing opening of doors, without the need for item ID whitelists.
It also allows customizing the behaviour of item and block interactions when sneaking - it's now possible to force spawn eggs to work when sneaking, or force containers to open.
Finally, this also allows preventing any interaction at all without preventing block placement (by setting both to false). Since cancelling the event will typically prevent placement too (which might not be desired).
Side note: Blocks are now always synced when right-clicking on a block.
This differs from the previous behaviour, where the blocks were only synced when the action "failed".
However, since this change introduces a situation where the action may succeed but have different results than the client expects, it's best to just always sync blocks in this situation.
Fixes#3267
this is a pain :(
It appears the client always sorts the keys in alphabetical order due to use of std::map. However I'm not sure of the exact ordering behaviour, so it needs to be investigated.
This allows better compensation for floating point errors introduced by the subtraction of the 1.62 height offset.
For example, if the player is at y=7 exactly, their Y coordinate will be reported as 8.62, which, because of floating point errors, will be something like `8.619999999`. Subtracting `1.62` from this (really something like `1.62000000000005...`) leads to the calculated Y coordinate being slightly below 7.
Rounding after subtracting this offset allows this to be rounded to 7 sharp. Similar errors appear in various other coordinates.
there's a bunch of places we can't reach with this right now:
- particles
- sounds
- tile NBT
- entity metadata
- crafting data cache
- chunk encoding
- world block update encoding
this is a work in progress, but ultimately we want to get rid of these singletons entirely.
this doesn't support editing the rear side of a sign, since the 1.12 format doesn't allow us to represent the rear text, and it would necessitate API breaks to support anyway.
However, we can quite trivially support APIs for the sign GUI, which plugins can use to enable editing signs. PocketMine-MP doesn't currently permit this, since it's currently an experimental feature in 1.20, but plugins can simply use Player->openSignEditor() to mimic it.
This is, however, a byproduct of the fact that APIs needed to be added in order to facilitate the use of OpenSignPacket in 1.19.80.
due to implementation quirks + some unforeseen ways these actions can behave, there can be as many as 53 actions in a single crafting request. This is an edge case, but it has to be catered for.
for some reason book edits generate a transaction in addition to BookEditPacket. PM has never used the transaction, and it doesn't pass anyway because CreateItemAction can't be used in survival mode.
However, since the strict validation introduced since ItemStackRequest, this dud transaction now causes the player to get kicked without these changes.
