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.
getting a loaded chunk is one of the most hottest pieces of code in the game.
Often, getChunkAt is called for the same chunk multiple times in a row, often
from getType();
Optimize this look up by using a Last Access cache.
should be fully working now as I pretty much fell back to existing
methods so anything touching the unloadQueue set should behave correctly.
And maintained NMS Reflection safe change too
While the previous logic was logically correct, some CB API's before
would request a chunk without removing it from the unload queue.
While this is logically wrong, some plugins seem to be causing unload issues.
This change will make anything using that one API that use to not remove from
queue, no longer remove from queue.
Hopefully other activities on the server will touch the chunk if it REALLY is in use.
Use an optimized method to test if a block position meets a desired light level.
This method benefits from returning as soon as the desired light level matches.
Also Optimize Grass more
Mojang included some sanity checks on arguments passed to the BlockData.
This code results in the Hash look up occuring twice per call, one to test if it exists
and another to retrieve the result.
This code should ideally never be hit, unless mojang released a bad build. We can discover bugs with this as furthur code that never expects a null
would then NPE, so it would not result in hidden issues.
This is super hot code, so removing those checks should give decent gains.
Removing chunks from the unload queue when performing chunk lookups is a costly activity.
It drastically slows down server performance as many methods call getChunkAt, resulting in a bandaid
to skip removing chunks from the unload queue.
This patch optimizes the unload queue to instead use a boolean on the Chunk object itself to mark
if the chunk is active, and then insert into a LinkedList queue.
The benefits here is that all chunk unload queue actions are now O(1) constant time.
A LinkedList will never need to resize, and can be removed from in constant time when
used in a queue like method.
We mark the chunk as active in many places that notify it is still being used, so that
when the chunk unload queue reaches that chunk, and sees the chunk became active again,
it will skip it and move to next.
First, Enchantment order would blow away seeing 2 items as the same,
however the Client forces enchantment list in a certain order, as well
as does the /enchant command. Anvils can insert it into forced order,
causing 2 same items to be considered different.
This change makes unhandled NBT Tags and Enchantments use a sorted tree map,
so they will always be in a consistent order.
Additionally, the old enchantment API was never updated when ItemMeta
was added, resulting in 2 different ways to modify an items enchantments.
For consistency, the old API methods now forward to use the
ItemMeta API equivalents, and should deprecate the old API's.
If the server lags out and skips multiple ticks, Furnace cooking behavior would not
cook in the expected amount of time as the cook time was not decremented correctly.
This patch ensures that furnaces cook to the correct wall time expectation.
