These newly added messages are also used now when giving items to yourself.
Added messages:
* msg-shop-creation-items-received
* msg-currency-items-received
* msg-high-currency-items-received
This has (among other things) fixed the issue that various optional (context dependent) command arguments were shown to be required inside the Shopkeepers command help.
Also: Missing Override annotation in AnyFallbackArgument.
Their default size is 1 (tiny). Even though Minecraft theoretically allows sizes up to 256, we limit the max size to 10. This avoids running into issues such as related to rendering, performance and not being able to interact with the slime or magma cube.
This also fixes the issue of slimes and magma cubes spawning with random size everytime they are respawned.
Added messages:
* msg-button-slime-size
* msg-button-slime-size-lore
* msg-button-magma-cube-size
* msg-button-magma-cube-size-lore
Internal: Slightly changed how we cycle through the villager levels (badge colors).
This setting allows changing the number of pages that can be filled with
trading options.
This limit applies to all shopkeepers (there are no different settings
for different types of shops or different permission levels so far).
This allows for up to 90 trades per shopkeeper now. Note: This seems to
work fine. However, the scroll bar rendered by the
Minecraft client will only work nicely for up to 64 trades.
We would receive a warning inside the log then about an unexpected entity (the passenger) being spawned.
This has been fixed by moving the call to 'forceCreatureSpawn' into the entity's preparation callback, after the entity has already randomly spawned its passengers and right before this specific entity is about to get spawned.
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.
Also: Added a note about the migration of 'ZOMBIE_PIGMAN_SPAWN_EGG' items to 'ZOMBIFIED_PIGLIN_SPAWN_EGG' items to the changelog. Spigot automatically migrates any 'ZOMBIE_PIGMAN_SPAWN_EGG' items inside the shopkeepers data. With the above change we also ensure that the migration results get saved back to the save.yml file in all cases.
We no longer use Bukkit's (now outdated) TreeSpecies enum to represent the available sign/wood types. Instead we use our own 'SignType' enum.
Sign shops of type 'GENERIC' and 'REDWOOD' are migrated to 'OAK' and 'SPRUCE' respectively.
When loading the sign type from the storage we verify that the loaded type is both valid and also supported on the currently used server version.
Also:
* Added the debug option 'capabilities', which logs additional details when the plugin checks for server version dependent capabilities.
* Added a note to the changelog regarding Minecrafts new chat features not being supported yet.
* Bumped version to 2.10.0-SNAPSHOT.
* 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.
Other changes:
* Improved/Fixed: Some mobs randomly spawn with passengers. We remove those passengers now.
* 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 player's 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 message 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.
* Debug: Minor changes to some debug messages.
* Internal: When the shop object is deleted, we explicitly check if there still is a corresponding NPC and otherwise abort right away.
* Internal: Moved the common code for looking up the corresponding shopkeeper for a given NPC into CitizensShops#getShopkeeper(NPC).
* Internal: The constructor of the shopkeeper trait refers the TRAIT_NAME constant to get its trait name now.
* Internal: Minor formatting, renaming and clarifications.
Added the messages 'msg-cant-trade-with-own-shop' and 'msg-cant-trade-with-shop-missing-chest' for the cases that trading with the own shop is prevented or if the target shop is missing its chest.
Also:
* 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.
* 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.
* Slightly changed the german translation of the 'msg-cant-trade-while-owner-online' message.
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 messages:
* msg-button-rabbit-variant
* msg-button-rabbit-variant-lore
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.
* Renamed TextText to PlainText.
* Added Text#setPlaceholderArguments(Object... argumentPairs) directly to Text.
* TextUtils#addArguments is public now and called TextUtils#addArgumentsToMap. It has some validation added to it.
* Removed the generic varargs type parameter from a few utlity methods inside TextUtils.
* Moved the next and child references up in the hierarchy into AbstractText. AbstractText#setParent is private now.
* Also moved various other common method implementations related to placeholders and plain text formatting into AbstractText.
* Minor javadoc changes, parameter renaming and formatting.
entity interaction now while holding the shop creation item in hand.
This resolves issues such as players being able to spawn baby mobs by
interacting with regular mobs while holding a spawn egg shop creation
item in hand (such as the default villager spawn egg shop creation
item). Other kinds of item and entity specific interaction behaviors and
the equipment of armor stands with shop creation items are blocked by
this change as well.
Players with the 'shopkeeper.bypass' permission are exempt from this
restriction.
Internal: Added ItemUtils#getItem(PlayerInventory, EquipmentSlot) method. This is also used within the BlockZombieVillagerCuringListener now. This utility method can be replaced with the corresponding Bukkit API method once we only support the latest versions of Bukkit 1.15.2 and upwards.
* 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 shops 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).
* Debug: Added some more information to the debug message that gets logged when the PlayerDeleteShopkeeperEvent has been cancelled.
* 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.
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.
* Minor formatting changes. Not applied to the whole code base yet.
Message changes:
* 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).
The shop will then be opened for the specified player.
Opening shops for other players requires the new 'shopkeeper.remote.otherplayers' permission (default: op).
The msg-command-description-remote message has been adapted to the addition of the optional player argument.
Internal: The description of the shopkeeper.remote permission has been updated to reflect that this commands also works for non-admin shops.
case the trade is invalid or disallowed (eg. when using strict item
comparison).
However, it has turned out that this doesn't work, because the client
will reset the result slot whenever it receives any slot update from the
server (including when we try to explicitly overwrite the item inside
the result slot).
in order to ignore those inside the editor and hiring ui views.
The heuristic works by ignoring any shift left-clicks that occur within
250 ms on a slot different to the previously clicked. The time span
cannot be reduced much further because the automatically triggered click
events may be received quite some time after the manual click that
triggered them (up to 150 ms on a local server and likely even later
with network delay involved).
This also does not work with automatic clicks on the same slots, because
we cannot differentiate them from regular fast clicking.
When a player interacts with a shopkeeper entity while holding an item
in hand, we may first receive the entity interaction event, which starts
an UI session, and then the interaction event for the item. To not start
any item actions for the held item (such as trident charging, food
consumption, etc.), we cancel any interaction events while an UI session
is already active.
blablubbabc