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, along with a (currently not committed) script to generate github releases and Spigot/DBO formatted release notes from this changelog, should reduce some of the friction associated with new releases.
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.
