Because this exploit has been widely known for years and has not been fixed by Mojang, we decided that it was worth allowing people to toggle it on/off due to how easy it is to make it configurable.
It should be noted that this decision does not promise all future exploits will be configurable.
This is a lot but basically adds a method to disable the dropping of experience and drops experience by default.
This way things that require XP to be dropped manually (via modification), they can drop XP themselves when needed but without touching anywhere else that may drop xp.
It should be noted this causes breakNaturally() to now drop experience.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
cdfe62e4 Update to Minecraft 1.20.4
CraftBukkit Changes:
51eea725f Update to Minecraft 1.20.4
Spigot Changes:
ce0f71e4 Update to Minecraft 1.20.4
In general, the client now has an acknowledgment system that will cause block changes made by the client to be reverted correctly.
Essentially:
The client enters a "prediction" stage, where any block changes made will have its old blockstate captured (this is referred to as "server state").
If you update blocks during this stage, the client will update this captured server state as long as they're still currently predicting.
After prediction is done (via an ack packet) all captured blockstates are reverted to their captured server state.
This means that if the server actually updated a block and send a block update packet, it's correctly set, while if a block wasn't updated on the server but WAS updated on the client (server state wasn't updated), that change will be reverted.
It should be noted that this system does not yet support block entities, so those still need to be resynced when needed.
I discovered this when noticing that blocks broken outside of the player's valid interaction distance are still properly reverted, even though the server doesn't send any block updates, only an ack packet.
Minecraft now ticks signs in order to validate the playerWhoMayEdit field. This is a horrible idea, as this means that even waxed signs are ticked for essentially no reason. This moves the logic lazily onto the getter.
This fixes the bug causing canceling PlayerInteractEvent to cause items to continue to be used despite being canceled on the server.
For example, items being consumed but never finishing, shields being put up, etc.
The underlying issue of this is that the client modifies their synced data values, and so we have to (forcibly) resend
them in order for the client to reset their using item state.
* Rework dependency management (WIP)
* Revert "Rework dependency management (WIP)"
This reverts commit e046cd59c68743dc00303b1ab42317bf474abd6a.
* Correctly add soft dependencies to the dependency tree for classloading resolution
* Add support for new dependency config format
* Rebase
* swap load order meaning
* Dependencies should be required by default
Abstracts relative teleport flags and instead makes a generic TeleportFlag option. This has the benefit of being able to easily add new flags in the future.
This adds a new flag, which allows you to keep inventories open when teleporting players (vanilla behavior).
These are breaking changes to the teleport api, however, it's still marked as experimental so I find this a fair change.
Owen1212055