This commit transforms the announcements system in the following way:
- announcements.yml makes it easier to add missing nodes and remove
obsolete ones. This way, users don't have to delete their previous
announcements-file to get the new keys.
- Color codes are supported in the fact that when an announcement
message is "set()", the string value has all of its &-symbols
translated.
- No need for a defaults-file, because the enum is very easy to
compile into a YAML file.
This change involves many classes because the adapter was relied upon
heavily throughout the project. The change is motivated by the fact
that the wrapper created more problems than it solved. Those problems
(listed here) are solved by this commit. Some classes have undergone
notable changes (e.g. ArenaRegion).
- The config-file will no longer overwrite and regenerate itself
seemingly randomly.
- The config-file will now save correctly when setting points and
expanding regions.
- The "no class items in lobby" problem has been fixed.
- The "must be inside region" problem has been fixed.
The classchest command can be used to link a chest to a class directly
(although still in the same world) without having to position them in
a specific pillar under the signs.
- When a player attempts to join or spec an arena while they are
in an arena (arena or lobby), they will be denied access.
- When a player attempts to join or spec an arena while they are
spectating an arena, they will be force-left first.
The region now contains two location references per region point for
the bounding boxes where p1, p2, l1 and l2 remain the same (min/max),
but also additional locations for the player's actual location, such
that e.g. moving back and re-setting a point has the more intuitive
behavior of expanding regardless of the optimized points.
This also (hopefully) finally fixes the previous issues with the setup
process *knock on wood*.
Previously, the set() method would overwrite coordinates completely
without min/max'ing the values to preserve the invariant that p1 is
the lowest point and p2 the highest.
Since ConfigurationSerializable, there's no need to manually serialize
items anymore, and thus we let Bukkit serialize player inventories for
when players join arenas.
However, the "repairables" in the soft-restore mechanism still use the
now obsolete SerializableItem and SerializableInventory classes, and
should perhaps be rewritten.
Note that for 1.0, it may still be necessary to write a custom means
of serializing items, since we don't know if a given implementation
supports native serialization (however it should be possible to rely
on Bukkit's in the Bukkit-specific classes).