* Update adventure to 4.19.0
The update only includes a new configuration for MiniMessage,
specifically one to prevent it from emitting virtual components.
As virtual components break the generated component tree, items quickly
become unstackable with items generated before adventure 4.18.
Plugin developers may construct their own mini message instance which
will emit virtual components if they so choose.
* Bump to adventure 4.20.0
This reverts commit ab984a0711.
The block damage is null *and has been* null in cases where the block
has already been cleared. Consumers are supposed to use the
getDamagerBlockState instead.
Always passes the respective block to a damage source when passing a
block state. While we could technically use the damageSourcePosition
here by, we'd have to translate it back to a block position by
subtracting .5 from all its components.
Such behaviour however relies on the caller logic's mutation of the
damageSourcePosition and will break once this position is not the centre
of the block.
Passing in the block at the specific callsite is a lot more future
proof.
While the running server will still be using the recently introduced
copy-mechanic for vanilla command namespacing, the data converter logic
relies on the fact that namespaced aliases were redirects as well.
To not break the converted, the commands type now takes a modern flag
only set by the running server.
While the paper command system no longer uses redirects for namespaced
registration, vanilla still does. This means that removal of vanilla
redirecting target nodes still causes issues, e.g. the removal of the
vanilla 'msg' node in favour of a command alias one.
Redirecting nodes like tell, minecraft:msg and minecraft:tell are broken
by this and need to by flattened before sending them to the client.
Player info packets carry chat state to other clients since the
introduction of chat signatures. Queuing these packets while force
pushing chat packets allows for potentially inverted packet order, which
may cause chain corruption on clients.
Bukkits entity remove event is called at a different time than the
existing paper event, specifically it is called after an entity has been
stored during chunk unloads.
This means that, while the bukkit event can have a defined reason, it
does not allow modification to the entity data. In this regard it
differs from the paper implementation and prevents developers from using
the paper event as an alternative.
Co-authored-by: TonytheMacaroni <tonythemacaroni123@gmail.com>
The goal of the build workflow is split into multiple requirements.
1. Run on pushes to same repo.
2. Run on PR open/reopen/syncs from repos that are not the same
(PRs from the same repo are covered by 1)
3. Run on labeled PRs that have the build-pr-jar flag.
Prevent division by zero in Player#applyMending by simply using zero
instead if the divider itself is zero.
This matches vanilla behaviour in the sense that
ExperienceOrb#repairPlayerItems, which this logic is lifted from, does
pass zero to the enchantment helper and runs its first iteration on
repairing. Vanilla is not affected as the computation failing with zero
is used to compute the leftover exp value, which is not needed if zero
itself is passed in.
As the paper impl however exposes said value to the initial event, our
code needs to account for the zero division.
The existing logic in LivingEntity#checkTotemDeathProtection completes
by checking whether the death protection component is null or not.
In cases where the event was cancelled, the component needs to be nulled
out to prevent the method from returning true, causing the player to
properly die.
An incorrectly updated hunk attempted to remove the MobEffectInstance
from the active effect map instead of the Holder<MobEffect> as the
parameter name was changed from holder to effect during hardfork.
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:
ed0ec489 SPIGOT-7965: Unknown TransformReason for Hoglins
9db03457 SPIGOT-7964: Fix typo in Deprecation annotation
d14119af PR-1082: Add "since" to Deprecation annotations
e8a318d4 PR-1067: Add method to get Advancement requirements
CraftBukkit Changes:
40dd796db SPIGOT-7971: NotSerializableException on serialize CraftUseCooldownComponent
fa85c5e0a SPIGOT-7968: ProjectileHitEvent not trigerred when arrow hits entity
b75b792ec SPIGOT-7970: World#getMaxHeight() returning incorrect value
2b9a094bb SPIGOT-7965: Unknown TransformReason for Hoglins
fd3f5a380 SPIGOT-7966: Some trees do not generate with #generateTree
f2822317c PR-1515: Add a Class reader and Class node argument provider
07abf6852 PR-1514: Add a test case for ClassTraverser
a7577cb24 Fix Inventory#addItem not respecting max stack size
066a74e74 PR-1490: Add method to get Advancement requirements
4a1df30e4 PR-1512: Test Art class based on specific values instead of the implementation, to better catch implementation changes
53254c56f PR-1503: Simplify CAS loop to getAndSet
e9447dc5e Make BlockDataMeta#setBlockData hide unspecified states
dd08a7120 SPIGOT-7960: Fix inconsistency between natural item drop coordinates
e9e8ed753 SPIGOT-7960: Improve natural item drop methods
Spigot Changes:
60c9969b Rebuild patches
Spigot incorrectly returns false in Wolf#actuallyHurt if the armor
absorbed the damage causing the entity to not get damage invuln ticks.
Resolve this by correctly reverting to the "always true" return value as
the event is not cancelled.
Fixes incorrect spigot handling of the invulnerability damage
reduction applied when an already invulnerable entity is damaged with a
larger damage amount than the initial damage.
Vanilla still damages entities even if invulnerable if the damage to be
applied is larger than the previous damage taken. In that case, vanilla
applies the difference between the previous damage taken and the
proposed damage.
Spigot's damage modifier API takes over the computation of damage
reducing effects, however spigot invokes this handling with the initial
damage before computing the difference to the previous damage amount.
This leads to the reduction values to generally be larger than expected,
as they are computed on the not-yet-reduced value.
Spigot applies these reductions after calling the EntityDamageEvent and
*then* subtracts the previous damage point, leading to the final damage
amount being smaller than expected.
This patch cannot simply call the EntityDamageEvent with the reduced
damage, as that would lead to EntityDamageEvent#getDamage() returning
the already reduced damage, which breaks its method contract.
Instead, this patch makes use of the DamageModifier API, implementing
the last-damage-reduction as a DamageModifier.
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:
2b4b6d14 PR-1023: Convert InventoryView to interface
CraftBukkit Changes:
68603b1c1 Use expanded interaction ranges for traced interact events
eae9f760c PR-1414: Convert InventoryView to interface
ee9eafe67 Fix Implementation for DamageSource#isIndirect for internal custom causing entity
The method sadly is not usable in 1.21 without a player as all of an
enchantments attribtue modifiers rely on a base value supplied by a
player. The method could only offer a rough estimate based on some
default values, however a better method for this should be added down
the line rather than trying to force such logic into the existing one.
Previously would stream and optionally filter out all entries in the
enchantment registry.
Moves it to using the empty optional if treasure is allowed, leaving the
logic to EnchantmentHelper.
The Enchantment damage increase API added previously used the
EntityCategory enum as a parameter. These values are now however
determined by tags instead of the categories themselves.
Deprecated the outdated api method, create a new overload that takes
EntityType instead and implement deprecated method by guessing an entity
type from the builtin registry based on the category passed.
This method allows
a) the tags to still be modified and the legacy
method still respecting such.
b) potential cursed implementations of enchantments of plugins to not
break that override the getDamageBonus method on Enchantment.
