players were switching from a weaker tool to a stronger one to get double knockback in PvP.
while it's intended that we don't cancel the second attack during hit cooldown if the damage is
higher (the first damage is subtracted to prevent doubling up), we don't want them to get double
knockback.
this behaviour now matches vanilla to the best of my observations.
Come at me PvP community... I know some people are going to hate this change
this ensures the greatest amount of consistency with vanilla.
in order to prevent the sounds being broadcasted on armor damage with the old method, we'd also have to sacrifice the sound when replacing one leather helmet with another, for example.
this approach minimizes the gameplay impact at the possible expense of plugins.
closes#6325
closes#6104
This function has been a footgun for anyone using it, since it also returns entity AABBs by default.
In all core use cases, this functionality was disabled, and we were paying a needless (admittedly micro) performance penalty for passing the extra useless argument and useless condition check.
'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
Perhaps this and EnchantOption should be called EnchantingHelper and EnchantingOption respectively. The terminology used is rather inconsistent, but 'enchantment' definitely isn't the right word here.
this produced a 40% performance improvement in a simulation with 800 item entities.
If the items were all different, then this would still be a problem. However, many of the same unstackable items occupying the same space is a problem for SkyBlock farms, so this should improve performance for SkyBlock quite a bit.
this was requested and PR'd as far back as 2020 (see #3782).
Since no issue was filed about this, it became forgotten until #5946.
However, #5946 overcomplicates the solution to the problem, and breaks BC without an obvious reason.
This occurs if the player had very high levels of Health Boost or other weird modifications.
It doesn't really make sense to apply damage modifiers to suicide anyway.
Really I'm doubtful that suicide should even be considered a damage type (perhaps we should add an EntitySuicideEvent), but that's a discussion for another time.
suicide damage is a voluntary damage source, which noDamageTicks is intended to prevent getting damaged while the player gets their bearings after (re)spawning.
fixes#5810
probably fixes#4986#5810 was caused by the workaround for #4394, which broke in 1.20 for reasons I'm still unclear on.
As FLAG_TELEPORT does not work at all for non-player entities, and causes bugs with player entities, sending the teleport movement without the flag is the least buggy way to solve all of these issues. Having the client interpolate teleport movements is not ideal, but there doesn't seem to be a way to reliably prevent it without causing even more bugs, so this will have to do.
this information will allow us to correct for any bugs introduced by past versions.
however, we still need to propagate this information to permit actually using it when loading data.
while I could implement server-side ability to disable entity movement, I don't think that's particularly useful. However, the intended function of this (disabling client sided AI) is useful, so it makes more sense to rename it to match its functionality, rather than changing its functionality to match the name.
closes#3130
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.
