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.
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.
Let plugins be able to control tab completion of commands and chat async.
This will be useful for frameworks like ACF so we can define async safe completion handlers,
and avoid going to main for tab completions.
Especially useful if you need to query a database in order to obtain the results for tab
completion, such as offline players.
Also adds isCommand and getLocation to the sync TabCompleteEvent
Essentials uses a custom logger name ("Essentials") instead of the
plugin logger. Log messages are redirected to the plugin logger by
setting the parent of the "Essentials" logger to the plugin logger.
With our changes, the plugin logger is now also called "Essentials",
resulting in an infinite loop. Make sure plugins can't change the
parent of the plugin logger to avoid this.
SLF4J is a commonly used abstraction for various logging frameworks
such as java.util.logging (JUL) or Log4j. Currently, plugins are
required to do all their logging using the provided JUL logger.
This is annoying for plugins that target multiple platforms or when
using libraries that log messages using SLF4J.
Expose SLF4J as optional logging API for plugins, so they can use
it without having to shade it in the plugin and going through
several layers of logging abstraction.
the first 'major' change in this PR is to cache the generated event
executrs from the ASM class, by doing this we only generate a single
class for every method that we need an executor for, thus reducing the
number of classes that are needed, especially in cases where plugins
re/unregister events all the time.
The second change is to modify the generated classloader map, generated
classloaders are not held against the plugin itself but the classloader
that the event is declared in, the implication here is that we cannot
drop generated classloaders when a plugin disable, and so we use a guava
weak-key'd hashmap, downfall here is that classes won't be GC'd until
guava drops the generated classloader, however the first change should
deal with most of the grunt.
Gets the Display name as seen in the Client.
Currently the server only supports the English language. To override this,
You must replace the language file embedded in the server jar.
This will take a Bukkit ItemStack and run it through any conversions a server process would perform on it,
to ensure it meets latest minecraft expectations.
Not all horses with Saddles have armor. This lets us break up the horses with saddles
and access their saddle state separately from an interface shared with Armor.
Adds a Pre Lookup Event and a Post Lookup Event so that plugins may prefill in profile data, and cache the responses from
profiles that had to be looked up.
Fixes our own, and upstream's, issues with the stricter Java 8 JavaDoc
linter.
Also removes the destroystokyo-release maven repository. I'm not sure
why I added it originally, but it's unnecessary now.
Spigot has patched this issue inside MapIcon, meaning that we no longer need to maintain this patch; Spigots patch also fixes#668 in that it will verify the length of the array, as well as protect against a negative type value being fetched from the array. Only real change is that Spigots patch returns a MapIcon.Type.PLAYER, instead of the RED_MARKER as originally PR'd by Aikar.
Also add "commands" to Tab Completion
Note: This required a signature change to Bukkit#reloadCommandAliases() so that it returns a boolean based on if the command aliases reloaded or not.
Finally made timings accept "Callback style" reports, so plugins
can listen for when the report is done.
Added new Util interfaces, MessageCommandSender and BufferedCommandSender
This restores and improves using RCON to generate timings reports
I believe we are getting data corruption by doing it in the middle of the tick, as I was seeing
really odd reports from automated ones vs command ones.
This will break issueing timings over rcon single command mode and getting the report link in the response back
But I will try to restore that (and make RCON no longer cause spikes) soon.
Reports will still generate, just because its async, the RCON connection
will drop if not in terminal mode before its done.
The Component based methods are not even safe to use, as it may result in invalid items being sent to the client.
The string based method we have added is the only safe way to send with the API.
The client is stricter about componenents being sent for this API, and does not accept children components.
The client is expecting a legacy string.
Require user to confirm the timings reset, warning them that they should not be doing this.
Also require Timings to have ran for 3 minutes before allowing the report command.
Also require 1 minute intervals between reports to stop report spam.
