Chunk caching in the World class does not know about outdated cache values.
This caused various problems when accessing previously unloaded chunks. The
caching also did not improve the performance so it is removed.
Synchronization is also not necessary, because all accesses to getChunkAt
may only come from the main thread.
Previously, Detector Rails were the only rails that properly called
BlockRedstoneEvent when they changed from powered to unpowered. This commit
adds BlockRedstoneEvent calls for both Powered Rails and Activator Rails.
Currently, plugins can set a player's display name to null, which could
cause issues for other calls to getDisplayName that aren't expecting a null
value. This changes setDisplayName to follow the same logic as
setPlayerListName, which sets the player's name back to their unmodified
"vanilla" name if it receives a null value as a parameter.
Previously, whenever BlockFadeEvent was called for ice melting, it returned
the new BlockState with a type of Material.STATIONARY_WATER. However, in
the Nether, ice melting does not form water, but is simply replaced by air
instead. This changes the event to use the proper BlockState based on
whether the block is located in the Nether or not.
CraftBukkit adds the ability to specify the maxStack size for most
inventories. However, some inventories were not overriding the getMaxStack
method properly, and so the functionality was unavailable. This fixes the
maxStack setting for Anvils, Minecarts, PlayerInventory, and Hoppers.
Previously, the SlotType for the last 4 slots in a player's inventory
returned QUICKBAR when it should have returned SlotType.CONTAINER. This
updates the code for determining slot type to return the proper value.
Previously, the SlotType for the 0 slot in a furnace returned CONTAINER,
when it should have returned SlotType.CRAFTING. This updates the code for
determining slot type to return the proper value.
Previously, when a skeleton was spawned via the spawn(...) function, the
resulting skeleton had no equipped bow and therefore could not properly
attack. This fix gives all skeletons the proper equipment and ensures that
they are able to attack.
Due to changes in how portals were created in Minecraft 1.7, the code that
was previously used to find the blocks involved in the PortalCreateEvent
no longer detected all blocks. Additionally, in the process of updating to
1.7.2, a missed diff resulted in some blocks that were found not being
properly added to the blocklist. This commit corrects that missed diff,
while also adding a check to ensure that the top and bottom of the portal
frame are included in the blocklist.
Adds BUKKIT-5370, BUKKIT-5377, BUKKIT-5378, BUKKIT-5379, BUKKIT-5380,
BUKKIT-5381, BUKKIT-5382. Adds reasons for zombies infecting villagers and
zombie villagers being cured. Readds reason for a skeleton being spawned as
a spider jockey. Adds reason to distinguish ocelot babies from the parent
they spawned with. Adds reasons for chunk generation causing the ender
dragon, villagers, and witches to spawn. And finally, adds a reason for
spawning a chicken mount for a baby zombie.
The old PaintingBreakByEntityEvent was deprecated and replaced by
HangingBreakByEntityEvent. However, in the case of being struck by
lightning, only the deprecated event was being called. This fixes that so
that both the new and old events are called appropriately.
Bans require a name and UUID but our API only allows for a single string
identifier for a ban entry. Until this is sorted out go back to the old
name based setup since we can always get a UUID given a name.
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.
