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:
a6aba46f PR-1078: Improve Javadocs of Player#loadData() and Player#saveData()
1e2e6a18 SPIGOT-7946: API for server pause when empty seconds
54a36938 SPIGOT-7944, PR-1077: Allow nullable fields in DamageTypeTags
CraftBukkit Changes:
2702c5c8e SPIGOT-7946: API for server pause when empty seconds
485f910fc SPIGOT-7947: addPassenger doesn't work if the vehicle is a player
ecf3dff0e SPIGOT-7949: Registering a new scoreboard objective with an empty display name throws a NPE
9b048cc84 SPIGOT-7948: `Bukkit#dispatchCommand` uses the wrong `CommandListenerWrapper` for Players
7b44d4640 SPIGOT-7931: Fix sync in Anvil View when result item is taken
EAR 2 evaluates the entities activity on the already incremented entity
tick. This diverges from spigots behaviour and hence needed adoption for
their item ear fix.
Updated Upstream (Bukkit/CraftBukkit/Spigot)
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:
b9df8e9f SPIGOT-7933: Improve custom Minecart max speed
fc496179 Fix InstrumentTest
7c0ec598 PR-1075: Make Art an interface
c389f5a4 PR-1074: Make Sound an interface
CraftBukkit Changes:
df1efc0bb SPIGOT-7945: `Bukkit#dispatchCommand` throws `UnsupportedOperationException`
285df6e85 SPIGOT-7933: Improve custom Minecart max speed
a0f3d4e50 SPIGOT-7940: Recipe book errors after reload
9e0618ec2 SPIGOT-7937: Cannot spawn minecart during world generation with minecart_improvements enabled
1eb4d28da SPIGOT-7941: Fix resistance over 4 amplify causing issues in damage
52b99158a PR-1504: Make Art an interface
e18ae35f1 PR-1502: Make Sound an interface
Spigot Changes:
e65d67a7 SPIGOT-7934: Item entities start "bouncing" under certain conditions
First, if the light data is not marked as correct, we should not be
parsing it in the first place. This will eliminate errors from
parsing possibly different versioned light data.
Secondly, if parsing the light data throws an exception (from
the SWMRNibbleArray constructor), then we can simply mark
the returned chunk as having incorrect light data - rather than
propagating the exception and causing the chunk to be re-generated.
Spigot uses a no longer valid ClientboundContainerSetSlotPacket with the
slot -1, which would update the carried stack in versions <=1.21.1 but
now leads to an IOOB.
1.21.2 instead introduced the ClientboundSetCursorItemPacket, which this
patch uses instead.
The previous implementation was based off of spigots logic in
CraftRecipe#toIngredient, which is completely incorrect as
nms.Ingredient.of() is a throwing call.
Correctly insert handling for the empty() choice in the toNMSOptional
logic.
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:
97c59261 PR-1073: Make Biome an interface
a38581aa Fix further javadoc errors
8271c490 Fix javadoc error
8a9ecf29 PR-1072: Fix bad naming for Vault State methods
6dd58108 PR-1071: Make Fluid an interface and add missing entry
ed2cdfc3 PR-1070: Make Attribute an interface and align names with the new minecraft ones
63472efb PR-1069: Add missing winter drop experimental annotation to pale boats
CraftBukkit Changes:
7235ad7b0 PR-1501: Make Biome an interface
602904003 PR-1500: Rename implementation for Vault State methods
75f26f79f PR-1499: Make Fluid an interface and add missing entry
4cfd87adc PR-1498: Make Attribute an interface and align names with the new minecraft ones
6bb0db5cb SPIGOT-7928: ExactChoice acts as MaterialChoice
3eaf3a13c SPIGOT-7929: Error when setting EquippableComponent
abbf57bac SPIGOT-7930: Fix spawning entities with SummonEntityEffect
92d6ab6cf PR-1497: Move boat field rename entries to below key renaming, so that keys are also renamed
abfe292aa PR-1496: Use correct Fluid class on Tags type check
c7aab7fa7 SPIGOT-7923: Fix Dispenser logic to avoid firing empty projectiles
Since 1.21.2, vanilla split relative teleportation flags into position
and delta/velocity flags into separate enum entries.
This highlighted a design flaw in the paper api addition for teleport
flags, which just simply mirrored internals while also only being able
to apply the delta/velocity part of a flag, given the teleport target is
always absolute in the API.
This patch proposes to simply no longer expose the non-velocity related
flags to the API, instead marking the entire Relative enum as being
purely velocity related, as non-velocity related flags are not useful to
callers. This was done over simply exposing all internal flags, as
another vanilla change to the internal enum would result in the same
breakage.
The newly proposed API *only* promises that the passed flags prevent the
loss of velocity in the specific axis/context, which should be
independent enough of vanillas specific implementation of this feature.
When enabled, ender pearls will not load chunks and will save to the world instead of the player.
Also changes the exploit config to be default false, as it only makes sense when legacy behavior is enabled.
