Very likely I was going to refactor this class, but then stopped since
it's abstract and thus can't have any constructor... but apparently I
forgot to revert that line.
Closes#377
If a player logs out then logs back in, and the task in the
PlayerJoinEvent rescues him first and the player has sat in the rescue
location for over 10 ticks (which should be within another portal), then
this task will also attempt to rescue the player. Because it was using
metadata in the log message though, it failed but also printed a
stacktrace since the player's metadata was already removed.
- Claim expiration collects all players (uuids) that own claims, and
iterates this set instead of iterating through every single claim.
- Individual claims had a "last modified" timestamp, so this method was
valid before, but makes no sense now since expiration is based on player
inactivity instead of claim inactivity.
New config option under the advanced node allows controlling the
frequency each player in the aforementioned set is checked for
inactivity.
1. Claim creation event... this is fired once all the claim creation checks have been passed. It can be cancelled. It contains the claim and the creating player
2. Claim modification event - this is fired as the claim is modified - it cannot be cancelled. It contains the claim and the modifier...which can be null.
Use Case:
This could be used so other plugins can hook gp and perform an action if a claim is created or changed. Something as simple as logging claim creations/modifications and deletions.
