| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
BUKKIT-3060
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
e93a3eb3b4c5234e3e3936bc697d566a42d3b30e. Fixes BUKKIT-4214
In the 1.2 update for CraftBukkit, a missed diff resulted in Skeletons no longer firing an EntityShootBowEvent when they shoot an arrow.
|
| |
|
|
|
|
|
|
|
| |
launchProjectile(...). Fixes BUKKIT-1536
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.
|
