| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
In commits 71a238ee and c8591397 we added checks while ticking to ensure
we never ticked anything in a chunk meant to be unloaded. We did this to
prevent these chunks being removed from the unload queue and leaked.
However, this causes a ridiculously large number of lookups on the queue
for a somewhat rare occurance. We also now have the chunk GC which will
take care of these leaked chunks when they do happen. With this in mind
we now remove these checks which removes almost all uses of the
LongHashSet backing the unload queue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the changes in d611cff2 we started including a mob's equipment when
calling EntityDeathEvent so plugins can access this data. However, the
changes to enable this triggered a bug that makes skeletons and pig zombies
no longer drop equipment because they handle this differently than the rest.
On top of this we don't handle dropping equipment for mobs that cannot
pick up items in vanilla even though vanilla does drop equipment for them
if you summon them with it. We also do not include a horse's inventory
in the event so they drop their saddle, armor, chest, and chest contents
with no way for a plugin to control this.
To solve this issues we revert mob item dropping back to vanilla logic
and instead just capture all their drops in the method they all call to
spawn them into the world. We also move horse inventory dropping so it
happens at a time when we're capturing these drops. With these changes
all items mobs drop on death should now be included in the event and
we have less diff to worry about for future updates.
|
| | |
|
| |
|
|
|
|
|
|
| |
Waiting to log until after PlayerCommandPreprocessEvent makes the server
not log anything if the event is cancelled. It also makes the server log
what a plugin changed the command to instead of what the player actually
tried to run. As the point of the log is to have a record of every command
a player attempts to run these are both not desirable.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In 7e37cf96 we modified the container logic to handle custom max stack
sizes better and ensure the client stays in sync with this scenario. This
had the effect of sending an extra set slot packet for every inventory
click a player did which was not wanted. These extra packets also cause the
client to recalculate recipes which breaks the result slot for custom
recipes. To avoid the extra packets in general we now only send them if the
max stack is not the one we started with. In the case of a setting a custom
max stack size on a workbench this is still not enough so we also now send
another extra packet to make sure the result slot is always correct.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To handle changes in 1.7.9 we changed skull meta to use GameProfile
instances instead of strings of player names. This reflects what vanilla is
actually storing for skulls now. As skulls still require a name our API was
not changed and we instead look up the rest of the profile information from
the name. The way this was implemented made it so that deserializing a skull
or setting its name potentially involved a network request. As skull meta
itself does not actually require a complete profile we now simply create one
that only contains a name and leave populating it to the server when it is
actually needed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With the current API it is possible to create an inventory with a specific
type, but it is not possible to give such an inventory a title other than
the default.
The commit changes that by adding a method to optionally supply the title
for the given inventory type and holder, creating the functionality to
display any supported inventory type with a 32 character length String.
If the inventory title supplied is larger than 32 characters then an
IllegalArgumentException is thrown stating so.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In commit 6efeddfe57, TALL_REDWOOD was used instead of the proper TreeType
of MEGA_REDWOOD. Additionally, this fixes an issue in CraftWorld with an
improper boolean flag related to the generation of MEGA_REDWOOD trees.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
23 classes have been removed as they are no longer needed using the new
capture logic. This should help quite a bit with future MC updates.
BlockPlaceEvent Refactor
Before calling Item.interactWith, a recording flag is turned on for
setTypeAndData to capture a blockstate for each block that attempts to be set.
When a block place event is cancelled, the recorded blockstate, stack
size, and metadata will revert back to the captured state. If the event is
not cancelled, a notification will be sent to clients and block physics
will be updated.
BlockChangeDelegate Refactor
Now that we have the ability to capture blockstates through world, there
is no need to modify world gen classes with BlockChangeDelegate. Instead
we will simply capture blocks during world generation in order to "replay"
all of the captured blockstates to send back to delegates.
StructureGrowDelegate and BlockSapling.TreeGenerator have also been
removed as part of this change. BlockSapling and BlockMushroom will
capture blockstates the same as block placement and revert back any grow
events if needed.
|
| |
|
|
|
|
| |
After the changes in c549609d anvils started incorrectly limiting their
inputs to single item stacks. Vanilla allows for full size stacks here and
this is useful for using materials to repair items so now we do too.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The AnvilInventory reports its size as the sum of the ingredient and
result inventories, but when trying to access the slots, only the
ingredient inventory is used, leading to an ArrayIndexOutOfBounds exception.
This change overrides getItem(I) and setItem(I) to use both inventories,
with the slot number adjusted based on their size.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Setting the goal target overrides the entity's will to do something
else. This makes it so entities like wolves with attack another player
with .setTarget(), instead of hanging next to their owner.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
If a conversation is abandoned due to a player disconnecting and an
exception is thrown in a ConversationAbandonedListener, the server will
crash. This commit prevents the exception from propagating further up
the stack and instead just logs the error.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
