| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This event is being called whenever a block or entity (e.g. hopper) tries to
move an item from one inventory to another inventory (one inventory may be
the hopper itself).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This command only functions in command blocks so the bukkit command for it
simply spits out an error message.
|
| |
|
|
|
|
| |
BUKKIT-3656, BUKKIT-3657
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is breaking for the new API for 1.5, including the interfaces for
the three new Minecart types and the name of the previously TNT_MINECART
material.
This change also deprecates the two previous specific minecart types located
in the org.bukkit.entity package. This deprecation is not a breaking change
and will still be internally supported.
Each minecart type has new javadoc to be slightly more descriptive. Included
with this are specific references to the interface for each respective
EntityType entry. Another package-info.java file has been included as well.
All specific minecart types extend minecart, each with a more descriptive
name. The naming will also follow the old convention. In addition, the
minecart with no specific designation is now more closely referred to as a
rideable minecart.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The permission attachment interface provides two methods each for setting
and unsetting permissions. Each one also provides an extra call to the
recalculatePermissions() method on the permissible, which degrades
performance.
This commit removes the duplicate call to recalculate permissions.
|
|
|
|
|
|
|
| |
Permissions are stored as lower case names and referenced as such in all
appropriate methods but removePermission. This changes removePermission
to also convert names to lower case to be consistent with the rest of
the API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Static methods are death to testability. However, irrelevant static
methods can be negotiated with until a later time in which they can be
removed. When instantiating a new Permission object, static calls are
made to the Bukkit class during a recalculatePermissibles logic path.
This recalculatePermissibles call should probably be moved
appropriately, but until the time such testing can be accomplished
itself, these tests work around that situation by simply verifying the
static Bukkit server references are satisfied since what is called as
a result is irrelevant currently.
This commit also updates a few other tests for PluginManagerTest to
work towards the standard of using the Hamcrest unit testing library.
|
| |
|
| |
|
|
|
|
|
|
| |
If the plugin.yml gets loaded but wasn't in the form of a map, the
server would crash. This safely checks to see if it can be cast,
throwing invalid description if it cannot.
|
|
|
|
|
| |
getInteger returns min value on illegal number formats, so we change
behavior to throw an exception when requested.
|
|
|
|
| |
If there is no TravelAgent assigned, it can not be used.
|
|
|
|
|
| |
The player name may not be provided, in which case the command will
fail hard.
|
|
|
|
|
|
| |
Addresses:
BUKKIT-1643, BUKKIT-1868, BUKKIT-1846, BUKKIT-2632, BUKKIT-3196,
BUKKIT-3187, BUKKIT-3198, BUKKIT-3200, BUKKIT-3201 and BUKKIT-3417.
|
|
|
|
|
|
|
|
|
| |
EntityPortalEvent is called when an entity is about to portal to a
new location. This event is cancellable on top of being able to
change the exit location.
EntityPortalExitEvent is called when exiting the portal, allowing
for adjustment of the exit velocity.
|
|
|
|
| |
Negative id values would try to access the array out of bounds and throw an java.lang.ArrayIndexOutOfBoundsException.
|
|
|
|
|
| |
The firework colors were based on the respective wool data values. This
means the colors were in reverse order.
|
|
|
|
|
|
|
|
|
|
|
|
| |
DyeColor used the wool data for getData(), which is very misleading based
on class name. The old method has been deprecated and replaced with
getWoolData() and getDyeData() for the appropriate types of data values.
The MaterialData classes Dye and Wool were updated appropriately,
especially Dye innapropriately using a DyeColor data value compensation.
Unit tests were added for the new methods, as well as the getColor on Dye
and Wool.
|
| |
|
| |
|
|
|
|
|
| |
The default leather color is already used internally in place of null. The
javadocs were updated appropriately to indicate as such.
|
|
|
|
|
| |
The warning message printed with the stack traces on the deprecated
methods mistakingly use the wrong method signature in the description.
|