Currently, plugin prefixes are prepended to the log message in
the PluginLogger before passing the message to the underlying
logging framework. This is bad design because they need to be
stripped manually when using custom appenders to log messages
in a different format.
Additionally, it makes integration of alternative logging APIs hard
because all logging must go through the PluginLogger. Avoid using
PluginLogger and create a regular logger using the plugin name.
The implementation should handle plugin prefixes by displaying
logger names when appropriate.
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.
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.
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.
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.
Provides API to control what Loot Table an object uses.
Also provides an Event to control if a lootable inventory should
auto replenish for a player.
Provides methods to determine players looted state for an object
Adds the PlayerUseUnknownEntityEvent to be used by plugins dealing with
virtual entities/entities that are not actually known to the server.
Co-authored-by: Nassim Jahnke <nassim@njahnke.dev>
Use ConcurrentHashMap to allow thread-safe access methods and very
limited synchronized portions to allow much higher concurrency in
MetadataStore as well as far less locking, especially on reads
