v2.19.0

Details

  • Filename
    Shopkeepers-2.19.0.jar
  • Uploaded by
  • Uploaded
    Dec 25, 2023
  • Size
    1.93 MB
  • Downloads
    71,033
  • MD5
    9e01112391efb2e5e412db21c5a092ce

Supported Bukkit Versions

  • 1.20.2
  • 1.20.1
  • 1.19.4
  • 1.19.3
  • 1.19.2
  • 1.19
  • 1.18.2
  • 1.17
  • 1.16

Changelog

v2.19.0 for MC 1.20.4, 1.20.2, 1.20.1, 1.19.4, 1.19.3, 1.19.2, 1.19, 1.18.2, 1.17.1, 1.16.5

I only list the primary changes here. For information on API changes, internal changes, and changes to the language files, you can find the complete changelog on Github: https://github.com/Shopkeepers/Shopkeepers/blob/master/CHANGELOG.md 

  • Add support for MC 1.20.4. MC 1.20.3, which is mostly the same, is not officially supported. No new features or mobs. Experimental MC 1.21 mobs are not yet supported.
  • Add setting `citizen-npc-fluid-pushable` (default: `false`) to make all shopkeeper Citizens NPCs pushable by fluids (`true`), unpushable by fluids (`false`), or not modify their current behavior (`"undefined"`).
    • When set to `"undefined"`, the Citizens NPCs are not modified but retain their default or previously set fluid pushable behavior.
    • Unfortunately, the Citizens plugin has no in-game command yet to toggle the fluid pushable state of individual NPCs. But this is likely to be added in the future.
  • Shulker shopkeepers peek at nearby players now.
    • This behavior can be disabled with the setting `shulker-peek-if-player-nearby` (default: `true`).
    • The setting `shulker-peek-height` (default `0.3`) defines how much the shulker opens when it peeks.
  • Add: Support for setting up items that execute a command when being traded (either sold or bought).
    • Add: Command `/shopkeeper setTradedCommand <command>` (permission `shopkeeper.settradedcommand`, default `op`): Sets the command to execute when the held item is traded.
    • The command to execute is stored inside the item's data under the Bukkit key `shopkeepers:traded_command`.
    • When an item that has a traded command assigned is traded, the item is destroyed and the assigned command is executed as often as there are items in the item stack.
    • This feature is not meant to replace the requirement for custom third-party plugins or scripts in order to implement complex or custom behaviors. In order to reduce implementation and maintenance effort, only a single command can be assigned to an item and only a very limited set of placeholders is supported: `{player_name}`, `{player_uuid}`, `{player_displayname}`, `{shop_uuid}`.
      • Simple command sequences can also be defined via command aliases in Bukkit's "commands.yml" (see https://bukkit.fandom.com/wiki/Commands.yml).
      • If additional context information is required, e.g. about the shopkeeper's location or shop owner, a custom plugin that listens for the `ShopkeeperTradeEvent` might be better suited to implement the intended behavior.
  • Add: Utility command "/shopkeeper replaceAllWithVanillaVillagers".
    • This command deletes all shopkeepers and replaces them with corresponding vanilla villagers without AI that are configured very similar to villager shopkeepers.
    • This might for example be useful when migrating a world to vanilla Minecraft, e.g. when a server closes a world but wants to provide it as download to its players with all the shopkeepers included.
    • This command requires all of the following permissions: `shopkeeper.debug`, `shopkeeper.remove-all.player`, `shopkeeper.remove-all.admin`.
  • Add: "No shops were found" message to the "removeAll" command.
  • Fix: Moving shopkeepers did not update their location in the AI system, breaking gravity and AI activations when being moved out of their original chunk.
  • Fix: Verify that the Citizens API is still available before we try to use it. This guards against cases in which the Citizens plugin reports as "enabled", but the Citizens API is not in a properly initialized state. Reloading the Citizens plugin via PlugMan also seems to leave the Citizens API in an unusable state.
  • Fix: The check whether the cursor can hold the traded item was off by one, unnecessarily preventing trades in some cases.
  • Fix: Shopkeepers could no longer be moved after a recent change in the Paper server (PR 9937) to now also call the EntityTeleportEvent for plugin invoked teleports: All plugins that previously cancelled or modified entity teleports in certain cases (including the Shopkeepers plugin itself) can now accidentally cancel or modify plugin invoked entity teleports that were not supposed to be cancelled or modified previously. For now, we restore the previous behavior for all of our plugin triggered shopkeeper entity teleports by forcing these teleports, bypassing any cancellation and modification attempts of plugins.
  • API (breaking): Changes to the `ShopkeeperTradeEvent`.
    • The result item received by the trading player and the items received by the shopkeeper can now be altered via the `ShopkeeperTradeEvent` (`#get/setReceivedItem1/2`, `#get/setResultItem`).
      • Breaking: Plugins that use this event can no longer assume that the received items equal those of the trading recipe.
      • It is also possible to clear the received items. This might for example be useful when implementing items that apply alternative effects when traded (e.g. command items, or Vault integration).
      • Trade logging and trade notifications still log the original items of the trading recipe.
      • Some shopkeepers ignore changes to the received items in certain cases. For example, when removing items from a shop container or when adding or removing currency items to or from shop containers, the default shopkeepers will ignore any changes to the received items.
    • Since the received items can now be modified by plugins during the trade event, the event is called earlier now, prior to certain inventory related checks.
      • Breaking: Plugins can no longer assume that the trade will actually take place even if the trade event remains uncancelled.
    • Add a non-cancellable `ShopkeeperTradeCompletedEvent` that is called if the trade actually took place, after all trade effects have been applied.
    • Add `ShopkeeperTradeEvent#getTradeEffects` that allows custom `TradeEffect` instances to be added that are invoked when the trade is either aborted or completed.
      • This can be useful when implementing custom trade effects that are meant to only be executed once the trade is actually applied.
      • This might also be used for some of the built-in default trade effects in the future.

Known potential issues: See here.

Donations

If you like this plugin, consider making a donation.

Thanks!