Some of the config-file resets were fixed in a previous commit:
4330885d46
The resets fixed previously were ones where snakeyaml would throw a fit
due to tabs. Because an exception is thrown, the call to saveConfig()
is never reached, which means the config-file is never reset.
However, errors resulting from other illegal characters were not caught
because the built-in reloadConfig() method catches, prints and then
simply does nothing about any exceptions thrown, which means the actual
YamlConfiguration would be empty. Saving this empty file would result
in a reset, because MobArena, during initialization, sees missing bits
and pieces and tries to insert them. Thus, the resets were not an issue
with MobArena's attempt to keep the config-file tidy, but the reckless
handling of errors in the built-in config methods in JavaPlugin.
This commit completely overrides the methods in JavaPlugin that would
result in these resets, and the MobArena plugin class stores its own
reference to the config file and an associated FileConfiguration. When
the reloadConfig() and saveConfig() methods are called, the checked
exceptions are caught and rethrown as unchecked exceptions, causing the
plugin to crash when it needs to do so.
This commit creates a fail-fast exception-throwing guard inside the
method for handling config-reloading in the main plugin class.
If a config-file contains a tab, an exception will be thrown when
the plugin loads (as it did before), which means the plugin will not
load correctly. However, upon reloading with the reload command, an
exception is thrown before the current settings are overwritten.
This fixes a long-standing issue with config-files resetting upon
reload with invalid syntax. Verification is needed, as this commit
has only been tested on OS X where tabs and carriage returns are
injected via vim.
Due to the start-delay-timer holding a reference to the
auto-start-timer as its internal callback, the start-delay-timer
should be stopped, when both timers should be stopped.
The StartDelayTimer wraps the AutoStartTimer and provides a means of
"locking" the lobby until a configurable time has passed. During this
time, it is possible for other players to join the lobby and ready up,
but the arena will not start until the StartDelayTimer has run out,
after which the AutoStartTimer is started (if applicable).
New per-arena setting: start-delay-timer: [seconds]
New announcement: arena-start-delay
This framework consists of interfaces and classes for managing various
kinds of timers. The Timer interface models a timer with configurable
tick intervals. The TimerCallback interface provides a means of adding
logic to the following timer events: onStart, onStop, onFinish and
onTick.
Timer implementations include a CountdownTimer (kitchen timer), and a
StopwatchTimer, which should both be self-explanatory.
The purpose of this framework is to add a means of creating a very
generalized approach to timers, in hopes of abstracting away some of
the Bukkit scheduling for easy maintenance and increased portability.
Future work:
- Port auto-start-timer
- Port boss abilities
- Port spawner
- Create 'delay-timer' as per DBO ticket request.
- Create various types of cooldowns, delays, etc.
When the WaveManager is queried for the next wave to be spawned via
the next() method, it now returns a copy of the wave instead of the
wave itself. This is because waves (boss waves in particular) have
state, and this state is transferred to the next occurrence of the
given wave. This caused recurrent boss waves to inconsistently share
state, which resulted in the BossAbilityThread bailing early after
the first occurrence of the boss wave it belonged to. By copying
the initial wave state in the WaveManager, the issue is fixed.
Fixes: http://dev.bukkit.org/bukkit-plugins/mobarena/tickets/1220/
This is necessary to ensure a robust /ma spec command. If no spectator
warp is set, the command will throw an NPE - it is much more safe and
sane to require the warp.
The items-node in the classes section now supports list values instead
of strictly string-values. This should make it easier to see exactly
which items a class has, and it should alleviate some of the problems
associated with apostrophes and such. The string-valued setup is still
supported to preserve some backwards compatibility.
The armor-node remains untouched, but it will probably be updated to
the same system later.
The notion of a "selected arena" disappears with this commit. All
commands that previously did not require an arena name in the case
of multiple arenas now do, i.e. it is no longer possible to "set"
an arena to be the target of commands. This should not be an issue,
however, since Setup Mode replaces all the commands that previously
were the main reason for the notion of a selected arena.
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
garbagemule