Bukkit

v2.13.0 for MC 1.17, 1.16.5, 1.15.2, 1.14.4

This update is rather large. I therefore only summarize the most important changes here. You can find the complete changelog in the Github repository: https://github.com/Shopkeepers/Shopkeepers/blob/master/CHANGELOG.md

This update has not yet been tested much on MC 1.17, which itself is probably not yet stable. Also, some of the other changes of this update bear the risk to introduce new bugs. This is why this version is initially marked as 'alpha'. I will promote this version to 'release' as soon as more time has gone by and no major issues have been identified. If you are upgrading to this version, be sure to create a backup of your server and shopkeepers data!

Update for MC 1.17:

• Added axolotls, glow squids, and goats to the by default enabled mob types. If you are upgrading, you will have to manually enable these new mob types.
• Added new editor features that are only available when using MC 1.17:
• Changing the axolotl variant.
• Toggling between a glowing and a dark glow squid.
• Toggling between a normal and a screaming goat. This editor option is only available if 'silence-living-shop-entities' is disabled.
• Toggle glowing text for sign shops.
• Known issues related to MC 1.17:
• Squids and glow squids can be pushed around. This issue might already have existed for some time. See https://bugs.mojang.com/browse/MC-89883
• The loading of entities is deferred from chunk loading in Minecraft now. I am not yet sure if this severely impacts the Shopkeepers plugin, but it certainly partially breaks the 'block-villager-spawns' and 'block-wandering-trader-spawns' settings currently. It is not yet clear how Spigot will update to account for this in order to retain backwards compatibility for plugins.

Migration notes:

• The folder structure has changed:
• The save file is stored inside a new 'data' folder now. If no save file exists at the new location and a previous save file is found at the old location, it is automatically moved.
• Language files are located inside a new 'lang' folder now. Existing custom language files need to be manually moved!
• Trading logs (if enabled) are stored inside the folder 'trade-logs' now. Existing logs are not automatically moved to the new location!
• Removed the 1.16 'PIG_ZOMBIE' migration. We no longer automatically remove this mob type from the config, but only log a warning and then ignore it.
• Removed the migration from Citizens shopkeeper NPC ids to NPC unique ids (originally added in v2.4.0).
• The setting 'enable-spawn-verifier' is no longer used and is automatically removed from existing configs during the update.
• The data format of the CSV trade logs has changed. If you automatically process these CSV trade logs, you may have to update your programs to account for the new format.
• The permissions for the shopkeeper remove (all) command have been renamed. You may have to update your permissions setup.
• 'shopkeeper.remove.own' -> 'shopkeeper.remove-all.own'
• 'shopkeeper.remove.others' -> 'shopkeeper.remove-all.others'
• 'shopkeeper.remove.all' -> 'shopkeeper.remove-all.player'
• 'shopkeeper.remove.admin' -> 'shopkeeper.remove-all.admin'

Language file changes:

• The default messages are no longer stored inside the config. Instead, we always generate an 'en-default' language file. This file acts as a template for custom language files. It is not meant to be modified and is replaced with an up-to-date version on every plugin startup. Message keys no longer start with the 'msg' prefix.
• Config: Changed the default language from 'en' to 'en-default'. Existing configurations are automatically migrated.
• Some texts that were previously settings in the config are now regular messages, such as the inventory titles, nameplate prefix, and sign shop lines. The appearance of sign shops has slightly changed.
• Added warnings when the language file is missing messages or contains unexpected messages.
• Fixed: Color codes for default messages were not getting replaced. This has an effect when some messages of the specified language file cannot be loaded.
• When splitting messages into multiple lines, we take all Unicode line break characters into account now.
• Fixed: The default german translation was missing some translations.
• Several messages were changed, renamed, removed, or added. See the complete changelog for details. You will have to manually update your custom language files to adapt to these changes.

New feature: Placeholder items for player shops.

• When players set up the trades of their shopkeepers, they can now use renamed nametag items as substitutes for items that they don't have. The nametag's display name has to match the name of the substituted item type. Display names that don't match any english item type name won't work. Other properties of the substituted item cannot be specified.
• The parsing is lenient to some extent: The Minecraft namespace prefix ('minecraft:') is optional (some item type names are even too long to be used in anvils if the prefix is included). The upper and lower case of characters is not important. Leading and trailing whitespace is ignored. Spaces and dashes are converted to underscores. Any color codes are also ignored.
• Placeholder items are immediately converted to their substituted item inside the shopkeeper editor. If what appears to be a placeholder item is not converted, its display name probably does not match a known item type. It is not possible to setup player shopkeeper trades that buy or sell the placeholder items themselves. But normal nametags, and nametags whose names do not match any valid item type, are treated like normal items and can be traded as usual.
• Placeholder items are supported by the selling, buying, and trading player shopkeeper. The admin shopkeeper treats them like normal items.
• Placeholder items can not only be used for items that are bought, but also for items that are sold. This allows players to setup trades before they have the items required to fulfill these trades.
• It is also possible to specify basic enchanted books via placeholder items:
• The used naming format is '<enchantment> <level>'.
• The parsing is similar to that of item type names: The normalized display name has to match the id of the intended enchantment.
• Aliases have been defined for some of the enchantments, so that for example 'curse of binding' is correctly mapped to the enchantment with id 'binding_curse'.
• Only a single enchantment can be specified.
• The level can be freely specified, even outside the range of enchantment levels that can usually be obtained in vanilla Minecraft. Levels outside the range of shorts are truncated to the nearest valid short number. If no level is specified, or if the level cannot be parsed, the enchantment's minimum level is used (usually 1).
• Up to level ten, the level can also be specified via roman numerals ('I' to 'X'). It is also possible to specify the levels 'min' or 'max', which results in the normal minimum or maximum level of the specified enchantment to be used.
• It is also possible to specify basic potions, splash potions, lingering potions, and tipped arrows via placeholder items:
  • Potion: '[long] [strong] [potion] [of] [long] [strong] <potion type> [2|ii] [potion] [2|ii]'
  • Splash potion: '[long] [strong] <splash> [potion] [of] [long] [strong] <potion type> [2|ii] <splash> [potion] [2|ii]'
  • Lingering potion: '[long] [strong] <lingering> [potion] [of] [long] [strong] <potion type> [2|ii] <lingering> [potion] [2|ii]'
  • Tipped arrow: '[long] [strong] [tipped] [potion] <arrow> [of] [long] [strong] <potion type> [2|ii] [tipped] [potion] <arrow> [2|ii]'
• The used naming formats are:
• The parsing of the potion type is similar to that of enchantments: The normalized 'potion type' has to match the id of the intended potion type. These potion types cover the potions that are found inside the creative inventory. Custom potion items with arbitrary effects and properties are not supported.
• The keywords 'splash', 'lingering', and 'arrow' are used to identify the different item types. If none of these keywords is found, a normal potion item is assumed.
• The keywords 'long', 'strong', '2', and 'ii' specify long or strong variants of the specified type of potion. There are currently no potion variants that are both long and strong at the same time. Consequently, only one of these keywords is allowed to be used at the same time. However, we currently ignore any additional occurrences of the respectively other keywords. If the specified potion type does not support the selected variant, the keyword is currently ignored as well. But this might change and potentially become more strict in a future release.
• Each keyword can occur at most once, but there may be multiple valid locations at which it can occur (which is why the above formats mention some keywords multiple times). However, for simplicity, the parsing does not actually take the order or dependencies of words into account currently, but only checks for the presence of the various keywords. But this might change and potentially become more strict in a future release. Any other words in the above formats that were not mentioned as keywords are optional.

New feature: Trade notifications.

• Config: Added settings 'notify-players-about-trades' (default: disabled) and 'notify-shop-owners-about-trades' (default: enabled), which enable trade notifications for all players with certain permissions, or for shop owners about trades that take place in their own shops.
• Permissions: Added permissions 'shopkeeper.trade-notifications.admin' and 'shopkeeper.trade-notifications.player' (both default to false). If trade notifications are enabled (setting 'notify-players-about-trades'), players with these permissions will receive trade notifications for all admin or all player shops respectively.
• There are different sets of trade notification messages for different trade variations and contexts. The default messages do not make use of all of these variations, but this should provide a lot of flexibility when adjusting the messages.
• In order to avoid notification spam, the notifications for equal trades that take place in quick succession are merged into a single notification. However, this does not completely prevent players from potentially causing spam by trading. If this is a concern to you, you may have to disable the trade notifications for now, until more sophisticated countermeasures are available to guard against this kind of spam.
• A new editor option allows shop owners to disable trade notifications for individual shopkeepers. This only affects the trade notifications that are sent to the shop owner, not the general trade notifications that are sent to players with the respective permission.
• Added command "/shopkeeper notify trades", which allows players to disable trade notifications. This command requires the new permission 'shopkeeper.notify.trades' (default: true).
• Since we do not keep track of any user data yet, the trade notifications are only disabled for the current game session (until the player reconnects).
• The first trade notification received during the current game session notifies the player that they can disable trade notifications via this command. This hint message is clickable and will automatically insert the command to execute into the player's chat box. This hint is only sent to players that have the permission to use the command.
• Config: Added settings 'trade-notification-sound' (disabled by default) and 'shop-owner-trade-notification-sound'. These sound effects are played whenever a player (or shop owner) receives a trade notification. They can be disabled by setting them to an empty String inside the config.

Improvements related to the saving and loading of shopkeepers:

• Fixed: Improved the error checking for both the serialization and the writing of shopkeeper data. This should also resolve an issue with the save data being lost when the disk is full.
• We provide more detailed error and debug messages now when a save fails. For example, we provide better error messages if failures are caused by missing directory access permissions.
• Replaced the old Java IO based implementation of saving and loading shopkeeper data with a new NIO based implementation. This should also contribute to more accurate error messages in case of failures.
• Fixed/Debug: The logged number of shopkeepers that have been deleted since the last successful save might not have matched the actual number of deleted shopkeepers. This number did not take into account any shopkeepers that could not be deleted during previously failed save attempts.
• Fixed: We explicitly wait for the new shopkeeper data to be written to disk now before we replace the old save data. This should provide additional protection against data loss and corruption in cases of severe system failures, such as crashes, power losses, etc.
• We log a warning now if we are not able to atomically replace the old and new save data. There are several non-atomic fallback solutions for the case that the save file cannot be atomically renamed. However, these may result in data loss or corruption in case of severe system failures (hence the warning).
• During plugin shutdown, we explicitly verify now that there really is no unsaved shopkeeper data, and that there are no saves pending or still in progress. Otherwise, we log a warning. This warning may for example be encountered if the final save during plugin shutdown fails.
• Fixed: When a save fails, we also trigger a delayed save now even if there are no dirty shopkeepers. This is for example required if there has been an explicit save request, or if shopkeepers have been deleted. These changes would not be reliably persisted before.
• When a save fails, we no longer serialize the data of the affected shopkeepers again during the subsequent save attempts if this data is still up-to-date.
• The name of the temporary save file was slightly changed (`save.temp` -> `save.yml.tmp`).
• We log a warning now whenever a shopkeeper is loaded or created that uses a shop type or shop object type that is disabled. We still load the shopkeeper, so that in the case of a player shop the container is still protected. But we no longer attempt to spawn the shopkeeper. Even though these shopkeepers might in some cases still seem to work as normal, there is no guarantee for this. Admins are advised to either delete these shopkeepers, or change their shop (object) types to something else.

Changes to the CSV trade logging:

• The CSV data format has changed. If you automatically process the CSV trade logs, you may have to update your programs to account for the new format.
• Config: Renamed 'enable-purchase-logging' to 'log-trades-to-csv'. The previous config is automatically migrated.
• Config: Added setting 'log-item-metadata' (disabled by default). This enables the logging of item metadata.
• In order to represent the logged trades more compactly, we merge equivalent trades that are triggered in quick succession over a certain period of time. By default, we merge successive equal trades for up to 15 seconds, but only if there is no gap larger than 5 seconds between the individual trades. The new settings 'trade-log-merge-duration-ticks' and 'trade-log-next-merge-timeout-ticks' control these parameters. They also allow the trade merging to be disabled.
• Performance: The logging is performed asynchronously now, and in batches. When a trade takes place, we wait 30 seconds before we log the trade and any other trades that may have taken place during this duration.
• Debug: Improved the error handling and debug output related to the CSV trade logging.

Several performance improvements:

• Various performance improvements related to sign shops and the processing of physics events.
• For load balancing purposes, the activities of shopkeepers are distributed over multiple Minecraft ticks now. However, processing the shopkeepers every tick, even if only a portion of them needs to do any actual work, also comes with a certain overhead. We therefore do not distribute their activities over all Minecraft ticks, but instead process them in groups only every 5 ticks.
• Performance improvements related to the shopkeeper mob AI:
• Config: Added the setting 'mob-behavior-tick-period' with a default value of 3.
  • This controls the rate at which we update the gravity and AI of shopkeeper mobs. Previously, these behaviors were updated every tick, as it is also the case in vanilla Minecraft. Values above 1 indicate a reduced tick rate, which result in a less smooth, less reactive, and possibly slower behavior in comparison to the behavior of mobs in vanilla Minecraft.
  • In order to compensate for a reduced tick rate, some activities are scaled accordingly. This ensures, for example, that mobs still rotate their head at the same speed towards nearby players, or that mobs still fall at the same speed when being affected by gravity. Consequently, a reduced tick rate is less performance-intensive in total, but may be slightly more performance-intensive per individual behavior update.
  • In my testing, the value 3 offered a large overall performance benefit with a relatively small additional performance impact per individual behavior update, while still providing an acceptable smooth mob behavior. Values above 3 are clearly noticeable and offer little additional benefit.
• Reduced the rate at which the shopkeeper mob AI activations are updated for online players from once every 20 ticks to once every 30 ticks. This seems to be sufficient to still fluently activate nearby shopkeeper mobs even for players that fly around in creative mode. We also immediately activate the shopkeeper mob AI in nearby chunks now whenever a player joins the server or teleports.
• Shopkeeper mobs no longer tick Minecraft's float behavior. This has no effect since they use the NoAI flag.
• The shopkeeper mob AI task is no longer dynamically started and stopped, but instead keeps running even if there are no entities to process currently. Frequently stopping and restarting the task is itself associated with a certain overhead. And even if there are shopkeeper mobs, we can now very cheaply skip their processing altogether when we know that there are currently no chunks with neither active AI nor gravity.
• Various other small optimizations to how the shopkeeper AI task checks if a mob is still valid, and how it stores, queries, and processes chunk and entity data.
• On some Paper versions, maybe due to their async chunk loading, the player's current chunk may sometimes not be loaded yet. We now avoid accessing (and thereby loading) the chunk when activating the AI and gravity behavior of nearby shopkeeper entities.
• Increased the chunk activation delay on chunk loads from 2 to 20 ticks. This further limits the rate at which shopkeepers may get spawned and despawned, for instance, when players frequently cross chunk boundaries back and forth. When a player joins the server or teleports, we immediately activate the chunks in a 2 chunk radius.
• Added a spawn queue for shopkeepers spawned on chunk loads.
• Spawning lots of shopkeepers at the same time can be quite costly performance-wise. This queue distributes the spawning of shopkeepers over multiple ticks to avoid performance drops.
• We spawn at most 6 shopkeepers every 3 ticks (roughly 40 shopkeepers per second): These numbers are a balance between keeping the number of shopkeepers spawned per cycle low, while avoiding the general performance overhead associated with higher spawn rates.
• In order to avoid players having to wait for shopkeepers to spawn, there are some situations in which we spawn the shopkeepers immediately instead of adding them to the queue. This includes: When a shopkeeper is newly created, when a shopkeeper is loaded (i.e. on plugin reloads), and after world saves. In the latter two cases, a potentially large number of shopkeepers is expected to be spawned at the same time. Due to its limited throughput, the queue would not be able to deal with this sudden peak appropriately. However, since these are situations that are associated with a certain performance impact anyways, we prefer to spawn all the affected shopkeepers immediately, instead of causing confusion among players by having them wait for the shopkeepers to respawn.
• The check for whether the shopkeeper mob moved and needs to be teleported back reuses the previous spawn location now. Previously, this would freshly calculate the spawn location each time, which also involves a ray trace to find the exact location for the mob to stand on.
• This change also ensures that shopkeeper mobs no longer start to fall if gravity is disabled and the block below them is broken. However, to account for shopkeepers that have previously been placed above passable or non-full blocks, which might have been broken since then, we still spawn shopkeeper mobs up to one block below their location even if gravity is disabled (e.g. when the chunk or the plugin are reloaded).
• Another side effect of this change is that if gravity is disabled, it is no longer as easily possible to force the shopkeeper mob to move back to its original location after the block it was previously standing on is broken. The shopkeeper will only check for a new spawn location now when it is being respawned. If the mob is supposed to dynamically move when the block below it is broken, gravity needs to be enabled.
• This reuse of the spawn location is limited to the movement check itself. If this detects that the shopkeeper actually moved and needs to be teleported back, a new spawn location is calculated as before. So if the shopkeeper previously spawned slightly below its actual spawn location (due to there missing some block), and gravity is enabled, players are still able to reset the shopkeeper's location by letting it fall due to gravity and then placing a block below its actual spawn location for the shopkeeper to stand on.
• There have been various internal changes that allow us to avoid copying and comparing item stacks in many situations.
• Improvements related to checking and deleting shopkeepers of inactive players.
• Various other minor internal improvements.

And many other changes, fixes, and improvements: See the complete changelog for details!

Known potential issues: See here.

Donations

If you like this plugin, consider making a donation.

Thanks!