geforkt von Mirrors/Paper
c180de46e2
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> |
||
---|---|---|
.. | ||
src | ||
.gitignore | ||
LICENCE.txt | ||
pom.xml | ||
README.md |
Bukkit
A Minecraft Server API.
Website: http://bukkit.org
Bugs/Suggestions: http://leaky.bukkit.org
Compilation
We use maven to handle our dependencies.
- Install Maven 3
- Check out this repo and:
mvn clean install
Coding and Pull Request Conventions
- We generally follow the Sun/Oracle coding standards.
- No tabs; use 4 spaces instead.
- No trailing whitespaces.
- No CRLF line endings, LF only, put your gits 'core.autocrlf' on 'true'.
- No 80 column limit or 'weird' midstatement newlines.
- The number of commits in a pull request should be kept to a minimum (squish them into one most of the time - use common sense!).
- No merges should be included in pull requests unless the pull request's purpose is a merge.
- Pull requests should be tested (does it compile? AND does it work?) before submission.
- Any major additions should have documentation ready and provided if applicable (this is usually the case).
- Most pull requests should be accompanied by a corresponding Leaky ticket so we can associate commits with Leaky issues (this is primarily for changelog generation on dl.bukkit.org).
- Try to follow test driven development where applicable.
Tips to get your pull request accepted
Making sure you follow the above conventions is important, but just the beginning. Follow these tips to better the chances of your pull request being accepted and pulled.
- Make sure you follow all of our conventions to the letter.
- Make sure your code compiles under Java 5.
- Provide proper JavaDocs where appropriate.
- Provide proper accompanying documentation where appropriate.
- Test your code.
- Make sure to follow coding best practises.
- Provide a test plugin binary and source for us to test your code with.
- Your pull request should link to accompanying pull requests.
- The description of your pull request should provide detailed information on the pull along with justification of the changes where applicable.