In some situations, an async task could be cancelled with no tasks
pending. This means the finally {} block from run() never gets executed
properly on the last async task to have run, as it expected to be
executed again.
This fix takes the only spot that the task period is set to cancelled
and will check to see if the task should be purged from the runners
list.
By: Wesley Wolfe <weswolf@aol.com>
Some meta functionality is refactored into common methods.
CraftItemStack uses the ItemMetaKey identifiers for enchantments.
Refactored unit test to include extra functionality; initially only
checking the presence of the DelegateDeserialization annotation.
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>
The purpose of the isSimilar method was designed to consider all NBT
data, not solely enchantments, without the need to have exact stack
size matches. The respective methods in CraftInventory were still
comparing enchantments instead of the ItemMeta.
By: Wesley Wolfe <weswolf@aol.com>
Changes some NPEs to IllegalArgumentExceptions for exception consistency.
Contains(ItemStack, int) correctly calculates number of ItemStacks.
Adds a containsAtLeast(ItemStack, int) for finding a combined amount of a
single similar ItemStack.
Makes some utility methods private to prevent ambiguity in use.
By: Wesley Wolfe <weswolf@aol.com>
When a player triggers a chunk load via walking around or teleporting there
is no need to stop everything and get this chunk on the main thread. The
client is used to having to wait some time for this chunk and the server
doesn't immediately do anything with it except send it to the player. At
the same time chunk loading is the last major source of file IO that still
runs on the main thread.
These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure. The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.
There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.
The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.
Thanks for @ammaraskar for help with the implementation of this feature.
By: Travis Watkins <amaranth@ubuntu.com>
This class is a general purpose task execution system, that uses stages
to separate processing blocks for asynchronous and synchronous
executions.
By: Wesley Wolfe <weswolf@aol.com>
Adds:
- Getting/Setting equipment
- getting/setting drop rates
- getting/setting ability to pick up items
-- As an added feature, players with this flag start off with a canceled PlayerPickupItemEvent
By: feildmaster <admin@feildmaster.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>
Fixes fireballs exploding in the shooter's face and not having a shooter for the projectile. (Two birds with one stone!)
By: feildmaster <admin@feildmaster.com>
org.bukkit.craftbukkit and net.minecraft.server will now include the
minecraft version in the package name. As the internal implementations
are known to change dramatically, this refactor reduces the strain on
support requests due to version mismatching.
org.bukkit.craftbukkit.libs will also have version numbers for each
imported set of packages. These are not dictated by the minecraft
version number. This is done to prevent future incompatibilities.
By: Wesley Wolfe <weswolf@aol.com>
