This option should probably be removed as its a descendant of an option that allows "old tnt cannon" behavior before ~1.9 But this improves the fix so properly update the velocity/position rather than the questionable way it was doing it before.
This more properly implement spigot's fix for teleportation area effect clouds, now however supporting many other entity types specified in this bug report.
Currently, this is not an issue for (all) hanging blocks since they have a fix identical to this inside of setPos. Note however the client does not nicely support moving these entities anyways.
Previously we added a parameter allowing for level data to be saved asynchronously which was then overriden by a vanilla parameter which does the opposite.
This reverts back to the previous behavior that we were doing before.
Co-authored-by: Warrior <50800980+Warriorrrr@users.noreply.github.com>
Reimplementation of the itemstack obfuscation config that
leverages the component patch map codec to drop
unwanted components on items or replaces them with
sanitized versions.
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
Exposes the data component logic used by vanilla ItemStack to API
consumers as a version-specific API.
The types and methods introduced by this patch do not follow the general
API deprecation contracts and will be adapted to each new minecraft
release without backwards compatibility measures.
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.
