Bukkit

In reply to FTChristmas:

 It's not that easily possible to change the max stack size of items. There is some other plugin trying to attempt something like this, but as far as I am aware it is plagued by issues..

v2.10.0 for MC 1.16.1, 1.15.2, 1.14.4

Update for MC 1.16.1:

• Added zombified piglin, piglin, hoglin, zoglin and strider to the by default enabled mob types. If you are updating, you will have to manually add these to your config's 'enabled-living-shops' setting.
• During my quick initial testing I did not encounter any major issues with these new mobs, but there are some oddities you might want to be aware of:
  • We don't support changing the baby property of piglin and zoglin shopkeepers yet. However, we at least ensure that they always spawn as adult.
  • The zombified piglin, hoglin and strider already support changing the baby property.
  • The strider constantly shakes when being spawned outside the nether and randomly spawns with saddle.
• The pig zombie mob type has been removed from the by default enabled mob types. If you are updating to MC 1.16, it will get automatically removed from your config. To prevent your config from losing its comments and formatting during this small migration, consider manually removing this mob type before your update.
• If you are updating to MC 1.16, your pig zombie shopkeepers get automatically converted to zombified pigman shopkeepers.
• Internal: Any internal references to the pig zombie mob type have been removed to prevent any kind of binary problems to arise.
• Sign shops support the new crimson and warped sign variants.
• Internal data format changes: Sign shops of type 'GENERIC' and 'REDWOOD' are migrated to 'OAK' and 'SPRUCE' respectively.
• Note on the removal of item type 'ZOMBIE_PIGMAN_SPAWN_EGG' and its replacement with item type 'ZOMBIFIED_PIGLIN_SPAWN_EGG':
  • If you are updating and your config contains an item of type 'ZOMBIE_PIGMAN_SPAWN_EGG' you will have to manually migrate this item to a 'ZOMBIFIED_PIGLIN_SPAWN_EGG'.
  • Any items stored inside the shopkeepers (eg. for their trades or hire cost items) are automatically migrated.
• Note on Minecraft's new RGB color codes and other new text related features: I have not yet looked into supporting those in the texts and messages of the Shopkeepers plugin.

Other migration notes:

• Removed: We no longer migrate items inside the config from legacy (pre MC 1.13) item types, data values and spawn eggs to corresponding item types in MC 1.13. Instead any unknown item types get migrated to their default now.

Other changes:

• Changed/Improved: We use a combination of our own 'Shopkeepers data version' (which has been bumped to 2) and Minecraft's data version for the data version stored inside the save.yml now. Minecraft's data version is incremented on every Minecraft release (including minor updates) and may indicate that new item migrations have been added. So whenever you update your server, we automatically trigger a full migration of all your shopkeepers data to ensure that your save.yml is always up-to-date.
• Fixed: Some mobs randomly spawn with passengers. We remove these passengers now.
• Fixed: When a mob randomly spawns with a passenger, this would previously interfere with our 'bypass-spawn-blocking' feature and print a warning inside the log about an unexpected entity (the passenger) being spawned.
• Fixed: The random equipment of certain mobs gets properly cleared now. For instance, this resolves the issue of foxes randomly carrying items inside their mouth.
• Fixed: When a Citizens NPC, created without the 'shopkeeper' trait, is deleted, we immediately delete any corresponding shopkeeper now. Previously the corresponding shopkeeper would not get deleted right away, but only during the next plugin startup (when checking whether the corresponding NPC still exists). Any chest used by the shopkeeper would remain locked until then.
• Improved: In order to determine the player who is setting up a shopkeeper via the 'shopkeeper' trait, we previously only took players into account which are adding the trait via the Citizens trait command (NPCTraitCommandAttachEvent). However, players are also able to add traits during NPC creation. We now also react to players creating NPCs (PlayerCreateNPCEvent) and then (heuristically) assume that any directly following trait additions for the same NPC within one tick are caused by this player. This player will then be able to receive feedback messages about the shopkeeper creation.
• Improved: For any trait additions not directly associated with a player, we previously waited 5 ticks before the corresponding shopkeeper got created. One (minor) side effect of the above change is that we react to all trait additions within 1 tick now.
• Added: Added a link inside the config which points to the translations repository.
• Added: Added feedback messages when a player cannot trade with a shop due to trading with own shops being disabled or if the shop's chest is missing.
• Changed: The check for whether the player is able to bypass the restriction of not being able to trade with own shops was previously checking if the player is an operator. Instead we now check if the player has the bypass permission.
• Changed: When checking if the player is able to bypass the restriction of not being able to trade with shops while their owner is online, we only check for the bypass permission now after checking if the shop owner is actually online currently.
• Added: The variant of rabbit shopkeepers can be changed now. Any existing rabbit shopkeepers will use the brown variant (the default). This also resolves an issue with the rabbit type randomly changing whenever the shopkeeper is respawned.
• Added: Added a header comment to the top of the save.yml file mentioning the risk of manually editing this file while the server is still running or without making a backup first.
• Fixed: If regular item usage is disabled we also prevent any kind of entity interaction now while holding the shop creation item in hand. Players in creative mode or with the 'shopkeeper.bypass' permission are exempt from this restriction.
• Fixed: Checking the WorldGuard allow-shop flag now takes into account the player for whom the flag is being queried.
• Fixed: The returned shop creation item would get dropped twice under certain conditions.
• Fixed: The shop creation item is now also returned if a player deletes his own shop via command.
• Fixed/API: The PlayerDeleteShopkeeperEvent is now also called when a player deletes shops via command.
• Changed: The result message after deleting shops via command will now print the number of actually removed shops (which does not necessarily match the number of shops that were confirmed for removal).
• Changed: The item representing the black horse inside the editor is now slightly less black.
• Debug: Added the debug option 'capabilities', which logs additional details when the plugin checks for server version dependent capabilities.
• Debug: Added some more information to the debug message that gets logged when the PlayerDeleteShopkeeperEvent has been cancelled.
• Debug: Minor changes to some debug messages related to Citizens shopkeepers.
• API/Internal: Added Shopkeeper#delete(Player) which optionally passes the player responsible for the shopkeeper deletion. Note that the player is not passed if a player shop is deleted due to a player breaking the shop's chest.
• API: Added a note about the PlayerDeleteShopkeeperEvent not being called in all circumstances.

Internal changes:

• Moved most of the code responsible for returning the shop creation item for deleted player shops into the new PlayerShopkeeper#delete(Player) method.
• Added ShopkeeperEventHelper class and moved the common code for calling and handling PlayerDeleteShopkeeperEvents there.
• Various minor refactorings related to the Text implementation.
• Various minor refactorings related to Citizens shopkeepers.
• Minor formatting changes. Not applied to the whole code base yet.

Added messages:

• msg-button-rabbit-variant
• msg-button-rabbit-variant-lore
• msg-cant-trade-with-own-shop
• msg-cant-trade-with-shop-missing-chest

Changed messages (you will have to manually update those!):

• Renamed 'msg-removed-player-shops' to 'msg-removed-shops-of-player'.
• Renamed 'msg-removed-all-player-shops' to 'msg-removed-player-shops'.
• Renamed 'msg-confirm-remove-admin-shops' to 'msg-confirm-remove-all-admin-shops'.
• Renamed 'msg-confirm-remove-own-shops' to 'msg-confirm-remove-all-own-shops'.
• Renamed 'msg-confirm-remove-player-shops' to 'msg-confirm-remove-all-shops-of-player'.
• The 'msg-removed-player-shops' message (previously 'msg-removed-all-player-shops') no longer mentions that 'all' shops got deleted (since this is not necessarily true).
• Changed the 'msg-button-villager-level' and 'msg-button-villager-level-lore' messages to clarify that this option only changes the visual appearance of the villager's badge color. The included german translation has been updated accordingly as well.
• Slightly changed the german translation of the 'msg-cant-trade-while-owner-online' message.
• Removed the note about left and right clicking items to adjust amounts from the 'msg-trade-setup-desc-admin-regular' message, since this doesn't actually apply to admin shops.

Known potential issues: See here.

Donations

If you like this plugin, consider making a donation.

Thanks!

In reply to mcreunioneu:

 v2.10.0 should be available any moment now and provide support for MC 1.16.1

In reply to Forge_User_35611682:

 There is already a related feature request ticket for this over at Github. Maybe you can elaborate there how you would expect a feature like this to work in detail.

However, Shopkeepers is an item-based trading plugin and there are no plans to change that. If you don't want that you will have to use one of the plenty other available shop plugins that support interfacing with the Vault economy directly.

One idea for partial Vault support could be to provide some type of item that players can easily exchange for vault money. And these items could maybe get instantly converted to vault money whenever they are used in Shopkeeper trades (eg. player buys this special 'cheque' item, and when picking up the item it either instantly disapears and the player received the value in balance. Or the player is able to manually redeem this item in some way afterwards.

However, I think there are already plugins which provide variations of this. You could check out Gringotts and MoneyNote as two well known examples.

In reply to StrangeOne101_:

 Consider posting suggestions over at github so that they don't get lost. Also try to clarify how you would expect this to work and be setup (config, in-game, etc.).

In reply to JunSteed:

 How do you specify these item drops? If you are using minecraft's snbt item data format with text components with formatting sections ("color: ..", "bold: ..", etc.), then this is caused by Spigot not properly serializing/deserializing these items inside Shopkeepers save.yml file. See https://github.com/Shopkeepers/Shopkeepers/issues/578
The workaround is then to either use a plugin to create those items (preferred) or use legacy color codes as shown here: https://github.com/Shopkeepers/Shopkeepers/issues/578#issuecomment-528980231

If this is not the case, and your items names or lore start with black or purple color codes, then this is also caused by an issue of Spigot treating these colors as defaults and therefore omitting them. Updating to the latest version of Spigot might help (there has been a recent commit which is supposed to fix this).

If neither of these apply, then I need to know how you exactly create/specify these item drops. I need step-by-step instructions on how to reproduce this issue on my test server so that I can further investigate.

The plugin (actually Spigot to be precise, because the Shopkeepers plugin uses a piece of Spigot API to store and load the items inside the save.yml file) storing the color codes with '&' instead of '§' is normal and intended. The color codes get converted back to § again when these items are loaded from the save.yml file.

In reply to lucymackin:

 They should automatically turn towards nearby players. Make sure that you are using the latest version of Spigot and are not invisible or similar.

If nothing helps, try to reproduce your issue on a fresh server with default configs.

In reply to christianmaskevich:

 Make sure that you are using both the latest versions of Spigot and the latest version of Shopkeeper

In reply to winchester_hots:

 You select the chest on shop creation. There are plans to allow selecting additional chests afterwards, in order to connect more than one chest to the shop. This probably require a way to unlink a chest again, so this may cover your usecase as well then. But there is no ETA on that yet