Automated island ownership transfer in case of inactivity

[Poslovitch]

Taken from #109.

Add an option so if the leader of a team doesn't log in the server for X configurable amount of time (For example: 3 months), the island leadership would go to other team member.

@tastybento Would it be better to transfer the ownership to the oldest member of the island or to the "most" active (connected the most recently) one ?

[Poslovitch]

I just remembered we did some kind of surveys nearly half a year ago on the discord server about this feature request, and these were the results:

So, what I'll do is the following:

• Add a config option (global for now) to toggle this feature (this might not be wanted by all server owners)
• Add a config option (global as well) to define the threshold above which the change of ownership must be carried out
• Do the inactivity checks once an island member logs in (rank >= member)
• All members (including the owner) that are above the threshold are excluded from being recipient of the automated ownership transfer. If there is no members left (which is theoretically impossible, but better be thoughtful), the transfer is aborted.
• Add a config option to define whether ranks should be taken into account when choosing the new owner (this means if A is a SUB_OWNER, they will be prefered to B (MEMBER), even if B's been the longest time)
• The ownership is transfered to the player who's been member the longest time (and/or, according to the option above, to the best ranked island member)
• Log the ownership transfer.

[Poslovitch]

It seems there is currently no way to know from how many time a player is member on an island... I might need to work on the island history first then...

[Poslovitch]

Postponed for now - it needs to fully implement the "island logs" and to ensure they are reliable enough.

[Poslovitch]

Okay, so I've worked on this a bit (got the help of a few classmates).

We raised the following points:

• Configurable "grace period" before the change comes into effect (basically: it tells all the island members who are connecting that if the owner doesn't reconnect in the meantime, the island ownership will be transferred to player X).
• It makes more sense to pick the new owner in the highest-ranked members first. The option to toggle "include ranks" should be removed right away.
• The algorithm will pick the highest-ranked player who has been member on the island for the longest time. Yet, if that player has not been "active" enough recently, then he is discarded.

About "being member for the longest time"...

Here lies the tricky part of this feature request.

We need to do changes to the Island class. More specifically, we have the need for a subclass: Island.Member.

Island.Member
--- Fields ---
- uuid: UUID
- rank: Integer
- joinTimestamp: Long
- arrivalOrder: Integer
--- Methods ---
+ getters

This will require the adaptation of some methods in the Island class, but that hopefully won't cause any breakage of the API.

However, @tastybento, will the database code support such a twist? Indeed, the implementation of the "members" list for the Island object will change drastically: Map<UUID, Integer> members to List<Island.Member> members. Moreover: banned players will need to be handled in their own list, since they'd not fall in the scope of this object.

Would that be possible?

[tastybento]

It could probably store in every database except YAML because we're using GSON serializing and the field are generic, but it will break all current installations unless you write conversion code into the class. That would have to stick around for a very long time just in case someone was late in upgrading.

However, I would recommend you try to develop something simpler. This feature is there to make admins lives easier so that motivated players don't bug them for a manual transfer. How about this:

1. When a member of an island logs in, do a last login check on the owner. (Bukkit.getPlayer(uuid).getLastPlayed();)
2. If the owner has not logged in for longer than X days (as defined in the config.yml) and the member is at or above the handover rank given in config.yml, e.g., SUB_OWNER or MEMBER, then give the member the chance to claim the island, e.g, via typing 'accept' into chat.
3. If they accept, they get the island.

In this approach, you don't need to change or store any data in the Island object. It's all done via the server API and it's just simple to understand. Admins can pick what rank they want. If they want a really quiet life, they set it as MEMBER. I would set it there.

It will require two additions to WorldSettings - handover rank and abandonment time. In this regards, I'd like to propose that all new additions to WorldSettings go in as default methods and not abstract methods. That way, GameModeAddons can have a choice as to whether they will override them or not and current versions will not break by this being added. For example, in the case of SkyGrid, I don't see a need to ever need to have this, so I'd prefer it to just default to never. But in BSkyBlock, it'll be a useful addition.