Moved some of the logic for determining which exception to use when handling fallbacks into Command and FallbackArgument itself. For the most part the behavior there is as before, but if a fallback failes due to missing an argument or requiring a player, the parsing exception of the original (root) argument is preferred. If the parsing context has changed (ag. if some of the following command arguments were able to parse something), the original argument may get reevaluated to determine the new error.
Other command related changes:
* Clarified CommandArgument#isOptional javadoc.
* Added some notes and TODO entries on remaining issues with ambiguities.
* Renamed FallbackArgumentException#getArgument to #getFallbackArgument.
* Added FallbackArgument#getOriginalArgument.
* Added MissingArgumentException and InvalidArgumentException (which ArgumentRejectedException extends) which allows specifically handling those types of exceptions.
* Renamed CommandArgument#missingArgument and #invalidArgument to #missingArgumentError and #invalidArgumentError.
* Added CommandArgument#requiresPlayerError, RequiresPlayerArgumentException and a corresponding default message (msg-command-argument-requires-player) for arguments that require a player as executor.
* PostponedArgumentParseException wraps another exception now which gets thrown by the command in place of the postponed exception itself. This allows providing context about the type of the postponed exception.
* Added PostponedArgumentParseException#getRootException.
* Using an Optional to indicate whether an argument's parent has already been set vs whether it has no parent.
* Making sure that the command argument parent isn't set to the argument itself.
* Fixed parent validation in Command#addArgument.
* Added: Validating that no arguments with the same name are added to the same command.
Other changes:
* Added Utils#concat() for arrays.
This is useful when there is a chain of wrapped arguments and the parent
needs to handle the value parsed by the child argument in some way.
Fixed: Chains of FirstOfArguments should now be able to properly store all the values parsed by child arguments along the chain. Previously this only worked for a chain depth of 1.
This can be used to change the display name of an command argument (used
in the command format). This may for example be useful in the presence
of multiple, otherwise conflicting literal arguments.
Bukkit is outdated and missing some features.
The API package still uses the bundled one (for now) to avoid moving
implementation utils into the API.
Also added a few more functions to StringUtils.
inventories (for hoppers, droppers, etc.)
This is mainly achieved by avoiding creating the inventory holder (block
snapshot) of the involved inventories, and also by avoiding duplicate
protection checks for double chests.
(default: true).
This can be used to disable the registration of the 'allow-shop'
WorldGuard flag. Usually this should not be required though. Note that
changing this setting has no effect until the next server restart or
full server reload.
This replaces the just previously added system property
'shopkeepers.skip-wg-allow-shop-flag' again.
be used to disable the registration of the 'allow-shop' WorldGuard flag.
This should usually not be required though.
Also moved some initialization and config loading into the onLoad phase,
so that it is available for any code running there.
Internally this new format uses Bukkit's item serialization for parsing
the item data, which allows it to support the specification of arbitrary
item data and hopefully not require any major updating/maintenance for
future minecraft versions. At the same time it tries to stay (slightly)
more user-friendly than Bukkit's item serialization by omitting any data
that can be restored by the plugin, by avoiding one level of nesting
between the item type and item data, by translating ampersand ('&')
color codes in display name and lore, and by offering a compact
representation for specifying an item only by its type.
This change also allows a more detailed specification of some of the
editor button items. However, many editor buttons still miss
corresponding config settings. Also keep in mind that the display name
and lore for these button items get specified via corresponding message
settings, so any specified item display name and lore will get replaced
by that.
When checking if an in-game item matches the item data specified in the
config, only the specified data gets compared. So this does not check
for item data equality, but instead the checked item is able to contain
additional data but still get matched (like before, but previously this
was limited to checking display name and lore).
The previous item data gets automatically migrated to the new format
(config version 2).
Other changes:
* Internal: Moved config migrations into a separate package.
* Internal: Moved some function(s) into ConfigUtils.
* Internal: Slightly changed how the plugin checks whether the high
currency is enabled.
* Internal: Avoiding ItemStack#hasItemMeta calls before getting an
item's ItemMeta, since this might be heavier than simply getting the
ItemMeta directly and performing only the relevant checks on that.
Internally ItemStack#hasItemMeta checks emptiness for all item
attributes and might (for CraftItemStacks) even first copy all the
item's data into a new ItemMeta object. And even if the item actually
has no data (Bukkit ItemStack with null ItemMeta), ItemStack#getItemMeta
will simply create a new empty ItemMeta object without having to copy
any data, so this is still a similarly lightweight operation anyways.
* Internal: Added ItemData tests. Unfortunately this requires
CraftBukkit as test dependency.
the API. They allow modifying the shopkeepers' trades. Factory methods
for the different types of offers are provided via ShopkeepersPlugin and
ShopkeepersAPI.
* The internal shopkeeper classes got renamed.
* API: Added a few utility methods to TradingRecipe for comparing the
recipes with given items or other recipes.
* API: Added toString, hashCode and equals to TradingRecipe and the new
offer types.
* Minor javadoc changes.
* Fixed: ShopkeepersAPI was missing getDefaultUITypes.
ShopkeepersAPI.
Adjusted Eclipse classpath to make tests work. There seems to be
something off with the maven setup for the individual child modules
though.
controls whether opening the trading menu and trading with shopkeepers
increment minecraft's 'talked-to-villager' and 'traded-with-villager'
statistics.
Previously the talked-to-villager statistics would always get
incremented and the traded-with-villager statistic was not used.
The setting gets also tracked by bStats.
blablubbabc
blablubbabc