This new API:
* Has first class support for Material / MaterialData
* Abstracts away the underlying Chunk format
* Implements useful utility methods to make life easier
By: Antony Riley <antony@cyberiantiger.org>
Up until now it has not been possible to create a new Inventory using
a custom title and permit any InventoryType available.
The commit changes that by adding a method to optionally supply the title
for the given inventory type and holder, creating the functionality to
display any supported inventory type with a 32 character length String.
If the inventory title supplied is larger than 32 characters then an
IllegalArgumentException is thrown stating so.
By: eueln <euelnd@gmail.com>
Fixes BUKKIT-5371 and BUKKIT-4285
Prior to this commit, ban reasons were not supported by banning commands.
Additionally, the player(s) affected by the ban-ip command would not have
been removed from the server via a kick.
The Bukkit API lacked support for modifying various attributes associated
with bans, such as the reason and expiration date. This caused various plugins
to use external or other means to store a ban reason, making the built-in
banning system on the server partially useless.
Now the ban commands will accept reasons for the bans as well as kick the
player from the server once banned. That means that if an IP is banned
that all players using that IP will be removed from the server.
The API provided now supports editing the ban reason, creation date,
expiration date and source. The ban list has also been created to
provide this information more easily. Editing the data requires an
implementing plugin to manually save the information with the provided
method in BanEntry or BanList once changes have been made.
The addition of this API has deprecated the use of OfflinePlayer#setBanned()
as it has been replaced by BanList#addBan().
By: mbax <matt@phozop.net>
Necessary additions include an interface to add internal value conversions
that are inappropriate for proper API design. This acts as a substitute
for properly formed, user-friendly commands in an effort to maintain
relatively vanilla behavior.
By: Wesley Wolfe <weswolf@aol.com>
The implementation is designed around having both a main scoreboard and
numberous plugin managed scoreboards that can be displayed to specific
players.
Plugin managed scoreboards are active so long as a reference is kept by a
plugin, or it has been registered as a player's active scoreboard. Objects
specific to a scoreboard remain active until unregistered (which remove a
reference to the owning scoreboard), but quickly fail if accessed
post-unregistration.
By: mbax <github@phozop.net>
