This commit introduces a Component system focused around Games, which is completely
backwards compatible, as well as designed to be flexible enough for later improvements
such as dependency injection. Each GameState is associated with a phase of the
PhasedLifetime that each Game has. Components can be registered with a specific phased
or the entirety of the Lifetime. Refer to the javadocs for Lifetime and PhasedLifetime
for more details. Currently the main two Component types are ICommand and
ListenerComponent.
This commit includes the first refactoring into using this system, which is replacing
the Wizards minigame's usage of Miniplugin with a Lifetimed Component, allowing for
the shop to be appropriately registered and unregistered. This change allows for
Wizards to be run more than once on the same server instance. Previously, attempting
to register the Miniplugin twice would result in the minigame failing to start after
the initial registration.
This commit additionally includes slight refactoring within GameCreationManager as
required for the Lifetime system to function correctly. These changes ensure that
Games are only disabled once, whereas before they could be repeatedly disabled.
The previous implementation of disable(), along with the classes that override it,
functioned correctly despite being called several times.
Finally, this commit adds in changes to the pom to allow for unit testing.
Currently players are unable to drop items if the held item
slot is below 5. This works fine when dropping items simply
by pressing q, but it often interferes with players dropping
items from an open inventory. This commit changes the check
to iterate over the first five slots and only cancel the event
if they're dropping one of them.
While the name of the gold items is "Golden X", the
name of the material is "GOLD X" resulting in gold items
providing no protective benefit other than the default
vanilla protection(in the case of there being only gold
armor).
This issue came down to two bugs with the explosions created
by Fireball and AnvilDrop.
The first was the damage being done. Settings the max damage
doesn't change the base damage, so they did the default amount
of damage based on the vanilla code.
The second was the radius of the explosion. The radius was
too small, and so it was perceived that only users directly hit
would suffer damage. The radius was increased, however the block
explosion size was kept the same.
