Speaking with Amaranth, his point of his implementation was that most
of the lookups are on loaded chunks, so that code is optimized for that case.
While Long2Object should be faster as a general purpose map,
for MC uses, Amaranth's version should be faster. Will try to benchmark
the 2 at some future.
Should only happen for blocks on the edge that uses neighbors light level
(certain blocks). In that case, there will be 3-4 other neighbors to get a light level from.
Pathfinder objects are storing references to ChunkCache's, and never cleaning up.
These ChunkCache's then leak other entity objects. Those entity objects then have leaks to their
own chunk cache. A recursive problem....
Clean up the ChunkCache reference after it is done being used.
Many protection plugins would unintentionally trigger chunk loads
by calling .getToBlock() on an unloaded chunk, killing performance.
Simply skip the event call. as CraftBukkit blocks changing the block
of unloaded chunks anyways.
This keeps behavior consistent, vs inconsistent flowing based on plugin triggered loads.
Fires when an Entity decides to start moving to a location.
This is not the same as a move event. This only fires when an entity chooses
to start moving to a location, and allows cancelling that pathfind.
Additionally, only get is supported for now. Unsure if changing target location
is safe to do.
Vanilla stores how long a chunk has been active on a server, and dynamically scales some
aspects of vanilla gameplay to this factor.
For people who want all chunks to be treated equally, you can disable the timer.
These events will give plugins a reliable way to track every entity that is added
or removed from a world, so that one may always ensure they are in a desired state.
Not sure of any reason a plugin would need to act on a Physics event
for redstone. There is a BlockRedstoneEvent that plugins can also use
for accessing redstone activity.
Defaulting this to false will provide substantial performance improvement
by saving millions of event calls on redstone heavy servers.
The lighting queue spreads out the processing of light updates across
multiple ticks based on how much free time the server has left at the end
of the tick.
