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
Andreas Troelsen