Any new API here needs more thought, skulls require a name but OfflinePlayer
is not guaranteed to have one. There is a Mojang approved way to get a
complete profile from a name but not from a UUID so for now just pretend
this still only uses names.
The getEntries methods on these return player names instead of UUIDs.
As we need the UUIDs for our API we add a getValues method to get at
the data we need. To further ensure we get the most data possible we
also add a way to get at the stored GameProfile to ensure we always
have both the UUID and the name from the list.
In the 1.7.5 update the diff that called book edit events when editing
books was accidentally dropped because of nms changes within the file.
This commit re-adds the craftbukkit call to restore event behavior.
The server's check is for whether or not a player can pass the whitelist
not just if the player is on it. That seems like more useful information
but the API has always just checked if they are on it so this commit
restores that.
When getting an OfflinePlayer by name we lookup their UUID and then
use that to fetch the OfflinePlayer. If the player has not played on
this server before the resulting OfflinePlayer will return null for
getName(). As this is unintuitive we now create the OfflinePlayer directly
using the profile we looked up and make OfflinePlayer prefer that data.
When working with inventories you regularly end up with different
Inventory objects that have the same underlying Minecraft inventory.
Currently, even those these point to the same thing, they are not
considered equal. With this commit comparing any Inventory object that
represents the same inventory will result in equals(Object) returning
true.
The method in EntityLiving to remove a potion effect was remapped during
the 1.7.5 update. The method invocation in CraftLivingEntity was not
updated to invoke the remapped method, which has led to a random method in
LivingEntity being called in its place.
This commit corrects the behavior of removePotionEffect by changing the
method to invoke the remapped method as opposed to EntityLiving#m(float).
Thanks to @gabizou for finding this issue.
Teleporting a player checks to see if the player is disconnected to
try to avoid creating ghost players. The check it uses, however, randomly
fails when the player is in the middle of joining the server. The check
that would work correctly here does not work correctly when the player
actually disconnects. To work around this we add a new flag which is
cleared on the first tick of the new player and assume they are connected
if the flag is set.
When VanillaCommandWrapper dispatches a command containing a
PlayerSelector wtih c>-1 (implicitly true for @a), it loops over the
selected players and exectures the command with each player. However, the
loop index is only incremented if the command fails. As a result, a
successful command is repeated on the same player indefinitely, locking up
the server. This commit fixes the issue by incrementing the loop index
regardless of whether the command succeeds, ensuring the command is only
executed once per player identified by the PlayerSelector.
If a plugin causes an entity to be removed from the world while the
world is ticking entities the ticking loop gets out of sync and fails due
to trying to go beyond the end of the entity array. To ensure this doesn't
happen we store the loop position as a field so we can fix it up in the
entity remove method just like the tick method does when it removes an
entity.
Previously the alias system would pass all arguments from the alias
to its command(s) implicitly. The new system requires arguments to be
explicitly passed so server owners can have more control over where and
how they are passed. To ensure this isn't a breaking change during the
migration from bukkit.yml to commands.yml we now add the $1- argument
to the alias commands to match the previous behavior.
Previously no implementation existed to access various additional
information fields regarding bans. This implementation expands on the
information outlined in the sister Bukkit commit to provide access to
the Minecraft implementation of the ban system.
This implementation of the banning API contains 2 new classes which
provide access to the internal workings of the built-in banning
system within Minecraft.
The CraftBanEntry class simply supports the representation of an internal
Minecraft BanEntry object. The data that may be modified within this new
object must be manually saved to the list contained within the
CraftBanEntry using it's save() method.
The CraftBanList class supports the representation of an internal
Minecraft BanList object through proxy methods. These methods do
validation on the passed objects where needed to ensure safe input to the
backed Minecraft objects.
These changes additionally re-route the existing banning API to the newer,
more detailed, system. Functionality prior to this change still behaves
as documented by the contract defined by the methods changed.
Books can now recieve more than one enchantment. As such, breaking out of
the loop after only 1 enchantment is applied is not the correct behavior.
This commit also reworks some of the logic surrounding the application of
enchantments to the item. By checking if the event doesn't add any
enchantments rather than if the original enchantments list is empty, the
application code is only reached if enchantments are applied, rendering
the "applied" boolean no longer necessary. The ItemStack's Item should only
be set once, so it is now set outside of the loop based upon whether or not
"flag" is true (with "flag" being whether or not the ItemStack's Item is a
book).
Hanging entities are placed into the entity tracker and updates are sent
out to clients for the initial placement. Thereafter data watchers are
configured to monitor the item inside the frame. However, if the
direction the ItemFrame facing changes the entity tracker will not send
out updates.
This commit removes and recreates the ItemFrame entity in the same way
that was already done for Painting entities. This causes clients to
be updated appropriately.
Previously any entities spawned through dispensers (monster eggs) or
by nether portals were given the incorrect SpawnReason of SPAWNER_EGG.
This made it impossible to distinguish what exactly happened in regards
to the creature being spawned.
A method in ItemMonsterEgg has been added to further fine tune reasons
for spawning creatures. This permits the DISPENSE_EGG reason to be used
correctly and accuratly as well as the NETHER_PORTAL reason due to how
BlockPortal spawns the mobs.
The redirected method, a(World, int, double, double, double), is still
called by the ItemMonsterEgg itself and therefore uses the default reason
of SPAWNER_EGG. This does not change previous behaviour.
Prior to this commit, a player disconnected during a respawn event would
remain in memory. This causes a ghosting issue of players in the slot
count and player list, as well as a reference leak.
This commit avoids re-adding the player to the player list (and world) if
they are disconnected. This ensures that the remainder of the respawn
logic is completed as well as ensuring a duplicate player is not left on
the server.
This commit also saves the player's file at the end of the method if they
have been disconnected to ensure that their next login is accurate to the
respawn event's actions. A player that was revived and disconnected will
reconnect as revived.
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.
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.
Calling this event allows plugins to react to the situation by simply
handling a normal damage event, possibly using existing code to
handle other entity damage.
Pulled from PR #1279
A vanilla server does a series of checks for the client black-listing
certain chat types (commands or chat). This change changes a CB
whitelist to the vanilla blacklist behavior.
This implements the detonate method from bukkit by setting the fuse
timer to 0. This makes a firework explode using the normal codepath,
but without waiting for the fuse.
The validation check in CraftMapView.render(CraftPlayer) filters out any
values less than 0. As of Minecraft 1.7, -128 through -113 are valid colors,
so filtering them out prevents some of the new colors from being sent.
This commit fixes the issue by adjusting the validation check to include
any values less than or equal to -113. As the minimum value for a byte is
-128, no invalid colors are included.
WorldGenerator setType and setTypeAndData have their arguments changed to
add in support for CraftBlockChangeDelegate, which changes the method
signature. This change in the method signature breaks any WorldGenerators
that aren't modified to use CraftBlockChangeDelegate.
This commit fixes the issue by readding the old method and maintaining the
CraftBlockChangeDelegate method. This makes it so that there is a
compatible method for both CraftBlockChangeDelegate WorldGenerators and
unmodified WorldGenerators.
Additionally, this commit reduces and corrects the diffs in
WorldGenerator, moving the fix for layering violations to
CraftBlockChangeDelegate.
A Block object is now passed in place of the previous id value, so the
obfuscated name for all subsequent arguments was shifted. As such,
BlockCanBuildEvent was using the incorrect values for both the material
and the location of the event.
This is corrected by swapping the values into the correct order and
providing an id based upon the Block passed into the method.
CraftBukkit modifies the IRecipe interface, adding new methods, so all
classes that implement IRecipe need to be imported and modified to add the
new methods.
Extending ShapelessRecipes implements the added methods and allows
RecipeBookClone to work with the Recipes API in a way that is consistent
with similar recipes, even if the recipe information present in the API
isn't technically correct.
Adding or removing operators was mistakenly using a loose player lookup
method, which would cause a permission refreshes on an online player whos
name starts with the name of the (offline) opped player.
Add/Remove op operations are exact name match only and the permission
refresh will behave the same way.
Both log4j and our own jline/jansi initialization attempt to catch
errors caused by jansi's use of native libraries. However both of them use
the Exception type which does not catch all errors. On Windows Server 2008
R2 Enterprise without installing extra software the required C++ libraries
are not available which causes an error that does not extend Exception. To
ensure we catch all errors I've changed both of these to catch Throwable
instead which gets us a working console minus jansi functionality.
l previously was the block id, however Minecraft's refactoring means that
the method is now passed a Block reference rather than the id. l is now
the data value of the block, so the block retrieved with that value is not
the correct block to be testing.
Something the log4j ConsoleAppender does makes the console work correctly
on Windows. After trying to pull pieces of it out and run them manually
I decided to just put the appender back. We now once again start with the
ConsoleAppender then remove it immediately after starting.
WorldMapCollection stores scoreboard, map (item), structure, and
village information. Scoreboards are explicitly handled globally,
while villages and structures are erroneously shared.
This commit separates the WorldMapCollections to not be shared among
custom worlds. Maps are special-cased to maintain the previous shared
behavior.
This change will print a warning when a plugin induces a forced save. A
player or console forcing a save (via a command) is ignored for purposes
of printing a warning.
When Minecraft first introduced an auto-save feature, we
were taken by surprise by how much of an impact it actually had on the performance
of the server. After investigating the potential causes of the significant
slow-downs we saw at the time, we came to the conclusion that it was a
combination of the auto-save interval being incredibly frequent and
servers already having an auto-save solution that was conflicting with the
newly added built-in one.
Since we noticed that most servers already had their own auto-save
solution, we decided to completely disable the built in auto-save by
default. In hindsight, however, we were so happy that we discovered and
squashed the cause of the performance issues that we forgot to consider
the future and, as a result, some servers have unfortunately been caught
by surprise when they ran their servers without any auto-save plugins.
Without the auto-save plugin conflict, however, Minecraft's default save
interval of 45 seconds is not suitable for the types of servers that run
Bukkit, to the point where it was negatively impacting performance. As
such, we've decided to re-enable the built in auto-save at an interval of
5 minutes for newly created servers.
The WorldMapCollection object for SecondaryWorldServers(Nether, End) is
shared with the main world, so saving it again for each SecondaryWorldServer
is redundant.
This commit removes the redundant call by checking if the WorldServer is an
instanceof SecondaryWorldServer before invoking worldMaps.a().
The recent Minecraft update rendered the
e20e50f85083dc53cb5456254bcf5781ef750daa fix incorrect by adding a
compound name to the base tag in some code. This fix changes all uses
of tag changes to explicitly use a name.
When a "uid.dat" file is corrupt (empty or <16 bytes), WorldNBTStorage
will silently fail to read and return null. Non-null behavior is
expected everywhere that this value is used.
This change will force a random UUID when the previous UUID cannot be
read, and getUUID to no longer silently ignore read/write exceptions.
This change adds the location and a more specific message to the
IllegalArgumentException that gets thrown when a hanging entity is being
spawned in a location that it cannot survive.
Opening a hopper inventory created by Server.createInventory will
currently have no effect as proper handling code is missing in
CraftEntityHuman for hopper inventories that aren't associated with a tile
entity or minecart. Initialization logic for hoppers is also missing from
CraftContainer, which is necessary for the opening of custom hopper
inventories.
This commit fixes the two aforementioned by adding proper handling to
CraftHumanEntity for opening inventories not associated with a tile
entity, and by adding initialization logic for hoppers to CraftContainer.
Previously fires spawned by lightning strikes were in the wrong locations.
This introduced the possibility of having blocks replaced when they should
not be.
EntityLightning now uses the correct locations as defined to spawn the
fires when needed.
When an entity is being moved as the passenger of an entity from one
entity to another, a VehicleExitEvent is fired, but it is assumed that the
current entity is a Vehicle. However, entities can be passengers of more than
just Vehicles, which causes a ClassCastException to be thrown.
This commit fixes the issue by checking that the current entity's vehicle's
bukkitEntity is an instance of Vehicle before casting it to Vehicle.
Prior to this change when a plugin called Player.hasLineOfSite() the
method would always return false because EntityHuman does not extend
EntityInsentient. This commit changes that by explicitly checking for
line of sight between two entities and returning that value.
Maven paths that include spaces (and possible other characters) get
improperly translated when using a file handle from a URL. This changes
the unit test to open a stream directly from the URL, providing proper
file resolution on multiple platforms.
This commit removes chat wrapping. It is no longer needed, as clients
properly render lines with line breaks.
This commit also changes an outgoing chat message to use the vanilla
behavior for indicating a client cannot chat with commands-only setting.
If a plugin generates an exception when returning a world generator, the
server will crash. This change adds a try-catch block to keep the server
from crashing on plugin defined world generators.
Custom inventories currently do not validate the titles provided. Null values
cause NPEs when writing packets. Values longer than 32 characters
disconnect clients.
This change throws and IllegalArgumentException for null titles or titles
longer than 32 characters.
The unleash event is only called for animals that are sitting - ones that
receive no movement vector. This adds the missing event call for
non-sitting animals.
When only considering trackers from player perspective, attach entity
packet could be sent before a packet for a respective vehicle is in view
and will, in turn, be ignored.
This adds another notification when the vehicle comes into view to cover
all cases.
A method has been added to Player which allows the server to send a sound string to the client. Assuming the client has the specified sound, it will be played. This is needed by the implementation of the /playsound command.
Items that cause entities to change state, including tags, chest, and
leashes, do not update the client properly following the firing of
PlayerInteractEntityEvent. This change makes the item checks occur
before the event fires, to concur with the client's assumptions.
This commit implements the ability to set the scale of hearts that the
client renders. When the Packet44UpdateAttributes packet is sent, the
max health attribute is replaced with a scaled version, to preserve the
scaled health illusion clientside.
In order to accurately display the scaled health for players, a true
health is stored within CraftPlayer, and the datawatcher now stores the
scaled health. The getHealth() method for players still returns their
true health.
Changed setHealth() within EntityLiving to appropriately handle health
for instances of EntityPlayer. Inlined a call to
setHealth(getMaxHealth()) within the EntityLiving constructor to work
around CraftEntity instantiation.
Additionally fixes the health values sent when eating food within
FoodMetaData and ItemFood, which previously sent the unscaled health;
this commit alters them to send the properly scaled health.
Additionally fixes BUKKIT-4535, BUKKIT-4536, and BUKKIT-4127
This changes livingEntity.addPotionEffect(PotionEffect, boolean) to
construct the MobEffect using the constructor that includes the ambient
setting as supplied by the PotionEffect
This also changes livingEntity.getActivePotionEffects() to construct the
PotionEffects using the ambient setting supplied by the MobEffects.
This change makes it so that EntityHuman#setPassengerOf(Entity) invokes
its parent method when leaving vehicles so that VehicleExitEvent is fired
for players leaving vehicles.
This change also fixes BUKKIT-2110, making it so VehicleExitEvent
correctly handles cancellation. The implementation of VehicleExitEvent
completely ignored the cancellation state of the event, making it so that
cancelling the event had no effect. Cancelling a VehicleExitEvent now
causes the entity to remain inside of the vehicle, with no visual stutter.
API has been added to interface with Horses and to modify their inventories. Horse entities will now be recognized with the type EntityType.HORSE, and will no longer be UNKNOWN.
HorseJumpEvent, EntityDamageEvent, and EntityTameEvent are all correctly fired for horses.
This commit fixes BUKKIT-4393.
Cancelling InventoryDragEvent causes the placed items to be lost. This is
because the cursor is set to the result prior to the event taking place,
so the items are removed from the cursor. When the event is cancelled, the
items removed from the cursor aren't placed in the inventory, and are just
lost.
This change sets the cursor back to the original cursor when the event is
cancelled.
Cancelling an InventoryClickEvent for a single click causes the click not
to be processed by the clicked inventory. The server then doesn't
correctly identify their second click as being a double click, causing an
inconsistency between what the Player believes the inventory to be and
what the server believes the inventory to be.
This change forces an updateInventory call whenever an InventoryClickEvent
whose action is NOTHING is cancelled. Both clicks are considered
PICKUP_ALL, so updating the inventory after the second click fixes any
inconsistencies that could arise between the client and the server.
Currently, the method used for calculating the damage of zombies is scaled
to their health, but it uses the default max health rather than the real
max health value. If zombies have more health than the default max health
value, the amount of damage they deal becomes negative.
This is caused by EntityZombie.getMaxHealth() returning a hardcoded value of
20, which is the vanilla max health for zombies. Rather than using this value
when calculating zombie damage, the call is changed to instead use
((CraftLivingEntity) this.bukkitEntity).getMaxHealth(). This uses the true
maximum health of the Entity. "this.maxHealth" could be used instead of the
aforementioned method, however that creates a very unclear diff, and a
confusing change.
When a Player drops an ItemStack while in creative mode by placing it outside
of their inventory window, the slot number in the packet is -1. The check
that was added to avoid throwing InventoryCreativeEvent excessively didn't
take this into account, and would cause an ArrayIndexOutOfBoundsException to
be thrown when attempting to get the slot specified by the packet.
This change shorts the invocation of player.defaultContainer.getSlot(
packet107setcreativeslot.b) to only occur if the slot id is within the range
of the Inventory. This prevents attempting to get the slot from a location
that is actually outside of the Inventory.
This commit brings the InventoryClickEvent up to date with the new Minecraft
changes in 1.5.
InventoryDragEvent (thanks to @YLivay for his PR) is added to represent the
new "dragging" or "painting" functionality, where if you hold an itemstack and
click-drag over several slots, the items will be split evenly (left click) or
1 each (right click).
The ClickType enum is used to represent what the client did to trigger the
event.
The InventoryAction enum is reserved for future expansion, but will be used to
indicate the approximate result of the action.
Additionally, handling of creative inventory editing is improved with the new
InventoryCreativeEvent, and handling of numberkey presses is also improved
within InventoryClickEvent and CraftItemEvent.
Also, cancelling a creative click now displays properly on the client.
Adresses BUKKIT-3692, BUKKIT-4035, BUKKIT-3859 (new 1.5 events),
BUKKIT-2659, BUKKIT-3043, BUKKIT-2659, and BUKKIT-2897 (creative click events).
We only go through event creation and calling when dispensing filled buckets
if the bucket is able to place its liquid. However, the check for this is
incorrect so the event is not called when a block liquids can destroy is
in front of the dispenser. This commit fixes the check to match the checks
vanilla does when actually using the bucket.
The CraftBlock class is setting bit 0x4 of the update flag when bit 0x2
should in fact be set here. Bit 0x2 means "do updates"; bit 0x4 means
"don't do updates if the world is static, even when bit 0x2 is set".
Minecraft 1.5.2 changed mob spawning by ignoring persistent mobs from the
mob count. In CraftBukkit all mobs that previously used a separate hard
coded persistence system were ported to instead use this one. This causes
all animals to be persistent by default and thus never be counted. To
correct this issue we consider if the mob would be considered persistent
in the hard coded system as well when deciding if a mob should count.
Currently there are several cases where a player will have their inventory
screen closed client side but we will not call an event. To correct this
we call the event when the server is the cause of the inventory closing
instead of just when the client is the cause. We also ensure the server is
closing the inventory reliably so we get the events. Additionally this
commit also calls the event when a player disconnects which will handle
kicks, quits, and server shutdown.
As an optimization we don't do any movement processing on entities that
have not moved. However, players in minecarts trigger this condition when
the minecart is moving on its own. This causes issues with things that rely
on player collision like tripwires. To correct this and any future related
issues we always handle movement for passengers and their vehicles even
if one of the two hasn't moved since they are linked.
When converting things in Minecraft to use wall time instead of ticks I
realized we'd run into integer division rounding issues and could have
updates that end up counting as zero ticks. To compensate for this the
code ensures we always process at least one tick. However, every time we
end up with zero ticks the next time we have an extra tick due to rounding
the other way with the leftovers. This means we are going far too fast and
should not have this at least one tick logic at all.
On top of this some potions rely on the number of ticks they run and not
just the amount of time they last and so potions were put back to running
with ticks entirely.
If a chunk has somehow managed to save with arrays that are not 4096
entries long when reading them again we will get exceptions. Checking the
array length and resizing if needed is cheap so we should do this to help
avoid crashing servers due to this error.
When a chunk is being loaded the server checks to ensure the chunk's idea
of where it is located matches where it was located in the region file. If
these two values do not match the chunk's idea of its position is updated
and the chunk is reloaded. In vanilla minecraft this loading involves the
chunk's tile entities as well. With the change to loading player chunks
asynchronously we split loading tile entities to a separate step that takes
place after this check. Because of this tile entities are loaded with
invalid locations that result in trying to fetch block data from negative
or too large positions in the chunk's internal block storage arrays.
Because loading the tile entities is not thread safe we cannot return to
vanilla behavior here. Instead when we detect a misplaced chunk we just
edit the NBT data for the chunk to relocate the tile entities. This results
in them moving correctly with the chunk without having to actually load
them first.
If a hopper is unable to perform any action during a tick it attempts to do
so every tick from then on. Once it is able to do so it then sets a delay
before attempting to do something again. To avoid excessive CPU usage for
hoppers sitting idle we now apply this delay regardless of the success of
the action.
When using the new feature in 1.5 to drop the item in any highlighted slot,
the anvil result slot does not apply the full anvil calculation that picking
up the item does, including the experience calculation.
Currently furnace smelting and the item pickup delay timer use wall time
(aka actual time passed) to emulate a constant tick rate so run at the
same speed regardless of the server's actual tick rate. There are several
other places this makes sense so this commit converts them.
The item despawn timer is converted so now always takes 5 minutes. Users
know this 5 minute number well so keeping this constant helps to avoid
confusion. This also helps alleviate lag because if a large number of item
drops is the reason your server is running slowly having them stay around
longer just means your server is slow longer.
Potion brewing and the zombie villager conversion timer are now constant.
These match the furnace criteria of being useful for hiding lag and not
having a detrimental effect on gameplay.
Potion effects are now also using wall time. The client is told about effect
times in ticks and displays this information to the user as minutes and
seconds assuming a solid 20 ticks per second. The server does have
code for updating the client with the current time remaining to help
avoid skew due to differing tick rates but making this a constant makes
sense due to this display.
Add a check to avoid doing movement work if an entity doesn't move. This
usually will not ever happen in the current server but is useful when it
does and will be more useful in the future.
Only process mob on mob (non-player) collisions every other tick. Players
tend to pack a lot of mobs into a small space (sheep farm, mob grinder, etc)
so they do a lot of work processing collisions. To help alleviate some of
this we only run these calculations every other tick. This has no visible
effect on the client but can be a huge win on the server depending on
circumstances.
Use generic entity inWater checking for squids. Squids have their own logic
currently for determining if they are in water. This check is almost
identical to the generic entity checking which is run anyway. To avoid
doing duplicate work we just remove the squid version. This does not
have any noticeable effect on gameplay since the checks are so similar.
Use HashSet for tile entities instead of ArrayList. Using an ArrayList for
storing tile entities in a world means we have very expensive inserts and
removes that aren't at the end of the array due to the array copy this
causes. This is most noticeable during chunk unload when a large number of
tile entities are removed from the world at once. Using a HashSet here uses
a little more memory but is O(1) for all operations so removes this
bottleneck.
When a player comes into range of an entity in a vehicle they will often be
sent the spawn packet for the rider before receiving one for the vehicle.
This causes the attachment packet to fail client side because it attempts
to attach the rider to a vehicle that doesn't exist on the client. To
correct this we account for both possible orderings and send the
attachment packet appropriately.
Vanilla also sends an new attach packet every 60 ticks even if the vehicle
has not changed. As this packet is a toggle this resulting in players
teleporting around randomly. Since we handle attachments properly now we
simply revert this section to use the 1.4 logic.
When looking up tile entities for a chunk to send to a player we currently
loop through every tile entity in the world checking if it is within the
bounds of the relevant chunk. Instead of doing this we can just use the
tile entities list stored in the chunk to avoid this costly searching.
As a further optimization, we also modify the generic range-based lookup
to use chunks as well. For most lookups this will give a smaller search
pool which will result in faster lookups.
Thanks to @mikeprimm for the idea and most of the implementation.
In certain scenarios a boat can be killed multiple ways in a single tick.
Due to improper guards this can cause the death code to run multiple times
creating item drops. To correct this we insert the appropriate death check.
