Books can 'store' enchantments that can be applied to other items later.
These enchantments exist seperately of enchantments that actually effect the
item, and are as stated 'stored' in the book instead of the book being
enchanted. The meta is generically named as the concept could be applied to
other item types later, such as a enchantment scroll.
All of the methods mimic those in the base meta, but instead specify
'stored' in each method name.
By: Wesley Wolfe <weswolf@aol.com>
FireworkEffect is an immutable class that requires the builder pattern
to construct, to reduce ambiguity and help make code uses more readable.
FireworkMeta contains a list of effects, as well as a flight height.
FireworkEffectMeta contains a single effect for charges.
By: Wesley Wolfe <weswolf@aol.com>
The setTexturePack method causes the player's client to
download and switch to a texture pack specified by a URL.
Note: Players can disable server textures on their client, in which
case this API would not affect them.
By: Wojciech Stryjewski <thvortex@gmail.com>
Prior to 49690f9, BlockFaces were mostly correct in their respective
MaterialData classes. However, a lot of things were not updated since
implementation and broke without being addressed.
This fixes any discrepancies with Block data.
By: feildmaster <admin@feildmaster.com>
These methods are unnecessarily exposed. They are specific to a type of
implementation for the class loaders, and should have no external use.
Because these methods are exposed, it limits the versatility to change
how the internal class loading system works, including an inherent class
loader leak for some situations.
They are now replaced with internal, package-private methods. The public
facing methods will print a stack trace the first time one is activated.
Extending the classes also produces a stack trace, to indicate that
extension is not actively supported.
By: Wesley Wolfe <weswolf@aol.com>
Mainly javadoc changes to be specific in functionality and outcomes. This is
mixed with specifying that null Material should throw IllegalArgumentException
instead of the previous undefined NullPointerException.
Included is a clarification on how contains(ItemStack, int) works, and a new
method containsAtLeast(ItemStack, int) for counting the number of a specific
item.
By: Wesley Wolfe <weswolf@aol.com>
BUKKIT-3164
This adds an isFlammable method, to indicate if a block can catch fire.
This adds an isTransparent method, to check if light can pass through.
This adds an isOccluding method, to check if it fully blocks vision.
This adds an isBurnable method, to indicate if a block can burn away.
By: Wesley Wolfe <weswolf@aol.com>
Currently when a plugin wants to get the location of something it calls
getLocation() which returns a new Location object. In some scenarios this
can cause enough object creation/destruction churn to be a significant
overhead. For this cases we add a method that updates a provided Location
object so there is no object creation done. This allows well written code
to work on several locations with only a single Location object getting
created.
Providing a more efficient way to set a location was also looked at but
the current solution is the fastest we can provide. You are not required
to create a new Location object every time you want to set something's
location so, with proper design, you can set locations with only a single
Location object being created.
By: Travis Watkins <amaranth@ubuntu.com>
The name is misleading, as it can be misconstrued to mean "a sync"
instead of properly understanding it as "an async"
By: Wesley Wolfe <weswolf@aol.com>
Non-living entities can change blocks, specifically falling blocks. This change is a small source break, but mainly a byte-code break (requires plugins to recompile).
By: Wesley Wolfe <weswolf@aol.com>
If you use BlockFace in any way, to compensate the directionals being incorrect, you can still have backwards compatibility if you add in the handling in your plugin:
boolean legacyBlockFace = BlockFace.NORTH().getModX() == -1; (and then handle it accordingly)
If you didn't special case your directions to fix what's being fixed here... Hurray! Your plugin should now work.
By: feildmaster <admin@feildmaster.com>
Reobtaining a constructor is not a trivial operation, this change makes the Material enum store the respective constructors for each MaterialData.
Additionally 'fixed' the material tests to use proper generics.
By: Darth Android <darthandroid@gmail.com>
These methods were never intended to be overwritten, and bukkit relies
on their internal functionality. Additionally, the methods were inlined
in JavaPlugin, but the finality maintains intention.
By: Wesley Wolfe <weswolf@aol.com>
EXPLOSION is used when a hanging entity is removed by an explosion.
DEFAULT is used when a hanging entity is removed by an uncategorised
cause.
By: EvilSeph <evilseph@gmail.com>
These numbers are mirrored in vanilla code as the coordinate limits for
a world. Replaced usages to a static final member for code readability.
By: Wesley Wolfe <weswolf@aol.com>
Two potion types were missing from the 1.4.2 update. Invisibility and
night vision are now in the potion type enum.
Fixes an erroneous use of PotionEffectType.SPEED where it should have
been WEAKNESS.
Removed deprecation for the PotionEffectType relating to certain effects
that are now active in 1.4.2.
Fixes BUKKIT-2677, BUKKIT-2758.
By: Wesley Wolfe <weswolf@aol.com>
As well as adding methods for ItemFrames, this moves some methods
previously contained in Painting to Hanging, as they are shared by both
classes.
An enum was added that represents rotations, similar to a clock-face.
This is needed as a contrast to cardinal direction based rotations.
By: h31ix <effectsdude@gmail.com>
Overriding the toString() method provides more human-readable feedback
when a problem occurs, including the version of the plugin if
applicable.
By: Wesley Wolfe <weswolf@aol.com>
This implementation provides access to a (mutable) list and the base
message. Also provided is a convenience method for getting the last
'token' in the provided string.
By: Wesley Wolfe <weswolf@aol.com>
CommandMap contains a method that will auto-complete commands
appropriately. Before the first space, it searches for commands of which
the sender has permission. After the first space, it delegates to the
individual command.
Vanilla commands contain implementations to mimic vanilla
implementation. Exception would be give, that allows for name matching;
a feature we already allowed as part of the command is now supported for
auto-complete as well.
Plugin commands can get a tab completer set to delegate the completion
for. If no tab completer is set, it can check the executor to see if it
implements the tab completion interface. It will also attempt to chain
calls if null gets returned from these interfaces. Plugins also
implement the new TabCompleter interface, to add ease-of-use for plugin
developers, similar to the onCommand() method.
The default command implementation simply searches for player names.
To help facilitate command completion, a utility class was added with
two functions. One checks two strings, to see if the specified string
starts with (ignoring case) the second. The other method uses the first
to selectively copy elements from one collection to another.
By: Score_Under <seejay.11@gmail.com>
PlayerPreLoginEvent was originally implemented with the intention that
putting synchronized blocks on the plugin manager made it thread safe.
Unintentionally, this causes the event to be executed when a plugin
would otherwise expect no events to be firing. It is now deprecated.
By: Wesley Wolfe <weswolf@aol.com>
The new methods return the actual task that gets created from the
scheduler. They are also named such that auto-complete puts the
asynchronous methods after the normal ones. These two additions are
simply semantic.
Tasks now have a method to cancel themselves using their task id. This
is provided as a convenience.
A new class called SimpleRunnable was added. It is an abstract Runnable
such that anonymous classes may subclass it. It provides six convenience
methods for scheduling as appropriate. It also provides a cancel method
for convenience. The functionality of SimpleRunnable only stores an
integer representing the task id. A SimpleRunnable can only be scheduled
once; attempting to reschedule results in IllegalStateException.
By: Wesley Wolfe <weswolf@aol.com>
When an exception occurs, the version of the plugin is not included.
Having this information would be beneficial to plugin authors performing
debug.
The list of authors for NagAuthorException verbose (although unused)
would be more appropriate to simply include all authors, as opposed to
the first appearing.
By: Wesley Wolfe <weswolf@aol.com>
If no plugin is found with the given name, the version command will
search all loaded plugins to find a case insensitive partial match for
the specified name and print to the sender all matches.
By: Wesley Wolfe <weswolf@aol.com>
Previously, the method could be called with a null MetadataStore and stored.
In later execution null pointer exceptions would be generated when checking
for the plugin that the set Metadata belongs to.
Additionally, places where a plugin is referenced will now throw an
IllegalArgumentException if specified plugin is null. Using null would be an
obvious logical flaw, and in some cases produce additional exceptions later
in execution.
By: mbax <github@phozop.net>
This change lets JavaPluginLoader use a temporary HashSet to store
methods that could possibly have the EventHandler annotation. Duplicates
are prevented by the nature of a Set.
Registering parent listeners is a breaking change for any listener
extending another listener and expecting parent listeners to not be
called. Changing this is justified by the ease-of-use and proper object
inheritance design. If this is undesired behavior, the method may be
overridden without reapplying the method with the EventHandler notation.
By: Wesley Wolfe <weswolf@aol.com>
PlayerChatEvent is now Deprecated. It should be fired asynchronously, but
has not been so traditionally. To do so would massively break plugins that
rely on it.
AsyncPlayerChatEvent now replaces PlayerChatEvent. It uses comparable
functionality, but can be fired without synchronizing to the event manager.
The event will sometimes fire synchronously if triggered by a plugin.
Because PlayerChatEvent is now deprecated, PlayerCommandPreprocessEvent will
no longer extend PlayerChatEvent. This is almost completely source and
binary compatible, bar plugins that downcast to PlayerChatEvent.
Additionally, some methods that are non-functional have been marked
deprecated and indicate such.
Additionally, new constructors are now provided to allow for lazier
initialization of the receiving player set. A note has been added stating
plugins should be prepared for UnsupportedOperationExceptions if the caller
provides an unmodifiable collection.
By: Wesley Wolfe <weswolf@aol.com>
This is now done after the event to allow you to be able to get previous damageCauses, and is now only applied if the event is not canceled.
By: feildmaster <admin@feildmaster.com>
ChatColor searches from the start to the end of a string for chat format
characters but this always has to search the entire string. By starting
from the end of the string and working backwards we can stop searching once
we find a color code or a reset code as any previous formatting is wiped
out by these.
By: Travis Watkins <amaranth@ubuntu.com>
- Uses enharmonic equivalences to rewrite the note in the normalized form, E-sharp becomes F and A-flat becomes G-sharp
By: Celtic Minstrel <celtic.minstrel.ca@some.place>
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>
Added new NETHER_PORTAL and END_PORTAL values to the TeleportCause enum
and relevant constructor for PlayerPortalEvent.
By: James Clarke <jamesrtclarke@me.com>
This metadata implementation has the following features:
- All metadata is lazy. Metadata values are not actually computed until another plugin requests them. Memory and CPU are conserved by not computing and storing unnecessary metadata values.
- All metadata is cached. Once a metadata value is computed its value is cached in the metadata store to prevent further unnecessary computation. An invalidation mechanism is provided to flush the cache and force recompilation of metadata values.
- All metadata is stored in basic data types. Convenience methods in the MetadataValue class allow for the conversion of metadata data types when possible. Restricting metadata to basic data types prevents the accidental linking of large object graphs into metadata. Metadata is persistent across the lifetime of the application and adding large object graphs would damage garbage collector performance.
- Metadata access is thread safe. Care has been taken to protect the internal data structures and access them in a thread safe manner.
- Metadata is exposed for all objects that descend from Entity, Block, and World. All Entity and World metadata is stored at the Server level and all Block metadata is stored at the World level.
- Metadata is NOT keyed on references to original objects - instead metadata is keyed off of unique fields within those objects. Doing this allows metadata to exist for blocks that are in chunks not currently in memory. Additionally, Player objects are keyed off of player name so that Player metadata remains consistent between logins.
- Metadata convenience methods have been added to all Entities, Players, Blocks, BlockStates, and World allowing direct access to an individual instance's metadata.
- Players and OfflinePlayers share a single metadata store, allowing player metadata to be manipulated regardless of the player's current online status.
By: rmichela <deltahat@gmail.com>
Removed internal collection leaks from PluginDescriptionFile
BREAKING: PluginDescriptionFile.getAuthors() now returns List instead of
ArrayList
Various places with unsafe generics, notably List<Object> getList() in
Configurations are now referenced as <?>. This is nonbreaking, but
sourcecode will need to be revised when compiled.
By: Wesley Wolfe <weswolf@aol.com>
This also allows, for instance, to parse complex numbers with imaginary part=0, if the according toString method omits zero components.
This also saves some unboxing (Foo.valueOf returns a wrapper, while Foo.parseFoo returns a primitive)
By: TomyLobo <tomylobo@nurfuerspam.de>
