The epsilon used was in the opposite direction, which would cause
the getCollisions method to incorrectly return it for when players
were exactly on the border but not colliding. To bring it in-line
with the rest of the collision code, the collision must be into
the border by +EPSILON.
Fixes https://github.com/PaperMC/Paper/issues/9859
* finish implementing all adventure components in codecs
* add some initial tests
* Add round trip tests for text and translatable components
* Add more round trip test data (score component is failing)
* Add more round trip test data
* Fix SCORE_COMPONENT_MAP_CODEC
* Improve test failure messages
* Add failure cases
* Add a couple more test data
* Make use of AdventureCodecs
* Update patches after rebase
* Squash changes into adventure patch
* Fix AT formatting
* update comment
---------
Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com>
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:
01bb6ba7 PR-936: Add new PersistentDataContainer methods and clean up docs
bc145b90 PR-940: Create registry for banner pattern and cat type
CraftBukkit Changes:
cb2ea54de SPIGOT-7440, PR-1292: Fire EntityTeleportEvent for end gateways
4fea66e44 PR-1299: Add new PersistentDataContainer methods and clean up docs
b483a20db PR-1303: Create registry for banner pattern and cat type
4642dd526 SPIGOT-7535: Fix maps not having an ID and also call MapInitializeEvent in more places
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
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
CraftBukkit Changes:
c9cb08551 SPIGOT-7536: Using Crafter crashes server
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:
9a294519 SPIGOT-7533, 943: Add missing Poses for 1.20.3
be2884c4 Add unique ID to PlayerResourcePackStatusEvent
d9c1eb83 Add additional @MinecraftExperimental annotations
68f5bb6a SPIGOT-7526: Add missing PlayerResourcePackStatusEvent statuses
CraftBukkit Changes:
368c48be1 Fix formatting issue in previous commit
da8f91f31 SPIGOT-7534: Error when chunk with decorated pot trying to save
d20c9291a SPIGOT-7532: Entity#isValid() returns false after server restart
ec1fa2ead PR-1309: Add tests for Bukkit Pose
5a7080b58 Add unique ID to PlayerResourcePackStatusEvent
0fd734950 SPIGOT-7528: Fix certain custom shaped recipes
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.
* Updates documentation in EntityEquopment.java to reflect behavior mentioned in issue #9867
* rebase and squash patches
---------
Co-authored-by: schwaa96 <schwaa96@mi.fu-berlin.de>
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:
96340858 PR-938: Various Sound API improvements
cbfe0ff0 PR-937: Minor improvements to World#rayTrace documentation
e979ee95 PR-935: Change Consumer and Predicates to super
27ae46dc SPIGOT-3641, SPIGOT-7479, PR-931: Add missing values to EntityEffect
0616ec8b Add eclipse .factorypath file to .gitignore
CraftBukkit Changes:
8e162d008 PR-1301: Various Sound API improvements
eeb7dfc2d SPIGOT-7520: Attribute LootTableSeed missing for generated containers with attached LootTable
d433f086d PR-1297: Change Consumer and Predicates to super
864f616da SPIGOT-7518: Fix NullPointerException when calling Block#applyBoneMeal()
5a2d905af Add eclipse .factorypath file to .gitignore
7c6bf15d4 Fix SkullMeta configuration serialization / deserialization with note block sound
Spigot Changes:
7de1049b Rebuild patches
For each player on each tick, enter block triggers are invoked, and these create loot contexts that are promptly thrown away since the trigger doesn't pass the predicate
To avoid this, we now lazily create the LootContext if the criterion passes the predicate AND if any of the listener triggers require a loot context instance
* Add attribute modifier from UUID API
* Add method to remove by UUID
* Add overload for UnmodifiableAttributeInstance, better precondition messages
* rebase
The existing EntityPickupItemEvent fixes patch moves the call to LivingEntity#onItemPickup for piglins after the respective EntityPickupItemEvent calls, which is correct.
However the patch moved the call so far down the line that the existing logic already mutated the picked up item entity, leading to faulty state being passed to the onItemPickup method.
To prevent logic in LivingEntity#onItemPickup to read from an ItemEntity that was already mutated, this commit moves the calls prior to the two respective mutations (either gold_nugget or rest).
This was chosen above taking a copy of the original item and restoring state later on to avoid a full item stack clone.
Upstream did not account for different hands when storing
the breed item for later use in the event. Also they only
stored a reference to the stack, not a copy so if the stack
changed after love mode was started, the breed item in the event
also changed. Also in several places, the breed item was stored after
it was decreased by one to consume the item.
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:
fde5602a PR-927: Add PlayerRecipeBookSettingsChangeEvent
949ff217 PR-930: Add methods to get/set evoker fang attack delay
f6f7c79d SPIGOT-7514, PR-929: Add "Enchantment Roll" API to enchant items according to Minecraft mechanics
d40e22da PR-712: Add API to get full result of crafting items
CraftBukkit Changes:
c8feb0629 PR-1291: Improve precondition message in Entity#playEffect
482c56a00 PR-1285: Add PlayerRecipeBookSettingsChangeEvent
cdf798800 PR-1290: Add methods to get/set evoker fang attack delay
2c1b5f78f SPIGOT-7514, PR-1289: Add "Enchantment Roll" API to enchant items according to Minecraft mechanics
6aa644ae9 PR-992: Add API to get full result of crafting items
ffb1319bc PR-1287: Fix scoreboards not updating in Player#setStatistic
Cost is a property of individual enchantments, and is used by vanilla in combination with environmental aspects like tool enchantability and bookshelf count to determine the final cost of an enchantment as shown in an enchanting table.
Having access to the base cost of an enchantment using these vanilla methods can allow plugin developers to determine the "value" of an enchantment, and use it in custom logic where needed. I came across this recently when trying to assign an economic value to enchantments during tool repairing, and noticed these values don't seem to be obtainable under the current API.
* Add predicate for block data when raytracing blocks
* Match based on block, instead of block data
* Use instanceof instead of casting
* Use Position instead of Location, add overload for rayTraceEntities
* Implement requested changes
* Invert predicate
* Cleanup
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:
19830133 PR-925: Add hit entity/block to events extending ProjectileHitEvent
CraftBukkit Changes:
5a72c3c04 SPIGOT-7510: Try to fix broken reflection usage of plugins
6fa69f235 PR-1281: Add hit entity/block to events extending ProjectileHitEvent
224f733ac Fix NPE introduced in #f4d977e
