* Mention missing impl
* Clean the implementation out of years old code
* Change the jd comment
* Move to default method
---------
Co-authored-by: Bjarne Koll <lynxplay101@gmail.com>
This allows plugins to access chunks slightly outside of the
max world border (such as ones which may be loaded naturally
by players) without tripping any logs.
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.
