| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
| |
Make sure we check the inventory's max stack size where appropriate and
don't assume the inventory slot is able to take our entire stack just
because it is empty. We also ensure the client is updated with the correct
slot contents and cursor contents in cases where the max stack changes
result in different behavior than the client expected.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It's currently not possible for a plugin to allow enchanting of an
otherwise un-enchantable item using the enchanting table. This commit
causes EnchantItemEvent to be called with an empty list of enchantments,
allowing a plugin to provide it's own set of enchantments when vanilla
Minecraft would not allow any. It also bypasses the unsafe enchantment check
since a plugin should be permitted to apply any enchantments they like, and
vanilla should not generate unsafe enchantments of its own.
|
| |
|
|
|
|
|
|
|
| |
Currently, whenever a player places a block in a protected area the
equipped itemstack size on client is never updated properly since the
client thinks the block was placed. The reason this happens is because
ItemStack.matches returns true since the server does not decrement stack
size if a BlockPlaceEvent is cancelled. To correct this on cancel we set
the flag to always update the client regardless of matching.
|
| |
|
|
|
|
|
| |
Currently if a plugin cancels an InventoryOpenEvent for vanilla chests,
the chest animation for clients is stuck in the open state since
IInventory's closeContainer method is never called. To fix the issue,
closeContainer is called before exiting the display GUI method.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Adds BUKKIT-5388, BUKKIT-5387, BUKKIT-5386, BUKKIT-5483, BUKKIT-5484.
Fixes BUKKIT-5389.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
