| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
| |
For more information please see http://www.spigotmc.org/
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When using a "vanilla" Minecraft server using the "pick block" key on a
command block yields the invoker with a command block within their
inventory while in creative mode. Implications of the invalid items set
containing the command block also include having a "ghost" item that
cannot be placed due to it not actually existing.
This commit resolves the problem and brings Craftbukkit closer to vanilla
behaviour by removing the command block item ID, 137, from the invalid
items set.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When we first added the reach limiter in CraftBukkit there was no
difference between how far the client could reach in vanilla while in
Survival or Creative. At some point in Minecraft's cycle Creative was
given a block extra to work with and our protection was not updated to
account for this. We need to respect the possibility of different game
modes in Minecraft providing the client with varying reach distances.
|
| |
|
|
| |
Thanks for pointing it out RingOfStorms!
|
| |
|
|
|
| |
Relocate CraftBukkit patch to fall damage when changing
gamemode from creative mode.
|
| |
|
|
|
|
|
|
| |
We do ray tracing on arm swings to filter out swings that hit blocks since
punching blocks has its own event handling. However, some blocks cannot
be punched so the air interact type is still valid for them. Luckily
these blocks all have a means to query them so add an additional check
for this and don't fail the check for them.
|
| | |
|
| |
|
|
|
|
| |
A vanilla server does a series of checks for the client black-listing
certain chat types (commands or chat). This change changes a CB
whitelist to the vanilla blacklist behavior.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This change will print a warning when a plugin induces a forced save. A
player or console forcing a save (via a command) is ignored for purposes
of printing a warning.
|
| | |
|
| |
|
|
|
|
|
|
| |
This commit removes chat wrapping. It is no longer needed, as clients
properly render lines with line breaks.
This commit also changes an outgoing chat message to use the vanilla
behavior for indicating a client cannot chat with commands-only setting.
|
| |
|
|
|
|
|
| |
Items that cause entities to change state, including tags, chest, and
leashes, do not update the client properly following the firing of
PlayerInteractEntityEvent. This change makes the item checks occur
before the event fires, to concur with the client's assumptions.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Cancelling an InventoryClickEvent for a single click causes the click not
to be processed by the clicked inventory. The server then doesn't
correctly identify their second click as being a double click, causing an
inconsistency between what the Player believes the inventory to be and
what the server believes the inventory to be.
This change forces an updateInventory call whenever an InventoryClickEvent
whose action is NOTHING is cancelled. Both clicks are considered
PICKUP_ALL, so updating the inventory after the second click fixes any
inconsistencies that could arise between the client and the server.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a Player drops an ItemStack while in creative mode by placing it outside
of their inventory window, the slot number in the packet is -1. The check
that was added to avoid throwing InventoryCreativeEvent excessively didn't
take this into account, and would cause an ArrayIndexOutOfBoundsException to
be thrown when attempting to get the slot specified by the packet.
This change shorts the invocation of player.defaultContainer.getSlot(
packet107setcreativeslot.b) to only occur if the slot id is within the range
of the Inventory. This prevents attempting to get the slot from a location
that is actually outside of the Inventory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit brings the InventoryClickEvent up to date with the new Minecraft
changes in 1.5.
InventoryDragEvent (thanks to @YLivay for his PR) is added to represent the
new "dragging" or "painting" functionality, where if you hold an itemstack and
click-drag over several slots, the items will be split evenly (left click) or
1 each (right click).
The ClickType enum is used to represent what the client did to trigger the
event.
The InventoryAction enum is reserved for future expansion, but will be used to
indicate the approximate result of the action.
Additionally, handling of creative inventory editing is improved with the new
InventoryCreativeEvent, and handling of numberkey presses is also improved
within InventoryClickEvent and CraftItemEvent.
Also, cancelling a creative click now displays properly on the client.
Adresses BUKKIT-3692, BUKKIT-4035, BUKKIT-3859 (new 1.5 events),
BUKKIT-2659, BUKKIT-3043, BUKKIT-2659, and BUKKIT-2897 (creative click events).
|
| |
|
|
|
|
|
|
|
|
| |
Currently there are several cases where a player will have their inventory
screen closed client side but we will not call an event. To correct this
we call the event when the server is the cause of the inventory closing
instead of just when the client is the cause. We also ensure the server is
closing the inventory reliably so we get the events. Additionally this
commit also calls the event when a player disconnects which will handle
kicks, quits, and server shutdown.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
We used to fall Item.filterData() for this but that method is meant for
converting item data to block data during placement and does the wrong
thing for this case. Instead we just see if the item should have data and
if not set it to zero. We also have to filter wool data explicitly because
clients crash when given invalid wool data.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The player would have no permissions (other than their OP status)
when checked in the Quit event. This is because we removed permissions
before the event occurred. By calling it afterwards, we can persist
the data until the server finally removes the player.
|
| |
|
