This simply provides the base API to create the objects. Further commits will come that adds
adds usage of this API to existing GameProfile based API's, as well as new API's.
This event can be used for when you want to exclude a certain player
from triggering monster spawns on a server.
Also a highly more effecient way to blanket block spawns in a world
Adds an event to fire before an Entity is created, so that plugins that need to cancel
CreatureSpawnEvent can do so from this event instead.
Cancelling CreatureSpawnEvent rapidly causes a lot of garbage collection and CPU waste
as it's done after the Entity object has been fully created.
Mob Limiting plugins and blanket "ban this type of monster" plugins should use this event
instead and save a lot of server resources.
See: https://github.com/PaperMC/Paper/issues/917
Limit the number of generations that can occur in a single tick, forcing them
to be spread out more.
Defaulting to 10 as an average generation is going to be 3-6ms, which means 10 will
likely cause the server to lose TPS, but constrain how much.
This should result in no noticeable speed reduction in generation for servers not
lagging, and let larger servers reduce this value according to their own desires.
add a system property to allow people to tweak how long the server
will wait for a reply. There is a compromise here between lower and higher
values, lower values will mean that dead connections can be closed sooner,
whereas higher values will make this less sensitive to issues such as spikes
from networking or during connections flood of chunk packets on slower clients,
at the cost of dead connections being kept open for longer.
Instead of overriding add within the queue, never add runnables to the
queue if the light queue is disabled.
This change is made to make timings reports and stacktraces less
confusing for administrators, who prior to this change, would have seen
the lighting queue referenced in both, regardless of whether or not it
was enabled.
This change should not affect performance, nor is it made with the
intent to.
This allows plugins that give players the ability to apply the experience
points to the Item Mending formula, which will repair an item instead
of giving the player experience points.
Both an API To standalone mend, and apply mending logic to .giveExp has been added.
Fired when the server is about to merge 2 experience orbs
Plugins can cancel this if they want to ensure experience orbs do not lose important
metadata such as spawn reason, or conditionally move data from source to target.
This ensures that enchants are never added in inconsistent order.
The client shows the enchants in a sorted order already
This will auto fix previously created items too on load.
Spigot, by default, disables several mechanisms around how chunks are
lit, if ever, which has forced them to always send chunks before vanilla
would consider them ready to send, causing for lots of issues around
lighting glitches.
Shamefully, the amount of work to relight chunks can be detremental
to some servers, meaning that forcibily disabling light updates can
cause major performance issues.
as such, we make a compromise; if this "feature" is disabled, we will
only send chunks which are actually ready to be sent, otherwise, we
will always send chunks.
Any plugin still using this API will result in the server saving an inconsistent UUID to player data files,
which then triggers warnings such as "Tried to load unrecognized recipe: bukkit:9e5b92f5-e549-4f47-b0a8-9f89390ed77b removed now."
on the players login.
Plugin authors need to define a key to keep it consistent between server restarts.
