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>
New events:
- InventoryOpenEvent
- InventoryClickEvent - detects any clicks on a slot or outside the window
- In the creative inventory view, only clicks on the quickbar are detected
- InventoryCloseEvent
- BrewEvent - when a potion finishes brewing
- CraftItemEvent (a subevent of InventoryClickEvent) - fired when taking the crafted item
- PrepareItemCraftEvent - fired just before updating the result slot
Changes to existing events:
- EnchantItemEvent extends InventoryEvent and also has a new whichButton() method
- PrepareItemEnchantEvent also extends InventoryEvent
- FurnaceBurnEvent and FurnaceSmeltEvent now extend BlockEvent (as does BrewEvent)
- PlayerInventoryEvent is deprecated (though it never did anything anyway)
New subclasses of Inventory:
- BrewerInventory
- CraftingInventory
- DoubleChestInventory
- EnchantingInventory
- FurnaceInventory
New methods in Inventory:
- getViewers()
- getTitle()
- getType()
- getHolder()
- iterator() - Yes, inventories are now iterable!
- The iterator is a ListIterator that does not support add or remove
New methods in Player:
- getOpenInventory()
- openInventory()
- openWorkbench()
- openEnchanting()
- closeInventory()
- setWindowProperty()
- getItemOnCursor()
- setItemOnCursor()
Other changes:
- createInventory() methods in Server to make inventories not linked to an object
- ContainerBlock is deprecated in favour of InventoryHolder
- New InventoryView class gives direct access to an inventory window!
- Removed the Slot class which did nothing and was used nowhere
Some small credit goes to Afforess (initial conception of openInventory() methods) and Drakia (initial conception of InventoryOpenEvent and InventoryCloseEvent).
By: Celtic Minstrel <celtic.minstrel.ca@some.place>
- New recipe iterator which enables deleting specific recipes
- Functions to delete all recipes or revert to vanilla recipe set
- Fixed the recipes API; you should now be able to define recipes that take brewed potions!
- Fetch all recipes that result in a specific item
By: Celtic Minstrel <celtic.minstrel.ca@some.place>
useExactLoginLocation() looks for settings.use-exact-login-location within bukkit.yml.
If true, we will bypass Vanilla's behaviour of checking for collisions and moving the player if needed when they login.
If false, we will continue to follow Vanilla's behaviour and move players that 'collide' with objects when they login.
By: EvilSeph <evilseph@gmail.com>
