* 'admin-sign-shop-line1/2/3/4'
* 'player-sign-shop-line1/2/3/4'
This gives more control over the sign contents of admin and player shop signs.
The default appearance of sign shops has also changed. They are slightly more colorful now.
The enabled living shop types get validated and cached as part of the derived settings now.
Also: 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.
Also refactoring: Moved the validation of settings into a separate method.
* A value of '0' for the 'max-shops-per-player' setting no longer indicates no limit, but can be used to disable the creation and hiring of player shops. 'No limit' is indicated by a value of '-1' now. Any previous limit of '0' is automatically migrated.
* The permissions specified inside the config get cached and checked in decreasing order now. We abort checking permissions if they cannot further increase the player's current shops limit. An effect of this is that it is only possible to increase the default limit, not decrease it.
* Added permission node 'shopkeeper.maxshops.unlimited' (default: op), which disables the max shops limit for a player.
* Message: Changed the 'too-many-shops' message to be more general.
command.
* If the player targets a container (regardless of whether it is
supported), we assume that he might be trying to create a player shop.
However, unlike before this only affects the default shop type that is
chosen if the player does not specify a shop type himself.
* It is now possible to create admin shops via command even when
targeting a container. However, the admin shop type has to be explicitly
specified as command argument.
* When a player shop type is selected, we send appropriate feedback
messages depending on whether player shop creation via command is
enabled, whether a container is targeted, and whether it is a supported
type of container.
* When not specifying a shop object type, we pick the first shop object
type that can be used by the player. This is consistent between the
creation of player and admin shops now.
Messages:
* Added 'must-target-container'.
* Added 'no-player-shops-via-command'.
* Removed 'no-admin-shop-type-selected'.
* Removed 'no-player-shop-type-selected'.
shop creation item.
This seems to cause more confusion than it helps. Also, this is less of
an issue, because the default shop creation item is a villager egg with
specific display name since some time now.
* 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.
* Config: Changed the default language from 'en' to 'en-default'.
Existing configs get automatically migrated.
* Fixed: Text#parse can now also parse alternative color codes starting
with '&'. This has an effect when some messages of the specified
language file cannot be loaded and the plugin then uses the default
messages instead. This is part of Text#parse now (instead of requiring a
separate color conversion) for convenience reasons.
* Added warning output when the language file misses messages, or
contains unexpected messages.
* All message keys were changed to no longer start with the 'msg'
prefix.
The idea is that this might allow for optimization when doing shopkeeper lookups: Previously we had to create and check object ids for all shop object types in order to check if a block or entity is a shopkeeper of a certain type. We still have to go through all registered shop object types, but we can skip those which use the default ids.
However, as of right now this doesn't seem to make much of a difference. In a future step we could further optimize this by caching all object types which use non-default object ids.
Also, some default method implementations were moved into AbstractBlockShopObject and AbstractEntityShopObject.
Monsters usually get set on fire quite frequently when standing in sunlight. We therefore give zombies and skeletons a stone button as helmet now. This prevents them from getting set on fire in sunlight, by which we have to process less EntityCombustEvents. The stone button is also small enough to not be visible inside their head.
Entities standing in lava or fire are still set on fire as before.
ChimneySwift
blablubbabc