To ensure that we are extensible from the get-go, this commit introduces
the parser aspect of the ThingPicker framework with parsers for the two
non-trivial picker implementations.
Nothing is wired up yet.
Things work best as hardwired, atomic pieces of "stuff", so fitting RNG
into the framework is a little difficult. We could have a RandomThing,
but the issue with that is that the entropy has to live inside of it for
it to be random every time it is given, taken, or checked. This makes it
impossible to make a well-defined, atomic Thing with entropy involved.
Enter the pickers.
The ThingPicker is an early stage extension to the Things framework that
encapsulates the possibilities of entropy and grouping _around_ Things,
a type of Factory pattern.
This introductory stage consists of a "leaf picker" that can only ever
pick a single Thing, a Composite Pattern "group picker" that wraps a
list of other pickers and shoves their resulting Thing instances into a
ThingGroup (introduced in the previous commit).
These simple constructs should now make it possible to introduce entropy
without placing the responsibility on the Thing framework itself. Using
this extension requires adapting code to using the ThingPicker interface
instead of using Thing directly.
Introduces a group of Things as a construct for bundling Things that
should constitute a single unit for whatever reason.
One reason could be to make an _item set_ an atomic reward, e.g. a set
of diamond tools for beating the `workshop` arena. Instead of having to
spread the rewards out into multiple waves or use a different plugin to
create item groups, this component allows MobArena to support that kind
of intent natively.
Note that nothing is wired up in this commit, so really this commit is
just introducing unused code.
Introduces the concept of an Announcer, which is invoked whenever the
`announce` methods on the Arena interface are invoked. Previously, all
announcements would simply be sent to the arena's Messenger, but this
new feature allows us to move them up into titles to help declutter the
somewhat overloaded chat box.
By default, to help people discover the new feature, the announcer type
is `title`, but it is possible to switch back to `chat` for the original
behavior.
Closes#272
Errata to commit 84a7a2ed8a.
The protocol after the join/leave process rework was:
- `spectate-on-death: true`: leave, then spec
- `spectate-on-death: false`: leave
The protocol now is:
- `spectate-on-death: true`: spec
- `spectate-on-death: false`: spec, then "leave"
I put "leave" in quotes, because _discarding_ the player here does not
invoke the part of the leave protocol that tries to ensure teleports go
through according to plan. By capitalizing on the "leave" part, making
it explicit that that's what we're doing in the next tick after warping
the player to the spectator area, we return to the form of the original
rework where we use coarser-grained state control to make things easier
to reason about.
A side-effect of this change is that if players somehow manage to kill
themselves in the lobby, they will be refunded the entry fee.
This promiscuous commit goes around touching almost every file in the
repository with the intention of removing trailing whitespace and adding
newlines to files missing them.
Trailing whitespace has been a pain for along time, especially in terms
of contributing to the project without accidentally littering commits
with whitespace stripping, so this commit is long overdue.
As for the newlines, well, the script I found on StackOverflow to strip
trailing whitespace also happened to add missing newlines, which is
something I wanted to tackle anyway, but in a different commit. It's all
good though.
This commit introduces a quality-of-life feature for spreading players
out during the warp to the arena floor. The feature is configured via
the new per-arena setting `arena-warp-offset`. When the value is greater
than 0.01, MobArena will add a random number of units between 0 and the
offset value to the X and Z axes in either direction. For example, if
the value is set to 3, players will be teleported to a random location
in a 3x3 square centered on the arena warp, rather than directly to the
arena warp itself.
Closes#371
Certain class chest items are cloned before they are made unbreakable,
but not all. This commit changes that, so all items in the input array
are cloned prior to setting the unbreakable flag on them. The items that
were previously cloned specifically no longer need to be, since they are
included in the initial cloning.
Fixes#637
Plugins like Multiverse and EssentialsX have features that override the
world spawn location for players respawning both with and without bed
locations. If MobArena catches the PlayerRespawnEvent too early, these
plugins will likely overwrite the respawn location set for players that
respawn after dying in an arena session.
Because MobArena is a minigame and its respawn manipulation logic only
runs for respawning arena players, it is perfectly reasonable for it to
get the final say in where these players should respawn. It would have
been nice to just use `HIGH`, but that is what EssentialsX runs at, so
we gotta go higher than that.
This commit forgoes some of the work done in the join/leave refactoring
of commit b1c6b61827.
The intent behind the original commit was to make the join/leave process
a very strictly defined set of steps that would work atomically to try
to ensure a stable, predictable process. As a result, the idea of making
spectators out of respawning players meant first kicking them out of the
arena and then re-joining as spectators, as if they had manually typed
`/ma leave` followed by `/ma spec`.
However, on some multi-world setups, this process causes people to get
thrown around a bit, which makes for a poor user experience. This commit
changes the behavior when `spectate-on-death: true` such that the player
isn't kicked, but is instead added to the spectator player pool when
they respawn. If the flag is false, players will still get sent to the
spectator area for one tick and then immediately kicked out as if they
had manually typed `/ma leave`. This does create a little bit of jumping
around, but because there is only one world change (as there would be
anyway), it is deemed acceptable at this point in time.
Closes#508
This commit changes the way Equippable wrappers are created, such that
they more closely match the way class chest armor pieces are "guessed".
That is, instead of looking directly at the Material value of the given
item, we instead look at the name _suffix_, i.e. the part after the last
underscore in the name, e.g. `BOOTS` in `IRON_BOOTS`.
The neat thing about this approach is that it is compatible with future
items that follow the same naming convention, such as Netherite armor
pieces.
The downside is that it is stringly typed and not particularly "pretty",
and if the naming convention breaks or new items are introduced (such as
the elytra), we will have to make modifications anyway.
Fixes#636
The vanilla behavior for most mobs is that they just stop minding their
targets' business if aggro is lost. The same applies to guardians and
elder guardians.
To prevent the pace of gameplay from stagnating, MobArena compensates
for target loss by helping the mobs find a new target. The issue with
this in terms of guardians is that breaking line of sight is the only
way - besides killing it very quickly - to avoid taking damage from a
guardian due to its lock-on laser attack. This means that guardians and
elder guardians need to be excluded from the retargeting logic to make
sense in an arena setting.
This commit introduces a new EnumSet of EntityTypes to exclude from the
retargeting logic. It is not a particularly pretty solution, especially
not since ArenaListener is such a huge class already, but it does make
it easier to add more mobs later down the road, and it does a slightly
better job at giving way to a config setting at some point.
For the Mobs Rework, a per-monster flag like `auto-retarget` or similar
might be a much better solution, so it's possible to have encounters
like a small batch of guardians that _don't_ lose their targets but have
very little health, so the "race against time"-aspect can exist, but in
a much more configurable way.
Fixes#601
This commit fixes the per-arena config setting `soft-restore`. Due to
commit 92c4ce1a8b, the soft restore logic
won't run on BlockBreakEvents, because to reach that specific part of
the event handler, the `protect` flag has to be set to `true`. However,
due to an early return in the soft restore logic if the `protect` flag
_is_ set to `true`, it is effectively impossible for it to run.
The fact that this functionality has been broken for over 6 years (!)
with almost no reports of it is perhaps a testament to how little it is
being used in the wild.
The integration only works reliably with the `clear-wave-` settings set
to `true`, because it relies on there being only one "current" wave.
This is a fundamental issue with the way sessions run right now, and is
another good example of why the Sessions Rework is necessary.
It is possible to achieve the exact same functionality by just making a
couple of Upgrade Waves before and after the waves that need to have
limited skill sets (thanks Lucy). With just a couple of quality-of-life
features like wave "triggers", it's possible to make things just the way
they were with the integration, but by using some more general building
blocks.
Closes#609
Catches ConfigError and prints its message rather than letting it bubble
up to the command handler as an uncaught exception. This means that
instead of seeing "An internal error occurred...", command senders now
see the underlying error message, as well as a short message telling
them to fix the error in the config-file and reload.
Closes#599
This commit fixes the `player-time-in-arena` per-arena setting by switching to `toUpperCase()` on the string value, which means that the values can actually result in something meaningful, rather than always throwing an exception.
The feature was broken in commit b1c6b61827, and it appears to be the only such instance to sneak through.
Fixes#621
Co-authored-by: Bobcat00 <Bobcat00@users.noreply.github.com>
Co-authored-by: Chew <chew@chew.pw>
This commit completely reworks the Root Target ability implementation by
replacing the repeated teleportation code with potion effects.
The old implementation relied on teleporting the target every tick for a
given duration, but because teleporting also involves pitch and yaw, the
result was a constant "snapping back in place" experience.
The new implementation works by applying the following potion effects
with a very large amplification:
- Slowness, to prevent the player from moving out of place.
- Slow falling, to negate fall damage.
- Negative jump boost, to prevent the player from jumping around.
Note that the jump boost uses a _negative_ amplification to make it have
the inverse effect, i.e. a much worse jump ability. It is still possible
to jump an arguably negligible amount away from the root location.
Fixes#490
Makes the class chest armor guessing logic pair `"ELYTRA"` up with the
chest piece slot. This specific matching works, because there are no
underscores in the `"ELYTRA"` item name.
Fixes#616
If someone spins up MobArena with a really old config-file or simply
removes the `pet-items` section, the plugin throws an NPE. This commit
fixes that by allowing the section to not exist.
It might be a good idea to log some helpful information, but let's wait
and see if this isn't good enough.
Fixes#606, closes#608.
Thanks Chew!
Adds support for a new `ready` state in the template engine for arena signs.
A sign is in the `ready` state when there are players in the lobby and all of them have readied up. This is only relevant in arenas with start delay timers, as the arena session automatically starts when all players are ready otherwise.
The new state is completely optional, even when no base state is provided, and it inherits from the `joining` state when not defined.
Closes#593
This commit adds support for listing arena players on arena signs by
introducing the following _dynamic variables_:
- `<arena-n>` the _nth_ live arena player
- `<lobby-n>` the _nth_ player in the lobby
- `<ready-n>` the _nth_ ready player in the lobby
- `<notready-n>` the _nth_ player in the lobby who hasn't readied up
Each variable points to a list of players (sorted by name), and the `n`
is the index into that list (1-indexed). This means that putting the
variable `<notready-1>` in a template will result in the name of the
first player in the list of lobby players who haven't readied up, sorted
by player name.
Implements #592
This commit changes how the ArenaRegion `intersects()` method works:
- The implicit null checks in the `setup` and `lobbySetup` flags have been replaced with actual null checks inside the auxiliary `intersects()` function. Not only does this make the auxiliary method more robust for potential future use, it also helps tidy up the code a bit. So neat!
- The semantics have changed, since `setup` depends on more than just the `p1` and `p2` points. This fixes an (unreported) bug where the check would report a false negative in case an overlapping arena region was defined, but e.g. the arena warp was missing.
- Instead of only checking arena vs. arena and lobby vs. lobby, we now also check arena vs. lobby and lobby vs. arena. That is, if the arena region is defined, we check it against both the arena region and lobby region of the other ArenaRegion (if they are defined). Same deal with the lobby region. This should ensure that no combination of overlaps pass through the check.
This commit fixes an issue with the new `intersects()` method on ArenaRegion. Instead of blindly assuming that the region points `p1` and `p2` are set when the method is called, we first make sure both regions are properly set.
Fixes#590
This commit introduces an `intersects()` method on ArenaRegion that
allows us to check whether two regions intersect.
The new method is employed in ArenaMasterImpl during arena load. If an
arena's region intersects with any other arena's region (in the same
world), we print a warning to the server log.
Fixes#367
This commit introduces a null check in the ConfigUtils `parseLocation`
method. If the world of a location string does not exist, the method now
throws an IllegalArgumentException, which allows callers to fail more
gracefully instead of having to resort to null checks.
Additionally, the parsing of exit warps, leaderboards, or linked class
chests is wrapped in try-catch statements that re-throw ConfigErrors
for better error reporting.
Fixes#421
This commit removes the old version checker that used the DBO resource
page and replaces it with a custom checker that uses the "legacy" Spigot
resource API. The Spigot API is much more lightweight and doesn't
require any sort of parsing.
The new version checker uses a simple cache, keeping version checks
fresh for up to one hour, reducing the need to go fishing on every op
login. The cache resets on restarts, though, but this is acceptable.
Note that no attempt has been made to ensure correctness on multiple,
consecutive invocations when the cache is stale. If a cache refresh is
initiated, all update checks invoked before the cache refresh has ended
will behave as if no update is available. This is acceptable, because
update checks are non-essential, the time frame is extremely narrow, and
the most common result of an update check is "no updates available",
since the amount of update checks made is vastly greater than the amount
of updates released.
Since the actual execution of these commands use the regular player name
instead of the display name, the tab completion is useless if it doesn't
also use the regular player name.
Fixes#589
This commit is a complete rewrite of the target event handling logic in
the ArenaListener class.
Instead of the complex, inconsistent code structure with too many line
breaks between control flow branches, we just have a thin logic wrapper
that delegates the event handling to smaller, more focused functions
that handle arena pets, arena monsters, and foreign entities on their
own.
A couple of auxiliary methods are introduced to try to limit the amount
of warnings produced by checking set membership with `contains()` when
the entity/target is an Entity and the collection is a sub type.
Fixes#572
This commit removes a condition in ArenaImpl#canJoin(Player) that checks to see if the arena's WaveManager has any recurrent waves.
Removing this condition is safe, because the WaveManager already makes sure to have a "catch all" default wave at hand for when no wave definitions match a given wave number. As such, the condition in ArenaImpl is completely unnecessary, and was in fact the root cause of a bug.
Fixes#566
Due to the package structure and location of MASpawnThread, SpawnsPets doesn't need to be opened up for this to work.
This change opens up for quite a few different upgrade strategies, since pet items obtained outside of Upgrade Waves are transformed as well. It is technically a breaking change, because it breaks the invariant that "after arena start, no items are transformed to pets". However, since pet items are customizable, it is possible to just change the `bone` to `sponge` in the config-file if bones carry some sort of implicit meaning in an existing setup.
Closes#524
It doesn't seem like there was any real reason to leave out potion effects as upgrades in Upgrade Waves previously, so they were likely just forgotten in the Things API overhaul.
Closes#565
This is a bit of an overhaul of how CreatureSpawnEvent is handled:
- Events happening outside the arena region are still ignored, as are armor stands placed in edit mode.
- Otherwise, if the arena isn't running, we blanket reject all entities.
- Player-mode iron golems and snowmen are still allowed.
- Anything that isn't spawned by a plugin is rejected, _unless_ it is a Vex spawned with "default" spawn reason, which is what the Evoker summon spell uses.
In the end we have a "custom" spawn reason inside the arena region while it's running, which is perfectly "legal". And because of the unfortunate use of Creature (instead of Mob) in MACreature, Slimes and Magma Cubes still need to be handled separately here.
Fixes#564
When a player takes damage from a hostile mob, the player's class pets will have their target set to that mob. This means that even zombies can function as "real" pets!
This commit removes the `auto-respawn` arena setting and the logic associated with it.
MobArena's hacky implementation of auto-respawning is buggy and discouraged. To get true auto-respawn functionality we'd have to move to the Spigot API instead of the Bukkit API.
This commit adds custom names to class pets in the form `<player name>'s pet`. This should help players more easily distinguish between pets and hostile mobs.
This commit changes the pet parsing and handling such that it is a lot more dynamic. Rather than limiting pets to wolves and ocelots, any living entity is now a potential pet. This means that we can do away with the logic that specifically targets the Wolf and Ocelot interfaces and instead work with the more general Tameable interface. As a result, the discrepancies between Minecraft 1.13 and 1.14 in this regard are largely irrelevant, because server owners can just specify which entity they want to spawn given which item in their config-files.
MonsterManager's two Wolf- and Ocelot-specific addPet() methods are replaced with a generic addPet() method that takes an owner (Player) and a pet (Entity). This is technically a breaking API change, but MonsterManager is an internal component that is very unlikely to be used outside of MobArena.
The `global-settings` node in the config-file can no longer be forced into strict compliance via ConfigUtils, because the `pet-items` node is now dynamic rather than static.
The default `pet-items` node in the config-file no longer has `ocelot` in there to avoid confusion on 1.14. It now only contains `wolf` and people will have to add their own ocelot/cat in if they haven't added it already.
Fixes#563
This commit fixes a bug introduced in 88ddbe5ac6.
During a food level change event, if the arena is running and the food level lock is enabled, we just need to also make sure that the given player is actually in the arena, otherwise it affects everyone on the server.
Fixes#557
This commit changes how SitPets determines if a nearby entity is "pet material". Instead of assuming that wolves and ocelots are tameable, we check for the Tameable interface. This means that we get rid of the "concrete" types, Wolf and Ocelot, and also fixes a bug on Minecraft 1.14 servers where ocelots are no longer tameable, but cats are. It also kinda catches parrots, but they will not sit if they are flying or perching on the player's shoulder when joining.
Because ocelots are no longer tameable in 1.14, they shouldn't cause trouble here, but because they are tameable in 1.13, we need to rely on the Tameable interface to maintain both backwards and forwards compatibility.
Fixes#548 (kind of - no more exceptions thrown, but the pet ocelots from SuperLuckyBlock may misbehave, however that is a different issue).
This commit adds support for basic tab completion for most of the commands that take arguments. Some completions are somewhat intelligent, e.g. `/ma join` which only lists enabled and "functional" arenas that the given player is permitted to use. Others are just kinda dumb, e.g. `/ma enable` which indiscriminately lists all arenas.
Closes#405
This commit changes how the final "catch all" works for incoming monster damage. Instead of checking if the damager entity is a LivingEntity, we check if it is a monster of the arena and then proceed as normal.
Note that this change may make it possible for monsters in the arena to take damage from non-arena entities. The so-called "catch all" doesn't really catch everything, but it does catch the infighting that it was designed to catch.
One "not thought of" damage source is that of player-made golems, so coincidentally, this commit fixes#550.
This commit adds support for altering the data portion of a potion item by prefixing either `long_` or `strong_` to get extended duration or level II versions of the given potion, respectively.
Closes#520
getById() is deprecated, and while this does break existing functionality, it is a good kind of breakage because it forces people over to the name-based IDs, which they will eventually be happier with.
Partial fix for #406
Similar to the previous commit about leaderboards, this commit fixes the crash caused by using the MaterialData API on Minecraft 1.14 servers.
Fixes#546
This commit fixes a bug on Minecraft 1.14 servers where leaderboards would cause a NullPointerException due to the MaterialData API being broken. Instead, we now use the new BlockData API, and everything is back to normal.
Fixes#536
This commit changes how the unbreakable setting works by just assuming that everything that is "damageable" (implements the Damageable interface) needs to be set as unbreakable. This means that the entire weapons/armor collection in ArenaClass is obsolete, and all of the checking is contained in ArenaImpl.
Fixes#544
This commit changes the SetHealth step such that it uses the player's own value for max health rather than the generic base value. As a result, players who join holding items that lower their max health will be missing health as soon as they join the lobby. But because food levels are maxed and locked, the health will quickly regenerate.
Unfortunately, players who join with a higher health value than the base max health value will have their health capped to the base max health value on the way out of the arena. This was also the case before this commit, but it is worth mentioning again for completeness.
These odd side effects are currently "necessary" because the effects of items that change max health values for players don't take immediate effect in the same tick as they are added/removed, so because MobArena's join sequence is synchronous, we can't feasibly "get it right".
Fixes#545
There is no reason why food should be a thing in the lobby or spectator area. This commit effectively disables it for players in those places/states, while retaining the in-arena conditional logic based on the config-file setting.
Fixes#514
The whitelisting approach works well for the legacy builds, because the
version landscape doesn't change with those. However, the main build on
the master branch will not run on a server version other than 1.13, so
come 1.14, MobArena will be broken.
This commit fixes this problem by changing to a blacklisting approach
for the main build on the master branch. Checking for versions that the
build *can't* run on brings back MobArena's old resilience to version
changes on the Minecraft side of things.
The previous hardcoded value of `20.0` works in most cases, but if a server uses a base health higher than 20, players don't get a full heal. Worse, if the base health is lower than 20, MobArena crashes when it tries to set the health to 20, which is now out of range.
This commit introduces the Attribute enum to MobArena's code base and uses it to get the base value for player max health. This should fix the aforementioned issues.
Fixes#513
Instead of explicitly ALLOW'ing a teleport if a player has the permission, we let the teleport handler logic run its course. If an arena explicitly REJECTs the teleport, we need to cancel the event, but the permission now overrides that behavior. This means that only in the case of an impending event cancellation, the permission kicks in.
This is important, because the permission is supposed to override the decision to cancel, rather than drive the decision to uncancel. With this change, MobArena never uncancels something it wouldn't have uncancelled otherwise, meaning it won't interfere with teleports outside of its own context, and thus won't interfere with other plugins.
Fixes#515, closes#516
Thanks to @minoneer for the bug report and pull request that this code
was based upon!
Spigot is at it again with another breaking change to the API where the
JavaDocs have been retrofitted to match the new, ancient way of writing
software.
The addItem and removeItem methods originally just added or removed
whatever they could when called, and returned a map of items that failed
due to lack of space/items. Now, with the breaking API change, these
methods actually *mutate their arguments* - a practice that has been
heavily discouraged for decades in modern software development, and
something you usually only see in C these days. This change, like many
others in the same vein, show the complete recklessness, incompetence,
and lack of awareness from an otherwise talented team of developers.
Hopefully, they will continue to hone their skills so that we can
eventually have a stable API again.
From a purist standpoint, the flySpeed tag should never be messed with
in MobArena, because simply turning off flight should be enough. It is
likely that the flySpeed tag was originally included to cull "cheaters"
who somehow managed to activate flight in the arena anyway, but this
isn't really MobArena's responsibility and can very probably be handled
by other means of cheat prevention in WorldGuard regions or the like.
By not touching the flySpeed tag, it makes it much easier for server
owners to recover from crashes where the leave steps aren't executed,
leaving players "locked in the air" when they try to fly.
Closes#509 since this "fix" was the reason that feature request was made.
Note that this doesn't make the arguments for commands case insensitive. Each command is still responsible for lowercasing their arguments if it makes sense for them to do so.
This closes#446.
Lowercasing the enchantment string before feeding it to the Bukkit API makes the enchantments a little more "copy/paste proof" when grabbing the uppercased names from the JavaDocs/Minecraft wiki.
Spectating is possible both during and before/after arena sessions. This means that an early return from the entity damage cancellation logic when the arena isn't running is going to allow damage to go through to spectators of non-running arenas, which means they can die. By simply removing the early return (and placing it in the one branch that actually requires it explicitly), spectators should no longer be able to take damage.
This fixes#502.
This changes how unbreakable items work in MobArena. It removes the legacy "repair logic" and replaces it with the item meta unbreakable flag. This approach should work all the same, except now if weapons and armor in class chests have special durability values, these are preserved in the cloning.
This should make MobArena compatible with plugins that depend on special durability values, such as QualityArmory.
This changes how unbreakable items work in MobArena. It removes the legacy "repair logic" and replaces it with the item meta unbreakable flag. This approach should work all the same, except now if weapons and armor in class chests have special durability values, these are preserved in the cloning.
This should make MobArena compatible with plugins that depend on special durability values, such as QualityArmory.
Following the changes in 266104d0a1, this commit gathers the leave-then-join logic and handles it in one fell swoop when joining from the spectator area. This means that the timer will start, and when it runs out, the player leaves the current arena (if any), and then joins.
There should be no issues with overlapping timers or anything like that, since the lookup happens when the time is up, not before the timer is started.
Commit 924a419b47 made it impossible to join an arena from a spectator area because the playerLeave method call in JoinCommand was removed. The call is re-introduced in this commit along with similar logic in InvokesSignAction. This means that a spectating player can now join arenas as if they weren't spectating, rather than having to first leave the arena they are spectating.
This commit changes how MASpawnThread is started. Instead of simply scheduling a task and letting it run whenever, we now explicitly tell it to stop when the arena ends. This matters, because if the scheduled task does not get cancelled, it will run at the scheduled time. MASpawnThread's run() method has an early return to stop whenever the arena isn't running, but with unlucky timing, it's possible to start a new arena session before the task runs again, meaning the same MASpawnThread keeps scheduling itself on the previous scheduling loop.
Instead of this whacky approach, we now specifically have MASpawnThread track its own BukkitTask. Upon arena start, we instantiate a new MASpawnThread and call its start() method, which in turn schedules itself and stores a reference to the associated BukkitTask. Upon arena end, we call the MASpawnThread's stop() method, which explicitly calls the BukkitTask's cancel() method, effectively stopping/unscheduling the task.
This fixes the (very) long-standing "double wave spawner" bug that we haven't been able to reproduce for so long. Hooray!
This setting was removed a long time ago, likely by "happy mistake" in a larger refactoring.
When enabled, players are granted any collected experience during the arena session as a reward when they die or reach the final wave of the arena. Note that deliberately leaving the arena is not included here, because "leaving" an arena is a highly ambiguous and conditional concept at the time of this commit. Figuring out when and how the experience reward should be added is complicated, and unless someone puts in a request for it, I think it's enough that the "legitimate" reasons for getting the experience (honorable death and reaching the final wave) are covered.
Closes#485
It turns out that experience in Minecraft is split out on a couple of different variables, and they are only loosely coupled.
Total experience, level, and level progress are three completely different variables that can be manipulated individually. This means that while 10 experience points from level 0 should bring you up to level 1 with a third of the experience bar full (level 0 to 1 takes 7 points, level 1 to 2 takes 9 points), simply setting the total points value to 10 won't automatically level you up. Using the Player#giveExp(int) method will, however, work this way.
This commit adds a new command, /ma ready (/ma rdy for short), as an alternative to the iron block for readying up after picking a class.
Note that this conflicts with the shorthand for /ma notready, which no longer triggers on the word "ready", but only on "notready".
This commit adds an event handler for the PlayerArmorStandManipulateEvent and cancels it if the arena protection is on, we aren't in edit mode, and the region contains the armor stand. The same logic applies to the armor stand damage event.
This commit re-implements and rearranges a lot of the logic in the main plugin class. It also removes the ConfigCommand class and moves its functionality into the CommandHandler to allow for reloads to be a bit more special than normal commands.
In the refactoring of the main class, the startup logic is broken up into two phases, setup and (re)load:
- In the setup phase, we create the data folder, and the command handler, config serializer(s), plugin integrations, boss abilities, the global event listener, and metrics are initialized. The ArenaMaster is instantiated, but it isn't initialized. These are things that need to be set up just once and don't change on reloads.
- In the (re)load phase, the config-file is loaded from disk, the global messenger is instantiated, the arena master is initialized (loads settings, classes, and arenas), the announcements file is loaded from disk along with the sign data/templates. These are things that we want to be reloadable.
If anything goes wrong during these phases, we store the exception thrown. This puts MobArena into a state where it prints the exception message to anyone who types a non-reload MobArena command to bring attention to the error so it can be fixed.
This commit is a full sweep across the WaveParser. It introduces the ConfigError exception to the WaveParser and throws it whenever something isn't right. There's quite a lot of stuff going on, but in overall:
- Errors are thrown rather than null values being returned
- Defaults are picked in lieu of explicit values when they "make sense"
- Most list-type values can now be either the default comma-separated string or a string list
Common nodes:
- Spawnpoints can now be a string list
Default waves:
- Missing or empty monsters map throws an error
- Missing wave growth defaults to medium
- Invalid wave growth throws an error
Special waves:
- Missing or empty monsters map throws an error
Swarm waves:
- Missing or empty monster node throws an error
- Missing swarm amount defaults to low
- Invalid swarm amount throws an error
Supply waves:
- Missing or empty monsters map throws an error
- Missing or empty drops node throws an error
- Invalid drop throws an error
- Drops can now be a string list
Upgrade waves:
- Missing or empty upgrades map throws an error
Boss waves:
- Missing or empty monster node throws an error
- Missing or empty boss health defaults to medium
- Invalid boss health throws an error
- Invalid ability throws an error
- Invalid drop throws an error
- Abilities and drops can now be string lists
This commit changes how the ThingParser is used throughout the code base. Instead of blindly filtering out null values, we're now throwing a new InvalidThingInputString exception. This exception is caught in an outer scope that has more context. The exception is then unwrapped and rethrown as a ConfigError with the additional context. In the outermost scope of (re)loading the config-file, the ConfigError is caught and printed, and then (re)loading stops gracefully.
We still need a proper way to handle loads/reloads consistently to get rid of the default command usage message, but this is a good step towards better usability in the face of user errors.
Fixes#478
This commit adds a new per-arena setting, join-interrupt-timer, which, when set to a positive number, will introduce a delay to the join and spec commands. During this delay, if the player takes damage or moves more than one block's distance, the command will be interrupted.
Closes#482
This commit adds a new per-arena config-file setting, next-wave-delay. When a new wave is about to spawn, a positive next-wave-delay value will cause the spawning of the wave to be delayed by that amount of seconds, similar to how first-wave-delay delays the spawning of the first wave.
By moving all of the actual spawning logic into a new method and simply referencing that as a Runnable, we can avoid having to set weird boolean flags and re-scheduling the MASpawnThread itself.
Closes#449
The autogenerated arenas are backed up in a file that isn't valid in 1.13. It's also buggy, inducing a false sense of safety. Instead of trying to hack it together for 1.13, let's remove it and see if we can't live without it.
This semi-reverts part of the change in e484583b7e.
We're now specifically denying the use of items if there are any. This doesn't cancel the interact event, but just prevents stuff like potion consumption.
The block fade event is called when a block fades from one state to another, such as when snow melts and becomes air, or ice melts and becomes water. Cancelling it solves the issue of snow and ice melting in arenas.
Fixes#249.
Originally, the right click ban was introduced to prevent issues with people blowing themselves and each other up in the lobby. The right click ban only solves this issue sometimes, so it isn't really very effective.
By removing the right click ban, it becomes possible to activate redstone stuff like buttons and levers in the lobby.
Fixes#431.
The flag is almost always set to true, and when it isn't, it's either because people don't know that they have to set it, or because they only give one upgrade per class and thus don't feel the effect of it.
This is not the proper way to solve this issue, but the refactoring needed to move the responsibility of class chest search somewhere else is a bit too much for a bug hunt.
This introduces state in the ScoreboardManager for keeping track of the scoreboards that players have before the arena session starts, if any. Upon leaving, the scoreboards are restored.
Ideally, this change should be re-implemented as a Step of the join/leave process, but that would require opening up Arena or ScoreboardManager in ways that would probably be best handled in a rewrite of the scoreboards, so we'll leave it in ScoreboardManager for now.
Fixes#366
A new section in global-settings called pet-items is used to define pet item transformation items. By default, bones are transformed into wolves, but the item type can now be changed to support using actual bones in classes.
This refactors the pet spawning into its own class to reduce some of the massive responsibility of ArenaImpl.
This closes#467
In this commit, the ItemParser's behavior changes from one that requires or encourages numeric IDs for everything to one that discourages it by logging a warning that suggests using a string instead of a numeric value.
While this doesn't actually make things that much better for updating to Minecraft 1.13, the "ID nagging" hopefully increases awareness about the upcoming breaking changes.
Fixes#382
This follows from the removal of the set class command being removed and the cascading removal of the methods in ArenaMasterImpl that referenced the parseString methods in ItemParser.
Similar to a88556771f.
This specific change may stir the pot a bit, since some people may rely on the set command. However, class chests solve a lot of the problems that the initial command set out to tackle, and we can probably do better in a rewrite of the command if it's missed anyway.
The removed commands render a few methods in ArenaMaster obsolete.
These commands solve a very, very specific problem that it's safe to assume nobody has. It's safe to assume that most config editing happens in the actual config-file, and changing class permissions is probably one of the last things people would expect to find a command for.
Removing these commands renders some methods in ArenaMaster and ArenaClass obsolete.
Instead of the obscure error thrown from ArenaClass when the SHIELD enum value on Material isn't found, MobArena throws its own, more human-friendly error.
Fixes#469
When the arena ends, the MonsterManager is cleared, which means that all references to health bars are lost. Before this, we remove all players from any boss bars to make sure that the boss bars don't stick to players upon dying.
Fixes#473
This changes the upgrade waves from the local Upgrade interface to the Thing interface. This means that all Things can now be used in upgrade waves, including commands, money, potion effects, and permissions.
Unfortunately, the weapons upgrade/replace functionality has been gutted as a result of the Things API not supporting it. We could add it back in later down the road, but for now let's just see if it causes anyone any inconvenience.
Closes#468
This replaces the Map<String, Boolean> approach in ArenaClass with a List<Thing> approach. This greatly simplifies how per-class permissions are handled.
This commit introduces the PermissionThing and associated parser. The parser determines the value (grant/revoke) of the permission by looking at the first character of the input string - if it is a minus (-) or caret (^), the value is false (revoke), otherwise it is true (grant). To distinguish permissions from other things, the parser requires a prefix of "perm:".
This removes the map of attachments in ArenaImpl and makes the permissions "replacement" happen via the Bukkit API's PermissionAttachmentInfo. Bukkit already keeps track of which attachments we've added to a player, so removing them is just a matter of looping through and finding those. This reduces the coupling between the Arena interface and UpgradeWave (which is the only interface that used the methods removed from the Arena interface).
The goal with these specific metrics is to figure out if some of the arena settings can be removed. If everyone uses the same values for these settings, there is no point in having the added complexity in the code.
Three different types of health bars are implemented behind a basic Strategy Pattern. A new per-arena setting, boss-health-bar, can be used to configure which one of the three types (if any) of health bar should be used for bosses in the given arena:
- `boss-bar` creates a boss bar at the top of the screen as if the players were fighting an ender dragon or a wither.
- `title` uses the Chapters/Titles API in Bukkit to display the health of the boss as a "subtitle" whenever it takes damage.
- `name` sets the entitiy's health along with an optional custom name above the entity's head.
