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.
* Update Commands documentation (see full commit)
This commit updates the Commands documentation.
* Follows RST document style guide
* Uses active voice / minor edits
* Reorganize structure, use tables
* Address feedback by @garbagemule in #413
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!
