Currently we use the async chunk loading system only when players trigger
chunk loading. If a chunk is loaded for any other reason it goes through
a separate codepath. This means if a player has trigged a chunk load and
before the chunk loads something else wants the same chunk we will load it
twice and throw away the second result. With this change we instead use
the sync processing feature of the AsynchronousExecutor to load the chunk
which will pull it out of the queue if it was already queued to load. This
means we only ever load a chunk once. Because chunk generation is not
thread safe we still fallback to the vanilla chunk loading system if the
chunk does not currently exist.
Previously we attempted to call interact events in cases that were missing
by modifying the arm swing logic. This, however, was too broad and started
triggering events in cases we already covered leading to duplicates. Since
the only case we can handle cleanly and the primary point of the previous
fix was fluids we now instead simply treat fluids as air for this check.
This also ensures we do not get duplicate events when the player is in a
fluid and hits a normal block, unlike the previous change.
This reverts commit 68b702f7 and replaces it with a better fix.
The block obtained and stored within the block object higher up does not
reflect the block at the location being hit, rather it is the air block
the arrow was previously in. Thusly when the variable is used to check
if the arrow is still in the block, it fails.
Because EntityFireball.setDirection() adds a random offset to passed
parameters, it is not appropriate for use in an API method. As such,
the values need to be directly set to remain accurate.
Previously, trying to launch a ThrownExpBottle or Fish projectile would
result in an IllegalArgumentException. This commit adds support for both
ThrownExpBottle and Fish, which means that all current projectiles are
now properly supported by this method.
Previously, if an error occurred during CraftServer initialization before the
logger was instantiated, it would cause an NPE and the server would never
finish loading properly. By instantiating the logger before attempting to
load anything else in CraftServer, we ensure that a logger will always be
available in the case of any errors.
In 1.7, Minecraft changed Weighted Pressure Plates to allow players and
entities to interact with them, rather than simply changing redstone signal
based on the number of items on the pressure plate. This commit adds calls to
PlayerInteractEvent or EntityInteractEvent for every entity that steps on the
plate.
ItemStacks do not stack if one has null for a tag, while the other has an
empty tag. In CraftItemStack, if you set an item to an empty ItemMeta, it
will create an empty tag for the internal ItemStack.
This changes the setItemMeta function to check for empty meta, and then
use null for the tag instead of an empty NBTTagCompound.
The method being called was renamed during the 1.4.2 update process
but the function call was not replaced accordingly, leading to a
missed diff from 314051580a0a8e4745d3a539f232b552916eb302.
Damage caused by explosions will return null for the event as of
6588d6f72bbca74bf150de65593ac575b846111b. As such, a null check is
now necessary when handling non-living entity damage events.
When falling back to vanilla recipes in the iteration of recipes,
a check is necessary to ensure that vanilla recipes are present.
RecipeIterator has been modified to account for the multi-map setup.
In commit f94b7af8 I delay removing the block until after running the
block's cleanup code to avoid errors. However, this causes problems of
its own due to blocks not being written with this in mind. To avoid blocks
getting recursively removed we now only delay removing containers since
they are the only ones we had problems with to begin with.
When setting a block the server sets the new block ID, calls the cleanup
on the old block, then calls the placement logic for the new block. This
would normally work correctly but we have logic to prevent errors that is
causing one here. When trying to clean up the old block we notice the block
ID has changed and try to fix things, this causes the cleanup logic to
fail. To ensure cleanup happens correctly we now do all the cleanup before
changing the block which avoids triggering the fixup code.
Due to vanilla blanket comparing data values, and the unspecified
order of hashmap iterators, we need to run through custom recipes
first, and therefore separately, to ensure that they are actually
used. By not adding the custom results to the experience table, we do
not override the experience gains from vanilla smelting recipes.
Setting a horse's passenger to a non-living entity will cause a
server crash when the horse ticks, we need to check that it is
a living entity before casting, and skip otherwise.
With the update in 1.7 that improved the server ping, it was made to
include a long version string for CraftBukkit. This value is too long
for proper display so we now send a shortened string consisting of
the server implementation and the minecraft version.
When we first added the reach limiter in CraftBukkit there was no
difference between how far the client could reach in vanilla while in
Survival or Creative. At some point in Minecraft's cycle Creative was
given a block extra to work with and our protection was not updated to
account for this. We need to respect the possibility of different game
modes in Minecraft providing the client with varying reach distances.
Due to an incorrect mapping of this method to a friendly name, we're
unfortunately calling the wrong method within EntityPlayer.reset() to
reset attributes. Instead of what we've mapped as "removeAllEffects", we
should be calling EntityLiving.aP(). This mapping should be corrected in
the next naming version.
In the CraftBlockState implementation, updating the blockstate onto
a block will force the block state data value onto the block.
Unlike vanilla which relied on block data being set when the type
changed, we must instead explicitely set the data in the blockstate.
Minecraft now uses resource packs instead of texture packs, which broke
the setTexturePack method, as the client no longer listens on the MC|TPack
channel.
This commit fixes the issue by adding in a setResourcePack method, and by
deprecating setTexturePack and rewriting it to call the newly added
setResourcePack. In order to simplify the method and prevent this from
happening in the future, setResourcePack calls EntityPlayer.a(String) to use
the same logic as minecraft when sending resource packs.
In Minecraft 1.7, URL processing was removed from the client while the
server gained the ability to designate a URL to be launched in response to
clicking text. However, this functionality is not implemented in the
vanilla server. This commit adds that functionality to messages sent to
the client, processing URLs as clickable.
Additionally, char array iteration is replaced with regex.
When growing trees we use a BlockChangeDelegate which queues up the block
changes so plugins can modify/block/log tree growing. However, we always
check the actual world when checking for existing blocks. This means when
the tree growing code checks to see if putting a leaf in a block is valid
it may incorrectly overwrite a log block that should exist in that
location. To ensure trees grow correctly we now check the delegate itself
for blocks that match the queried location before checking the world.
Commit c576054539790bdeb35285f62863d74b48c0782d removed the chunklist
collection stored in ChunkProviderServer, however it has been partially
restored in some places by 7e1ac0a77129b169704c1e222ff2deb3ab6cd2d2. As
not all references to this were restored, this has caused the chunklist
and chunks collections to become out of sync, resulting in a memory leak.
This commit removes chunklist from ChunkProviderServer again.
When ItemDye is used to place a Cocoa Block, the postPlace() method
should not be called, as data is handled within the ItemDye class.
However, if Cocoa is placed via its block item, postPlace() should
still be called to mirror vanilla behavior.
