This commit centralizes event handling to where damage is actually applied
to the entity to avoid bugs that have resulted from nodamageticks,
modifications to damage after the event has been called, and similar
mishaps. This also implements new API for getting and setting of
modifications made to the damage amount actually applied to the entity.
This is done by storing the change in the damage amount as each modifier
is applied by vanilla code.
The method that actually damages the armor worn by an entity has been
relocated beneath the event called as to not apply durability loss when
the event has been cancelled.
When a chunk is loaded the server tries to ensure it has its initial light
calculations done before sending it to the player. When ticking entities
the server tries to ensure the entity does not walk into an unloaded chunk.
To accomplish these the server checks a one chunk radius around the chunk
to be lit or a two chunk radius around the chunk the entity is in. These
lookups happen every tick even though their result is unlikely to change
that often. To reduce the cost of these checks we replace them with a
system to keep track of what neighbor chunks a chunk has loaded and update
it when chunks load or unload which is a much less frequent action. On a
server with ten players this change removes about 100,000 calls a tick to
LongObjectHashMap's containsKey method.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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.
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.
