Started using the new Spigot text feature at a few places:
The give and transfer command show the player's uuid as hover text now and allow it to be copied into the chat input via shift clicking.
List and remove commands follow soon.
Also:
* Fixed: FeaturesChart was missing the CollectionUtils rename.
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.
Other changes:
* Changed a few button messages for consistency.
* Changed the default value for the setting
enable-chest-option-on-player-shop to 'true'.
* Fox: Type, crouching, sleeping state.
* Wolf: Collar color (, angry state isn't working yet)
* Parrot: Color, sitting (, baby variant isn't working for parrots)
Moved common de/serialization code into new Property classes.
* Sheep can now be set sheared.
* Cat collar color can be specified now.
* Villager type (biome) and level can be specified. TODO This currently
requires a fix in Spigot for the SNOW/Y type to work.
* Fixed: Wandering trader doesn't support the baby state.
* Removed the generic 'sub type' editor option in favour of letting each
shop object supply a list of editor options. This allows living
shopkeepers to provide multiple editor options now.
* API: Removed getSubTypeItem, cycleSubType and equipItem from
ShopObject. Editor options are internal API for now, and mob equipment
hasn't properly worked already before due to not getting persisted.
* All ageable mobs can now be turned into baby variants. Previously this
options was only available for zombie and pig zombie shopkeepers. The
editor item for this option is a regular chicken egg now.
* Villagers store their profession under 'profession' now. Previous
values under 'prof' get imported.
* Dropped support for MC 1.13. This version only supports MC 1.14.
* If you are upgrading, make sure that you have successfully updated
shopkeepers to 1.13 first. Migration from older MC are not supported and
might not work. Reverting to older versions isn't supported either.
* Removed pre 1.13 sheep color migration.
* Villager shopkeepers:
* Changed default profession from farmer to 'none'.
* Priest villagers get converted to 'cleric' and blacksmiths become
'armorer'. Previous regular farmer villagers stay farmers (but they look
different now).
* Changed the items representing the villager professions in the
editor.
* Note: Wandering traders are not a villager sub-variant, but a
different mob type.
* Ocelot shopkeepers of cat types have been converted to corresponding
cat shopkeepers. You might have to adapt your players' permissions,
since cat and ocelot shopkeepers require different permissions now. With
this migration players can end up with cat shopkeepers even though they
don't have the permission to freshly create those if they wanted. The
different cat types are represented by colored leather armor inside the
editor.
* Any settings affecting regular villagers will affect wandering traders
as well now. There are no settings (for now?) to handle wandering
traders differently. When preventing regular villagers from spawning,
the trader llamas of the wandering trader are prevented from spawning as
well. When hiring a wandering trader its leashed llama should get
unleashed due to the removal of the wandering trader.
* Added: Sign shops can now switch between different wood types.
TODO:
* This has not yet been tested. Spigot 1.14-pre5 seems to still have
some other issues which prevent me from testing this currently.
* New entities have not yet been tested.
* Support for changing between different villager biome types would be
nice.
Inside the editor, the player picks up items in their inventory and can
then freely place a copy of those items in the top window of the editor
to specify the traded items.
With this it is now also possible to setup multiple trades for the same
result item.
However, the number of trades that can be setup is strictly limited to 8
now. Previously one was able to setup additional trades by moving the
items in the chest around.
UIHandlers can now react to inventory dragging as well. The new trading
shopkeeper setup makes use of this to interpret dragging that only
involves a single slot just like clicking that slot (makes the inventory
interaction more fluent).
* Shop creation via command and via item and via
ShopkeepersPlugin#handleShopkeeperCreation should be more consistent
now.
* Various chest related checks that were previously only run during
chest selection are now run during shopkeeper creation again as well
(and by that also when creating player shopkeepers via command).
* Changed: Shopkeeper creation via command now takes the targeted block
face into account when determining the spawn location. You can now place
shopkeepers on the sides of the targeted chest (previously it would
always place player shopkeepers on top of the chest).
* Changed: Always preventing all regular shop creation item usage, even
when shopkeeper creation fails for some reason, or when selecting shop /
shop object types. One can use the shop creation item regularly (if not
disabled in the config) by using it from the off hand.
* Removed the setting 'simulate-right-click-on-command'. Chest access is
now always checked as part of shopkeeper creation.
* API: ShopkeepersPlugin#handleShopkeeperCreation now takes various
restrictions into account that were previously handled as part of chest
selection or as part of shopkeeper creation preparation. This includes
chest validation, chest access checks, permissions and enabled-state of
shop and shop object types, spawn location validation, and checking for
other shopkeepers at the spawn location.
* API: Removed the separate owner from player shop creation. The creator
gets used as owner now. The creator can no longer be null when creating
shopkeepers via ShopkeepersPlugin#handleShopkeeperCreation.
* API: Added AdminShopType and AdminShopkeeper interfaces. There may be
different types of admin shopkeepers in the future.
* API: ShopCreationData is abstract now. For creating admin shopkeepers
one has to use the new AdminShopCreationData instead.
Added and changed (mostly colors) few messages:
* Added: msg-no-chest-selected
* Added: msg-chest-already-in-use
* Added: msg-no-chest-access
* Added: msg-no-admin-shop-type-selected
* Added: msg-no-player-shop-type-selected
* Changed: msg-selected-chest
* Changed: msg-must-select-chest
* Changed: msg-chest-too-far
* Changed: msg-chest-not-placed
* Changed: msg-too-many-shops
* Changed: msg-shop-create-fail
* Removed reference to old Cube-Nation repository.
* Added a separate parent pom and renamed the old parent to 'sk-root'.
Only sk-main uses sk-root as parent now. The api project therefore
relies only on a minimal set of dependencies now.
* Shopkeepers and ShopkeepersAPI get installed and deployed with a
flattened pom now. This should allow depending on those without having
to also deploy the various versions of the parent poms or child modules.
* The different child modules that get bundled and deployed as part of
the final plugin jar use the 'provided' scope now, in order to not be
transitive for projects depending on Shopkeepers internals.
* Added a separate nms-parent pom, to further reduce duplicate contents
in the nms handler child modules.
Overview over (unrelated) changes performed during the rewrite, which
ended up in the same commit now:
* Fix: All inventory operations are now limited to storage contents.
This might fix issues with hiring cost items being removed from armor or
extra slots.
* Improvement: Normal player shops are now slightly smarter when
figuring out whether the chest has enough space for the traded currency
items, by allowing a variable ratio between high and low currency items.
* Internal/Fix: All general inventory operations now work on content
arrays (inventory snapshots) instead of the inventories directly. (This
might even fix a few severe issues, which were unnoticed so far..)
* Internal: Minor javadoc improvements.
* Internal: Removed a few redundant final modifiers.
* Internal: Added Settings#isHighCurrencyEnabled() and using that now
everywhere.
* Internal: Settings#isHighCurrencyItem() now returns false if high
currency isn't enabled.
* Internal: Minor refactoring related to setting up the editor window
and handling of editor clicks.
* Internal: Updated the TODO list and added a few more ideas.
* Internal/Improvement: Buying shopkeepers are now slightly smarter when
removing currency items from the chest: It prioritizes low currency
items over high currency items, partial stacks over full stacks, and is
able to split more than one large currency item and return the excess
change to the chest (previously it only converted at most 1 high
currency item). This should help keeping the chest more compact.
* Internal: Added a debug message for every trade processed by
Shopkeepers.
* Fix: The purchase log was missing the header row since a previous
commit (35bbfc0bc0). (Also forgot to
mention on that previous commit: The logged data now contains the
players uuid as well, in parentheses inside the 'PLAYER' column.)
* Improvement: The collect-to-cursor inventory action is now allowed
inside the trading window, as long as the result slot doesn't match the
item on the cursor.
Major rewrite of the processing of trades:
Shopkeepers is now implementing the inventory actions that might trigger
trades itself.
Previously, trading with player shopkeepers only allowed simple left
clicks of the result slot. We predicted the trading outcome (rather
simple when only allowing left clicking..) and then let minecraft handle
the click like normal. Any other inventory actions (ex. shift-clicks)
were prevented, because so far we weren't able to predict the outcome of
those.
I finally took the time to dive into minecraft's and craftbukkit's
internals to figure out, how it processes the various clicking types and
resulting inventory actions, how those can trigger trades, and how
minecraft processes those trades.
Supporting more advanced inventory actions for trading requires at
minimum being able to reliably predict the outcome of those inventory
actions, and by that already requires re-implementing of large parts of
the vanilla logic (which is one of the reasons why this wasn't done so
far). The step to also apply those predicted inventory changes ourselves
then isn't that much of an additional effort on top, but has a few
advantages:
For one, we can be quite sure that the predicted outcome of a trade
actually matches what gets applied in the end. This should reduce the
risk of inconsistencies between minecraft's behaviour and our
predictions resulting in bugs (also with future minecraft updates in
mind).
Secondly, when relying on minecraft's implementation we are only able to
allow or cancel the inventory action as a whole. The shift-clicking
inventory action however is able to trigger multiple trades in a row
(possibly even for different trades). By implementing this ourselves, we
are able to apply as many trades as are possible with regards to
available stock and chest capacity.
Implementing the trading ourselves has a few advantages, but also comes
with caveats:
Caveats:
* Increased maintenance and testing effort.
* Increased possibility for inconsistencies between vanilla
inventory/trading behaviour and our own implementation.
* Minecraft performs some map initialization when certain map items are
created by crafting or via trades: This seems to be responsible for
updating the scaling (after crafting a larger map) and enabling tracking
(this doesn't seem to be used anywhere inside minecraft though). Since
this is only the case if the map item has some special internal nbt data
(which shouldn't be obtainable in vanilla minecraft), we currently
simply ignore this inside Shopkeepers.
Neutral:
* The usage count of the used trading recipes doesn't get increased
anymore. But since these are only temporarily existing and aren't used
for anything so far, this shouldn't be an issue.
* The player's item crafting statistic doesn't get increased anymore for
traded items.
* The player's traded-with-villager statistic doesn't get increased
anymore for shopkeeper trades.
I could manually replicate some of these, but since these are custom
trades anyways I don't see the need for it right now. But if there is a
justified interest in this, let me know and I might add a config option
for it.
Advantages:
* Support for more advanced inventory actions when trading with
shopkeepers:
* Currently supported are: Shift-clicking, and moving traded items to a
hotbar slot.
* Not (yet) supported are:
* Dropping the traded item: Exactly reproducing the vanilla behaviour
for dropping the traded item is actually rather tricky / impossible with
pure bukkit API so far.
* Trading by double-clicking an item in the player inventory: The
behaviour of this inventory action is rather arbitrary in vanilla
already (trades zero, one, or two times depending on the other items in
the inventory), and it is affected by a bug
(https://bugs.mojang.com/browse/MC-129515)
* Simpler API: A single ShopkeeperTradeEvent is called for each trade
(might be multiple per click depending on the used inventory action, ex.
shift-clicking). The ShopkeeperTradeCompletedEvent was removed. (API
breakage, sorry.)
* Fixed: The logging of purchases should now actually be accurate for
shift-clicks. It logs each trade individually.
* Eventually this might allow for more options for customization of the
trading behaviour in the future.
Potential issues (that have existed before already):
* If minecraft adds new inventory actions, those are initially not
supported by shopkeepers: If those inventory actions involve clicking on
the result slot, they will simply be prevented. If they however allow
players to trigger trades by clicking on items inside the player's
inventory (similar to the existing collect-to-cursor action by
double-clicking), they might introduce bugs which players might be able
to exploit.
Other changes as consequence of the trade-handling changes:
* Internal: Added a version-dependent function which matches items in
the same way as minecraft does it: Minecraft allows the offered items to
contain additional metadata and still accept them for the trade.
* Internal/Fix: Minor refactoring during updating to the new trade
handling. This might even fix a few small potential bugs/inconsistencies
related to handling of high-currency items.
* Internal: Due to the changes regarding the handling of trades, the
trading count listener (added in a previous commit) is now solely used
to detect trades with non-shopkeeper merchants (ex. vanilla villagers).
This can be useful when comparing vanilla trading behaviour with
shopkeeper's new trading behaviour.
* The ShopkeeperTradeEvent now directly provides access to the items
offered by the player and the order in which they were matched to the
used trading recipe.
blablubbabc