It's not clear why this variation in the auto-ready logic exists, and
the commit history doesn't seem to have any clues either. Perhaps the
actual readying up logic was incompatible with auto-ready at some point,
but at this point in time it doesn't seem like this is necessary at all,
and it appears to be causing a bug with the MobArenaStats extension.
By simply calling the player ready procedure regardless of the status of
the auto start timer, MobArena fires the arena player ready event that
MobArenaStats depends on for some of its pre-session bookkeeping. It
could be argued that MobArenaStats should be more robust, but we would
much rather fix the root problem than slack on the otherwise fairly
sound strictness of the MobArenaStats data model.
Fixes#746
Makes the boss entity the source of the obsidian bomb explosion, which
then makes the damage event listener handle the explosion damage as if
the boss is the damager, which means the `monster-infight` flag should
be respected.
Fixes#759
Makes the sheep entity the source of the explosion that's created when
it triggers close to a player. This, in turn, makes the damage event
listener handle the explosion damage as if the sheep is the damager,
which means it will respect the `monster-infight` flag.
Fixes#758
This new spawn reason was introduced somewhere between 1.18 and 1.18.1,
and unfortunately it is a breaking change, so we have to employ it for
MobArena to properly allow and register vexes (again...), but we also
have to maintain a variation of the old logic so we don't break support
for older server versions.
Fixes#719
This time around we're trying to keep the API version bumped for the
sake of not leaving the people who actually keep their servers updated
behind. It does present some potential backwards compatibility issues
when we do employ new API, but we'll just have to be mindful of _how_ we
go about doing so...
When a player with pets dies in the arena, we want their pets to be
removed. One could probably argue that the pets _should_ be able to
stick around, but the original intent was for them to be removed
alongside their owner.
Fixes#721
Removes the first `_` in the `_SHULKER_BOX` matching to ensure that normal shulker boxes with ID `SHULKER_BOX` are removed from My Items as well.
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
This new setting allows changing the fuse time for auto-ignited TNT,
which is normally a hardcoded 80 ticks in Minecraft. Note the somewhat
weak safeguarding without any sort of error message - with great power
comes great responsibility...
Closes#715
This property makes TNT explosions look more "real" to other plugins who
may be consuming events from MobArena's sessions. It also gives way to a
potential rework of the "planter" logic that currently makes use of the
Bukkit Metadata API.
Closes#718
Changes the behavior of the ArenaListener's teleport event handler such
that it _ignores_ teleport attempts instead of _rejecting_ them when the
player in question has the `mobarena.admin.teleport` permission. Because
the global listener's event handler only ever checks the permission if
at least one per-arena listener has _rejected_ the teleport attempt, and
none of them have explicitly _allowed_ it, the change means that it will
never check the permission, because its internal `allow` flag will never
change to `false`. Thus, the check can be safely removed from the global
listener's logic.
When the response is to ignore instead of reject, the message that would
have otherwise been sent to the player is skipped. This fixes#702.
It is perhaps tempting to move the permission check up into the section
of sanity checks in the global listener, but this is very specifically
avoided to allow MobArena to _uncancel_ teleport events that have been
cancelled by other plugins, but that MobArena might need to go through.
Please see afcc526a71 for more info.
This is technically not necessary when pets are simple entities like
wolves and zombies, because these types of pets will never target and
thus attack other players in the arena. However, projectile entities
such as Blazes and Ghasts may hit players in the line of fire, and so
any such damage should be cancelled.
Fixes#712
Introduces a new arena setting that changes the "emptiness check" for
`clear-wave-before-next`, `clear-wave-before-boss`, and the final wave
check, allowing for a customizable _leeway_.
By default, the leeway is 0, which means the monster set has to be
completely empty for the checks to pass. With a value of 2, the set
may contain up to two monsters for the checks to pass, and so on.
The leeway should help alleviate some of the issues some people have
with their arena sessions when monsters "disappear" behind terrain or
end up in hard-to-reach areas. This is by no means a real "solution"
to the underlying problem, since the build-up of monsters in longer
sessions will just result in the issue being pushed to later waves.
We'll see if the setting leaves any additional customization to be
desired and perhaps defer any such requests to the Sessions Rework.
Closes#706
Sets the player fall-distance to 0 before performing a player teleport
during "move player" steps. This should cancel out the any fall damage
that may have built up before the teleport was initiated.
Fixes#698
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
It turns out that, according to the Spigot API, flaming arrows actually
_change_ TNT blocks to air before/instead of igniting them. While this
is a little counter-intuitive, the fix seems to revolve around allowing
the change to happen if the changed block is TNT and the "changer" is an
arrow.
Allowing the change event to happen means "foreign" primed TNT entities
will spawn, which makes it necessary to clean them up during the session
cleanup phase in ArenaImpl.
Fixes#696
It's not clear if this change actually solves the underlying issue,
because it has not been tested in a controlled environment. However,
considering the EntityExplodeEvent constructor, which doesn't take a
cancel state value, and the `HIGHEST` priority setting of MobArena's
event handler, the issue is realistic, and this change very likely
solves the issue.
Fixes#704
The arena signs predate the use of arena slugs everywhere, so something
slipped through the cracks in this regard. Incidentally, the handler for
arena updates is one of the few classes in the signs package that has no
unit tests, probably due to it being "obvious implementation". Not so
obvious after all, it seems, so now we have a basic test for it.
Fixes#705
This commit (unfortunately) makes two somewhat unrelated changes:
- Forces certain ageable entities into adulthood to prevent the occasional baby spawns (fixes#687).
- Introduces support for baby versions of certain ageable entities (fixes#689).
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
Introduces four "new" boss abilities that work like their pre-existing counterparts, but affect all players in the arena. This makes the four _ability sets_ a bit more complete, as it were, in that it is now possible to choose between single targets, nearby, distant, or _all_ players for the given abilities.
Closes#434
Due to a breaking change in Spigot 1.17, sending a title with an empty string no longer works, even if a non-empty subtitle is provided. The TitleAnnouncer and TitleHealthBar components only use the subtitle portion of the title API to avoid obtrusive behavior.
With this commit, the two components send a single space character as the title. Effectively, there is no difference between showing the empty string or a single space on the client-side. It's a dirty hack to fix something that should be fixed in Spigot instead, but odds are that it won't be.
Fixes#683
Introduces a new arena setting to force spectators to leave the arena
when the current session ends. If set to `true`, it "overrides" the
behavior of `spectate-on-death: true` when players respawn, such that
they only become spectators if there is an active arena session.
The respawn behavior technically means that it is possible for a player
to begin spectating "the next session" if a new session begins between
them dying and clicking Respawn on the death screen. Ideally, we would
want the player to auto-leave, because the session _they_ participated
in ended, but we don't have a concept of "previous sessions", so this
quirky behavior will have to do.
Closes#682
When piglins, piglin brutes, and hoglins go through zombification, the current entity is removed, and a new one spawns. MobArena prevents the zombified entity from spawning, so it feels like the mobs just "vanish".
We don't actually want the mobs to zombify, however, so this commit makes them immune to the zombification process. Note that this shouldn't cause any problems on server versions prior to 1.16, because the piglin and hoglin keys never get registered on those versions, so there is no risk of hitting those branches in the `switch` statement.
Fixes#684
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
Adds a new optional `pet-name` property to arena class configurations that lets server owners set a custom pet name template instead of the hardcoded "<player>'s pet". This allows for translation and color coding. To accommodate setups where the player's "display name" isn't a good fit, e.g. because it is too long, the more generic "player name" is available for use instead.
Closes#595
Co-authored-by: Bobcat00 <Bobcat00@users.noreply.github.com>
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
Changes the way monster equipment is handled from clearing _all_ items to clearing just the armor contents. This means that monsters that naturally spawn with weapons won't need their weapons added back in.
It also means that monsters that _occasionally_ spawn naturally with weapons now may do that in arenas. This is deemed acceptable, because:
- occasional weapons don't have as much of an impact as occasional armor,
- the forwards compatibility aspect is too valuable to pass up on, and
- should occasional weapons become too much of an issue, they can be conditionally removed, i.e. we can implement the _inverse_ behavior of what we had previously.
Fixes#641Fixes#686
Co-authored-by: Andreas Troelsen <garbagemule@gmail.com>
This commit filters the result list of a ThingGroupPicker by a non-null
predicate to avoid null values in the resulting ThingGroup instance.
Since null values represent `nothing`, and we don't usually announce it
when players earn a `nothing` reward, it makes sense that they wouldn't
bubble up and somehow "manifest" in groups of things either.
Fixes#691
This commit introduces a new type variant, `angry-bee`, which is a bee
whose anger level is maximized upon spawning, much in the same vein as
its angry wolf cousin.
Note that bees are not available prior to Minecraft 1.15, so a sentinel
`null` name is used in the registration to prevent warnings from being
logged on server versions that don't have a concept of bees.
Closes#584
Because this bullet covers both the commit with the version bump and the
following compatibility commits, it didn't really fit properly into any
one of those commits, so now it gets its own!
This commit introduces two reload events, MobArenaPreReloadEvent and
MobArenaReloadEvent. Both events are fired when MobArena reloads, the
former right before the reload, and the latter right after.
The reason for two events is to allow plugins to reload either entirely
or partially along with MobArena, if it makes sense for them to do so,
_when_ it makes sense for them to do so. Some plugins need to reload and
re-register themselves with MobArena before the config-file itself is
loaded (e.g. ThingParsers), while others either require MobArena to be
fully loaded or are more decoupled and thus don't depend on anything in
MobArena's innards to function. The "pre" event is for the former, while
the other event is for the latter.
As for naming, the choice of "Pre" and no prefix was made for the sake
of consistency with the event names in the Bukkit API, which has just
one example of such a pair (PlayerPreLoginEvent and PlayerLoginEvent).
Some event naming conventions (e.g. in the .NET world) seem to favor
present and past tense (reloading, reloaded), but this would be wildly
inconsistent with the rest of the event names, so it might be better to
just stay consistent. Names may change before an actual release, but for
now, this is what we're rolling with.
Closes#677
This commit introduces a new `register()` method on the CommandHandler
class to allow registering pre-instantiated subcommands. This means that
subcommands are no longer restricted in terms of instantiation, so they
can have their dependencies injected at creation, rather than having to
resort to Singleton anti-pattern means.
Also refactors the existing internal MobArena command registration to
use the new method to "drink our own champagne" and to reuse the code.
Fixes#675
This commit changes the pattern of the player list command to one that
isn't quite as greedy. This change is enough to fix issue #676 and thus
allow MobArenaStats to take control of its own command.
The command framework could definitely do with a bit of a rework away
from pattern matching towards aliases, which would prevent similar
issues from cropping up down the line. For now, this is good enough.
Fixes#676
These should have been included in their respective commits, but they
didn't seem particularly interesting for end users at the time. Might as
well include them, though.
This commit re-frames the formula concept used by the wave growth, swarm
amount, and boss health wave configuration properties. It fundamentally
changes how these values are calculated, from a static, compile-time set
of enum values and hardcoded expressions, to a powerful math expression
feature that supports constants, variables, operators, and functions.
In part to remain backwards compatible with existing MobArena setups,
and in part for a better user experience, the old enum-based expressions
are relocated into a new file, `formulas.yml`, as _macros_. The file is
written to the plugin folder if missing, and it contains a formula for
each of the legacy values for each of the enums. Additionally, it has a
global section with some predefined macros for inspiration's sake. The
goal of this file is to allow people to define new formulas and reuse
them in their wave configurations instead of having to duplicate the
same formulas again and again.
Parts of the system are extensible. It is possible for other plugins to
register additional constants, variables, operators, and functions.
Closes#460Closes#461
This commit constitutes a major rewrite of how arena signs are stored
and loaded. It fixes an issue where an unloaded or missing world would
cause MobArena to throw errors if there were any arena signs recorded in
said world.
The solution is to load signs of a given world when it is available,
rather than loading all signs at once indiscriminately. At startup,
signs for all _currently available_ worlds are loaded. This fixes the
errors. When a world loads and a WorldLoadEvent is fired, signs in that
world are loaded. This ensures that all valid signs in existing worlds
will _eventually_ load. To keep things tidy, a WorldUnloadEvent will
unload all signs for the unloaded world.
Bukkit's own YAML deserialization implementation doesn't re-throw all
deserialization errors, which means we can't actually catch the problem
of missing worlds without doing an awkward "scan" of the deserialized
objects. This prompted a rewrite of the serialization and data storage
into a custom CSV-like format which is both simpler and also provides a
lot more control over the process. Instead of relying on world _names_,
the new format uses world _UUIDs_. While the rest of the plugin won't
necessarily adapt well to a world being renamed, the signs data store
should be resilient enough to handle it.
Most of the actual sign rendering code and almost all of the template
code is intact, but quite a lot of other classes have been rewritten or
replaced. Some of the rewrites weren't strictly necessary, but because
the components were already fairly small, rewrites were much faster and
a lot less awkward than attempting to adapt existing code.
Fixes#645
This is a bit awkward to deal with, because the actual fix exists only
on the 1.8 branch, but we release from the main branch, so we want the
changelog entry to come from there.
Rearranges and reformats the changelog entry for the upcoming version to
better fit with the Keep a Changelog guidelines. We're already grouping
stuff decently, but we can do better with section headers. In an entry
like this one with lots of changes, it just makes the reading experience
much better, and we do want people to read the changelog :)
Introduces support for multi-word arena names in the two commands. The
approach is to simply join the arguments by spaces. Because of the new
slug-based lookups, multi-word names are fairly straightforward.
This commit is a minor refactor of how arenas are resolved by name,
similar to the previous arena class resolution refactoring.
The difference this time around is that there is an ArenaMaster method
that does most of the work for a lot of different areas of the plugin,
`getArenaWithName(String)`. This method is called from well over 30
different places in the code base, making it a cornerstone of all arena
resolution. Luckily, it is called primarily from places that shouldn't
care _how_ an arena is resolved.
Affected by this commit are all commands that resolve arenas by name,
including all those not listed in the diff, because of the change to
`getArenaWithName(String)` on ArenaMaster.
Commands that can tab complete arena name arguments now complete slugs
instead of config names.
Going forward, it should be possible to show "pretty" arena names by
simply using a pretty name in the config-file instead of slug-like names
now that slugs are on the horizon.
Swaps the weird "camel casing" approach in the autogenerate command out
with simply using the "config name" of the arena classes when creating
class selection signs.
This fixes the breaking change to how classes are resolved in a previous
commit, but only in future arena generation procedures. Arena generated
before this change may still contain broken class signs.
This commit is a minor refactoring of the class selection functionality
plugin-wide. Instead of selecting classes based on the "lowercase name"
of a class, commands and listeners are now "slug aware", as it were.
The ArenaClass class now uses its slug instead of its "lowercase name"
for equality and hash codes.
The `/ma class` command now tab completes slugs, but it still supports
class names as they appear in the config-file when executing the command
itself. The same applies to the `/ma classchest` command.
The sign handling in ArenaListener slugifies sign text instead of just
lowercasing and stripping spaces.
This commit changes the permission checks for arenas and classes to a
slug-based approach instead of the "config names", which are somewhat
arbitrary and may contain spaces, which are generally not supported by
permissions plugins.
This is a breaking change, which means it will be necessary for users
to change their permission setups. Backwards compatibility could have
been implemented, but it just leaves more room for ambiguity and will
make a necessary transition later down the road less obvious. Instead,
we burn the ships!
As a result of this change, access to the "My Items" class can now be
revoked as intended with the key `mobarena.classes.my-items`.
Fixes#647
This command takes an arena player and a Thing as input. The Thing is
parsed in the same way as all other rewards are parsed, so it supports
the new `all()` and `random()` functions and the `nothing` keyword.
The "target audience" of the command is mainly scripts. It opens up the
possibility of hooking into MobArena's rewards from command blocks or
other plugins, but with very low coupling.
Closes#643
By using a ThingPicker instead of a Thing, boss rewards can now, just
like regular wave rewards, make use of the new `random()` and `all()`
functions as well as the `nothing` keyword.
Closes#628
This commit introduces the strange concept of a singleton ThingPicker
that only ever picks `null`. The purpose of this picker is to allow for
a type of "loot table" experience similar to that found in other games.
An example would be a piece of equipment that only has a 50 % chance of
dropping. With the current state of MobArena, it would be necessary to
something conjure up a CommandThing or something to emulate nothingness,
but now there is native support for it with the `nothing` keyword.
The nullability of rewards also has the side effect that we got to clean
up the MASpawnThread `addReward` method a bit.
Closes#638
This commit makes the MAUtils class responsible for parsing reward maps
use the new ThingPickerManager to parse the reward lists. As a result,
the new `all()` and `random()` pickers are available for use in the
rewards section.
This should allow for granting item sets and similar types of "bundles"
as rewards in the arena, e.g. a diamond sword and permission to join a
more difficult arena.
Closes#386
