Plugins were abusing this to dispatch commands async anyways.
We will no longer check that flag, and force all commands to be ran sync.
Use a different boolean for allowing things go to through on shutdown/restart instead.
Resolves#1004Resolves#1005
- Lots of itemstack cloning removed. Only clone if the item is actually moved
- Return true when a plugin cancels inventory move item event instead of false, as false causes pulls to cycle through all items.
However, pushes do not exhibit the same behavior, so this is not something plugins could of been relying on.
- Add option (Default on) to cooldown hoppers when they fail to move an item due to full inventory
- Skip subsequent InventoryMoveItemEvents if a plugin does not use the item after first event fire for an iteration
This is adds basic item meta for armor stands. It does not add all
possible metadata however.
There are armor, hand, and equipment types, as well as position data
that can also be added here. This initial implementation should serve as
a starting point for future additions in this area.
Fixes GH-559
This is a source of MAJOR lag for hoppers, as well as a gameplay bug.
This removes the necessity to disable the cat on chest behavior to improve performance.
now performance will be improved even if you have cat chest detection on.
Allows plugins to populate profile properties from local sources to avoid calls out to Mojang API
to fill in textures for example.
If Mojang API does need to be hit, event fire so you can get the results.
This is useful for implementing a ProfileCache for Player Skulls
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.
