Skip to content
This repository was archived by the owner on Dec 4, 2024. It is now read-only.

aaaaaaa #1

Open
wants to merge 2,601 commits into
base: master
Choose a base branch
from
Open

aaaaaaa #1

wants to merge 2,601 commits into from

Conversation

sizquirt
Copy link
Owner

saasdsfghntgbbbgbgbgf

kennytv and others added 30 commits December 4, 2024 11:05
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:
c294e05d7 SPIGOT-7975: Fix issue with Pale Sapling growing
c9f5a8fdf SPIGOT-7974: Fix Crash for Creaking Heart Block particle
VoxelShape coordiantes generally are an integer + a sum of powers of
two between [-1, -3]. Most offsets are generally an integer. As
a result, applying an offset to the coordinates generally results
in an error of 0. However, coordinate inputs do not follow such
trends. Thus, when applying an offset to the coordinate input,
there may be some floating point error.

By applying the offset to the VoxelShape coordinates, we can
eliminate additional floating point error.

This change also fixes the inconsistency when using
the single AABB, as input coordinates were not offset
when using the single AABB as the single AABB is already
offset.

Fixes Tuinity/Moonrise#81
This specific issue is caused by floating point error resulting
in the falling anvil's y position becoming around -8E-17 when it
should be 0.
While this is still very comfortably in the collision
epsilon (1.0E-7), this results in the falling anvil's y block
position to become -1 (as the block position is simply
the floor of the coordinate).
setup-gradle v4 validates the wrapper
This prevent the creaking from being pushed with knockback
enchant when it can't move
* Switch Impl types to Holderable

* Fix compile issues

* more improvements

* compile fixes

* remove unneeded unwrapAndConvertHolder call

---------

Co-authored-by: Bjarne Koll <[email protected]>
Fixes #11649 - As noted in the issue, when CommandNodes are serialized
they are used as the key in a Map. Their equals()/hashcode() should only    match if they are equal nodes (name & command), but due to the erasure of the command field pre-serialization, nodes with different commands can be mapped onto the same value. This causes the client to interpret both nodes as the same, causing suggestions where they should not.

This is fixed by creating a different no-op command for the
erasure, instead of them holding the same lambda.
* Re-add shear methods from bukkit Shearable

* Add back
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.