The /ma setup <arena> command is the first step in the process of
making the setup procedure more intuitive. The command consists of
the actual command handling, as well as a multi-role inner class,
and together they constitute Setup Mode.
- Toolbox; a set of tools are provided to the user, and a handler
for the interact event will react to the usage of these tools,
providing the primary, interactive element of Setup Mode. The
tools are used to set regions, warps and points.
- Text input; by typing 'exp', the user can expand a given region
in the typical directions (up, down, out), and by typing 'show',
the user can request red wool blocks to be displayed in place of
region frames, warps and points.
Whilst in Setup Mode, the user cannot type any commands, because
the input is intercepted due to the Conversations API - this is
by design, and may prevent some inconsistencies.
The next step in the process will be to fully remove the commands
that Setup Mode renders obsolete. The commands include, but are
not limited to:
- set(lobby)region
- expand(lobby)region
- setwarp
- addspawn
- delspawn
- addchest
- delchest
- The execute() method has had its docs redefined to reflect how the
CommandHandler now handles the return value of the method. That is,
if the method returns false, the CommandHandler prints the usage
message and description of the command to the command sender.
- Commands now only return false when they should, according to the
updated docs of the execute() method.
- Most commands have been tidied up a bit, i.e. they've had some
unnecessary code removed in the advent of the new usage printing
of the CommandHandler.
- Some commands have had their patterns altered slightly.
- The order of command registration now matters. That is, the order
commands are registered in will be the order in which the help
screen will display the command usages and descriptions.
- The help screen now shows ordered commands, and separates the
types into user, admin and setup sections for a better overview.
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.
This commit consists of two components:
- Restarts are no longer required after setting up the first arena
- Regions no longer auto-expand
The restart requirement is fixed by preventing the ArenaMaster from
actually creating an Arena object and assigning it to the selected
arena upon generating the default arena node in the config-file. The
problem was that the selected arena was set to this initial Arena
object, but another Arena object was created afterwards, which due
to the equals() method of ArenaImpl overwrote the previously created
Arena object in the arenas-list, but didn't change the reference in
the selected arena. In other words; two identical Arena objects were
created, but used in different places (arena list vs. selected arena).
The auto-expansion is removed by simply never auto-expanding regions
upon setting the arena warp or spawnpoints. Instead, setting these
warps throws an error, if p1 and p2 have not yet been set, or if the
location is outside the region.
- All the core abilities have been moved into the project folders
such that they no longer require any extraction. As such, all
servers should have the abilities already installed and ready
to use, regardless of setup-retardation.
- An attempt at fixing the "invisible bosses" issue; a call to
removeBoss was replaced with getBoss - hopefully this fixes
all the issues.
Using a node setup similar to that of the classes-section, it is
now possible to make complex Upgrade Waves that update weapons
and armor on-the-fly. This also means 'permissions' upgrades.
