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.
By: t00thpick1 <t00thpick1dirko@gmail.com>
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.
By: t00thpick1 <t00thpick1dirko@gmail.com>
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().
By: mbax <matt@phozop.net>
Necessary additions include an interface to add internal value conversions
that are inappropriate for proper API design. This acts as a substitute
for properly formed, user-friendly commands in an effort to maintain
relatively vanilla behavior.
By: Wesley Wolfe <weswolf@aol.com>
This commit adds proper formatting to the closing bracket used when certain
commands send messages to all players with the broadcast-channel
permission.
By: Luke A <stuntguy3000@gmail.com>
Prior to this commit all /say command output would be a generic "[Server]"
prefixed line. This commit changes that by adding the source into the
message, such as a player. By doing this Bukkit more closely matches
vanilla behaviour and gives a more descriptive message to the client.
By: Kezz101 <1millionchances@gmail.com>
In vanilla, gamerules are global, across all worlds. Maps created for
vanilla that use command blocks expect this behavior, which is broken
when they are placed on a world that is not the default world (world #0).
This commit changes that by using the command block's current world when
executing the command, forcing the game rules executed to be executed in
the world the command block is currently in.
By: Kane York <rikingcoding@gmail.com>
TimedRegisteredListener uses a reference to the first event fired. This
causes a memory leak in the server for any references that event has. This
changes TimedRegisteredListener to only store a reference to the class of
the event.
This change is intentionally a breaking change, as it is an obscure part
of the API. A non-breaking change would require the leak to be maintained
or an immediate update for any plugins using the method, as it would be an
indirect break.
A unit test is also included to check behavior of shared superclass
functionality.
By: Score_Under <seejay.11@gmail.com>
When the minimum volume is being used because the distance is over a
threshold, the unit vector delta should be added to the player's
location, instead of where the command specified location.
This change makes the player's location the point of reference for
playing sounds when distance to volume scale is lower than minimum
specified volume.
By: Wesley Wolfe <weswolf@aol.com>
Through a miscalculation, team display names were being created via
command ignoring the first word in the submitted display names.
By: mbax <github@phozop.net>
Two checks to argument length were changed to properly consider if the
sender is a player instead of an off-by-one logical error.
By: Wesley Wolfe <weswolf@aol.com>
The method to make a string from a collection of strings already exists
and should be used when adding multiple players to a team.
By: Wesley Wolfe <weswolf@aol.com>
The implementation is designed around having both a main scoreboard and
numberous plugin managed scoreboards that can be displayed to specific
players.
Plugin managed scoreboards are active so long as a reference is kept by a
plugin, or it has been registered as a player's active scoreboard. Objects
specific to a scoreboard remain active until unregistered (which remove a
reference to the owning scoreboard), but quickly fail if accessed
post-unregistration.
By: mbax <github@phozop.net>
getInteger returns min value on illegal number formats, so we change
behavior to throw an exception when requested.
By: feildmaster <admin@feildmaster.com>
