the intent of this was noble (to make sure nothing was missed), but in practice throwing
errors on this stuff is just a pain in the ass. We don't actually need to care if the
properties are not used, since it doesn't affect the decoding (like it would for
a missing packet field), so the only reasons to complain are for BedrockProtocol to
have a complete picture of the protocol, and to make sure we're not discarding useful
information.
Log a warning in these cases instead, which should be noticed by developers without
being an unnecessary problem for users.
closes#6816
if the prediction was a fail, we can assume that the client didn't do anything visual on its end,
which avoids the need to resend blocks.
This fixes block lag when towering as discussed in #6803.
The more general issue in #6803 remains unresolved (that the server's block resyncing may overwrite
additional client side predictions if it places a block before the server's resync for the initial
placement arrives), but that's more complicated to fix and I'm not convinced on the correct method
to resolve it yet.
In any case, this change nets a decent improvement for everyone, regardless.
* Deprecate BaseSign get/set/updateText(), add get/set/updateFaceText() which accepts true/false for front/back
* add isFrontFace() to SignChangeEvent
* add optional frontFace to Player::openSignEditor()
* add BaseSign::getFacingDegrees() and getHitboxCenter() which need to be implemented by subclasses
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 field was added to the action in 1.21.20. Previously, the client would behave as if clicking the crafting result slot many times. Now it behaves more like recipe book shift-clicking.
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.
in particular, the information from VerifyLoginTask shouldn't be sent to clients, as it could contain sensitive information.
This change only affects disconnection screens. The server log shows the same amount of information as before (though formatted differently in some cases).
