This method was used pre 1.17 era where an Entity was explicitly
tied to a (then called) Chunk's entity slices. If an entity
was not inside a Chunk, then it was considered invalid as
it was not possible to save the entity.
In 1.17+, entities are now tied to a separately tracked entity
section management system. This system is far more reliable now
as it no longer requires a full chunk load to properly track
entities for saving. As a result, an Entity if inside the world
is always attached to some entity chunk section (except in rare
cases in Vanilla which are fixed in Moonrise).
As a result, whether the chunk the entity is in is loaded is no
longer an indication of whether they are tracked in the world
and we can reliably infer that the entity is correctly in the
world through the valid field alone.
Additionally drop the isInWorld() check, as valid=true implies
isInWorld=true. More importantly, the isInWorld() check invokes
getHandle which may trip a thread check on Folia. This will fix
World#getEntities() and friends exploding on Folia.
However, World#getEntities() on Folia still cannot reliably return
all entities in the world as actions such as cross-region
(not cross-world) teleporting will remove entities from the world.
Enchantment shouldn't support direct holders despite the ctor
accepting a Holder type. We want to limit the types
to ones that are actually used as direct holders in the game
This diff was accidentally dropped when updating to hard fork.
This diff importantly:
- Does not return true if the async catcher is disabled
- Does not return true during shutdown
- Returns true for any instance of TickThread (enables
watchdog and Folia threads to be considered main)
Static final MethodHandles perform similar to direct calls. Additionally,
hidden classes simplify logic around ClassLoaders as they can be defined
weakly coupled to their defining class loader. All variants of methods
(static, private, non-void) can be covered by this mechanism.
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.
