Use ItemStack display name in ItemStackThing (if available).
This means that named items will appear in the rewards list with their name rather than the ItemStack type. This is useful for "tokens" type items.
Note that named items are still not supported by the built-in item parser, so this commit only affects ItemStackThings created by custom parsers (for now).
With CommandThing and its parser, it is now possible to use commands anywhere a thing can be used. Commands are invoked as the console/server, and they support a single variable, the name of the recipient player.
Commands are give-only, meaning they will fail to be "taken" from players, and they cannot be "held" either. The idea of commands as things basically only makes sense in the context of rewards.
While it doesn't really make sense to have class prices be a Thing (or maybe it does?), this does get rid of the dirty "ItemStacks wit ID -29" hack for economy money, which will eventually break, when the upstream int-based ID API breaks.
With this commit, the Things API is introduced to the code base, but it is not yet used. It introduces the building blocks for an extensible architecture that supports custom parsers and custom "things". This should allow other developers simple, yet powerful hooks into the way MobArena handles class "equipment" and rewards. The basic skeleton includes parsers for ItemStacks and economy money, so it should be interchangeable with the current inner workings of the plugin.
The commit also adds an overload to the ItemParser that allows for a the method to fail silently. This is necessary to avoid false negatives in the log in case the ItemStackThingParser fails but a different parser succeeds.
Since the announce() methods always required an Arena argument, and since the Messenger instance used was always acquired from an Arena instance, there really was no reason for the methods to exist on Messenger.
- Messenger no longer has a static nature and must be instantiated to be used. The prefix is provided in the constructor.
- MobArena instantiates a global Messenger in onEnable() with a prefix string from global-settings. This instance is used by anything that isn't arena-specific, as well as for arenas with no prefix.
- ArenaImpl instantiates a local Messenger in its constructor if, and only if, its arena-specific prefix setting is non-empty. Otherwise it uses the plugin's global instance.
This removes the logging capabilities from Messenger and replaces all references to them with proper logging via Bukkit's PluginLogger that all plugins have.
The blockList() call returns the actual List<Block> object in the explode event, which means it'll be shared between the the fake event and the original event. As a result, the call to blockList().clear() will clear the shared list, and the following call to blockList().addAll(fake.blockList()) results in trying to add the empty list to itself.
This commit makes sure to copy the original event's block list before sending it to the fake event.
Okay, "Fixes" would be lying, and that's terrible, but here's something to help you shrug it off: The timer module is a bit of a mess, and since there isn't actually anything "dangerous" about this, let's just calm our tits and focus on other stuff.
Before, these redundant calls didn't really do anything. Now they mess everything up, because setContents() doesn't set inventory contents only, but the entire inventory instead, because that's so super useful. Well done, boys!
#notsalty
Because it is clearly impossible to change JavaDocs to correctly describe what a method does, the method setContents() has now been changed to a useless, over-aggressive, inventory-wiping piece of junk that must be invoked before anything else. This commit ensures that armor contents are set after the setContents() method is called, overwriting the nulls that the setContents() method creates.
