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.
Due to changes in the generation of trees, the name of the class responsible
for the generation of jungle trees has changed from WorldGenMegaTree to
WorldGenJungleTree. As such, references to WorldGenMegaTree need to be
updated to WorldGenJungleTree to generate the correct type of tree.
Pulled from PR #1277
Several sounds were renamed in Minecraft 1.7, and have been updated
accordingly. Additionally, two sounds, HURT and BREATH, were removed from
Minecraft.
For Cocoa Blocks, Block.getDropType() returns the item form of the Cocoa
block, rather than the Cocoa Bean item. Because of this, Cocoa blocks need
to have explicit handling in order to return the proper drop contents.
Previously, due to the way that death events were called, Blazes only
fired death events when they dropped loot. This change fixes that,
enabling death events for Blazes whenever they die, regardless of loot
drops.
EnderDragons did not call an EntityTargetEvent when they
were targeting random players in the End. This commit
adds that event call into the targeting code.
Explosions directly caused by LivingEntities, such as creepers and tnt lit
by players, have their EntityDamageEvent explicitely handled within
the Explosion class. In order to prevent double events when damage
is handled for other DamageSources, we need return null for explosion
based damage sources.
The EntityLiving dealDamage method will not call an event for the
entity damage caused by an explosion without an associated
entity cause, therefore, the explosion caused by EnderCrystals
needs to be explicitely handled within the EnderDragon class.
Bukkits Visibility API should prevent players from seeing fall particles
of players that they cannot see. This commit alters the handling to
provide an EntityPlayer argument that is later used to determine if they
are visible.
We do ray tracing on arm swings to filter out swings that hit blocks since
punching blocks has its own event handling. However, some blocks cannot
be punched so the air interact type is still valid for them. Luckily
these blocks all have a means to query them so add an additional check
for this and don't fail the check for them.
This changes the logic for furnace smelt event to consider a result of
null (read: air / invalid), which will still consume an item. It also
properly considers item meta in the result, instead of only checking the
item data value.
Log4j takes a long time to load on startup. Before it loads, the server
appears to have frozen as there is no output until after. We now print
a loading message before this happens to let the user know the server
is actually working.
When pistons push/pull blocks they call Entity.move(float, float) to move
entities out of their path. For hanging entities this code path makes them
simply die and drop as an item. We now call an event in this scenario so
plugins can control this behavior.
Some types of damage are handled specially so do not end up returning an
event in handleEntityDamageEvent. To ensure we don't have problems with
these we need to check for them and simply ignore them, as they've been
handled already.
