| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
| |
"Fish" is a badly named class to represent a fishing hook due to the
possibility (or lack of) that Minecraft may be getting fish entities.
This commit provides potential future compatibility by deprecating the
existing Fish class and moving the methods to a new class: FishHook.
|
| |
|
|
|
|
|
|
|
|
| |
When tab completing /deop, a potentially large set of players is used for
finding suitable player names. This potentially large set of players can
cause performance concerns on servers. To fix this, only the set of
operators should be considered for the /deop tab completion where the
player set is much more relevant and follows suit with other commands
which employ "more specific" player sets when possible. This commit adds
this more efficient behaviour.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we added the new API in EntityDamageEvent to give control over the
various things that modify the final damage done we caused a change in
behavior for users of the old #setDamage(double) method. Before changing
the damage would happen before the modifiers were calculated so they would
be based on the final damage value from the event. Now they are calculated
at the beginning so changing the damage does not change the modifiers.
To allow the old style and the new to coexist we now expose the vanilla
modifer calculations to the event in the form of Function objects. These
are used in #setDamage(double) to calculate the difference in the modifier
between the old damage and the new and apply this difference to the current
modifier. The difference is between the vanilla values for both damage
values and is applied on top of the event's modifier value as this should
make old and new API usage work together in a way that isn't surprising.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This commit adds API for the enchantment, armor, potion and other
modifications to damage done to an entity. These damage modifiers are each
editable editable via a getter and a setter. This addition allows for more
accurate modification and monitoring of damage done to/by an entity, as it
displays the final damage done as well.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On JVMs with UTF-8 default encoding, this commit has no change in behavior.
On JVMs with ascii default encoding (like some minimal linux installa-
tions), this commit now uses UTF-8 for YamlConfiguration operations.
Because all ascii is valid UTF-8, there is no feature degradation or data
loss during the transition.
On JVMs with any non-unicode but ascii-compliant encoding, this commit now
forces YamlConfiguration to escape special characters when writing to
files, effectively rendering the encoding to be plain ascii. Any affected
file will now be able to migrate to UTF-8 in the future without data-loss
or explicit conversion. When reading files, YamlConfiguration will use the
system default encoding to handle any incoming non-utf8 data, with the
expectation that any newly written file is still compliant with the
system's default encoding.
On JVMs with any non-unicode, but ascii-incompliant encoding (this may be
the case for some Eastern character sets on Windows systems), this change
is breaking, but is justified in claim that these systems would otherwise
be unable to read YamlConfiguration for implementation dependent settings
or from plugins themselves. For these systems, all uses of the encoding
will be forced to use UTF-8 in all cases, and is effectively treated as if
it was configured to be UTF-8 by default.
On JVMs with unicode encoding of UTF-16 or UTF-32, the ability to load any
configurations from almost any source prior to this change would have been
unfeasible, if not impossible. As of this change, however, these systems
now behave as expected when writing or reading files. However, when
reading from any plugin jar, UTF-8 will be used, matching a super-majority
of plugin developer base and requirements for the plugin.yml.
Plugin developers may now mark their plugin as UTF-8 compliant, as
documented in the PluginDescriptionFile class. This change will cause the
appropriate APIs in JavaPlugin to ignore any system default encoding,
instead using a Reader with the UTF-8 encoding, effectively rendering the
jar system independent. This does not affect the aformentioned JVM
settings for reading and writing files.
To coincide with these changes, YamlConfiguration methods that utilize a
stream are now deprecated to encourage use of a more strict denotation.
File methods carry system-specific behaviors to prevent unncessary data
loss during the transitional phase, while Reader methods are now provided
that have a very well-defined encoder behavior. For the transition from
InputStream methods to Reader methods, an API has been added to JavaPlugin
to provide a Reader that matches the previous behavior as well as
compliance to the UTF-8 flag in the PluginDescriptionFile.
Addresses BUKKIT-314, BUKKIT-1466, BUKKIT-3377
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Up until now it has not been possible to create a new Inventory using
a custom title and permit any InventoryType available.
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.
|
| |
|
|
|
|
|
|
|
|
| |
Prior to this commit MapFont#getWidth() did not account for the 1px
spacing inserted by CraftMapCanvas#drawText().
This commit adds the consideration of the 1px spacing per character
while taking care to not consider the last character as it will not
have a 1px space behind it. This commit also ensures the method will
not check a 0-length String.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are many effects that were not present in the API prior to
this commit. These effects are being used by the implementation,
but cannot be accessed via plugins.
This commit exposes these effects using the EntityEffects enum,
allowing for plugin authors to make use of these effects. However,
many of the effects require certain conditions to be met before
they will be visible to the client, much like some of the existing
effects.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Some blocks, such as beds, doors, or flowers, are actually composed of
multiple blocks when they are placed. Currently, to detect how many
blocks are actually modified a plugin has to perform various calculations
to determine the directions of relative blocks, many of which are
difficult to perform and can easily return false positives.
This commit adds in a BlockMultiPlaceEvent, which adds in easy support for
accessing all blocks modified by the placement of a block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds three new TargetReasons to EntityTargetEvent to address
missing cases where the event is not currently fired.
The first, TargetReason.TARGET_ATTACKED_NEARBY_ENTITY, is used when a
neutral wolf is attacked, causing all nearby wolves to turn hostile and
attack the first wolf's target.
The second, TargetReason.REINFORCEMENT_TARGET, is used when a zombie summons
reinforcements and the new zombie targets the first zombie's target.
The third, TargetReason.COLLISION, is used when an iron golem collides with
a hostile entity, causing it to begin targeting the entity it collided with.
|
| |
|
|
|
|
| |
Adds BUKKIT-5370, BUKKIT-5378, BUKKIT-5382, BUKKIT-5482. Covers zombie
villagers, ocelot babies, silverfish popping out of blocks, and mobs
spawning with a mount.
|
| |
|
|
|
|
|
|
| |
Previously, when calling the /tp command with coordinates, no TeleportCause
was passed, causing the resulting PlayerTeleportEvent to be called with
TeleportCause.PLUGIN instead of TeleportCause.COMMAND. This commit adds the
missing TeleportCause to ensure that the resulting PlayerTeleportEvent
reports the correct TeleportCause.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
BUKKIT-5442
|
| |
|
|
|
|
| |
This change drops the previous plugin data folder migration based on the
plugin's file name, and adapts the migration to now instead consider
plugins that have spaces in their original name.
|
| | |
|
| |
|
|
|
|
| |
This change makes the lists of loadbefore, softdependency, and dependency
replace the spaces in the names with underscored to reflect the behavior
used with names.
|
| | |
|
| |
|
|
|
|
|
| |
When executing an alias we already call an event for the alias itself. The
extra events are not needed for logging purposes as the alias itself is
logged and the events cause issues for plugins trying to do spam checking
on their own.
|
| |
|
|
|
|
| |
There is no need to print a stacktrace when an alias fails, we do not do
this for normal commands. We also now give error messages when attempting
to register an alias instead of having them just silently not function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a large expansion of the aliases system. Aliases can now take arguments,
reorder their arguments, and only pass certain arguments to certain commands.
New syntax added to the aliases are $1 for optional arguments, $$1 for
required arguments, $1- for optionally using all the arguments from the
specified position onward, and $$1- to do the same thing but require at least
the specified position exist. These exist for numbers 1 through 9. You are
able to pass arguments to one command of a multiple command argument and not
others. You can also use the argument as a prefix and/or suffix. A raw $ can
be represented in the arguments by using \$.
Examples:
aliases:
# Usage: /testobjective score_deaths 1 5
testobjective:
- "testfor @p[$$1=$$3,$$1_min=$$2]"
# Usage: /ban Amaranthus Because reasons
ban:
- ban $$1 $2-
- say Banned $$1
# Usage: /icanhasbukkit
icanhasbukkit:
- version
# Usage: /icanhasplugin HomeBukkit
icanhasplugin:
- version $$1
One change from the previous aliases system is that commands are no longer
passed all arguments implicitly. You must explicitly pass the arguments
you want to pass to the command.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of duplicating code to handle two pools of commands
we can instead just add the fallback commands after all
plugin commands are loaded and achieve the same effect. We
also now always register the direct address of a command
to ensure it is always possible to access it.
In addition, aliases can be determined by whether or not
the command label of the command matches the command address,
thereby rendering the aliases HashSet redundant.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes BUKKIT-5371 and BUKKIT-4285
Prior to this commit, ban reasons were not supported by banning commands.
Additionally, the player(s) affected by the ban-ip command would not have
been removed from the server via a kick.
The Bukkit API lacked support for modifying various attributes associated
with bans, such as the reason and expiration date. This caused various plugins
to use external or other means to store a ban reason, making the built-in
banning system on the server partially useless.
Now the ban commands will accept reasons for the bans as well as kick the
player from the server once banned. That means that if an IP is banned
that all players using that IP will be removed from the server.
The API provided now supports editing the ban reason, creation date,
expiration date and source. The ban list has also been created to
provide this information more easily. Editing the data requires an
implementing plugin to manually save the information with the provided
method in BanEntry or BanList once changes have been made.
The addition of this API has deprecated the use of OfflinePlayer#setBanned()
as it has been replaced by BanList#addBan().
|
| |
|
|
|
|
|
|
|
|
| |
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.
With the additional two SpawnReasons, plugins can identify sources of
creature spawning more easily and accuratly.
|
| | |
|
| | |
|
| | |
|
