Extend PlayerChestAccessEvent

The current implementation lacks an access state. Namely, plugins know when a chest is accessed (opened), but not when the chest is closed. Therefore, I propose extending this event with a simple flag

public class PlayerChestAccessEvent extends PlayerObjectEvent implements Cancellable {


    boolean cancelled;


    public PlayerChestAccessEvent(Player player, commons.objects.ObjectElement object) { }


    public PlayerChestAccessEvent(Player player, short objectid, byte variation, int cx, int cy, int cz, short px, short py, short pz, short rx, short ry, short rz, int info, byte status) { }


    public int getChestID() { }


    public boolean isChestOpen() { }


    public boolean isCancelled() {  }


    public void setCancelled(boolean cancel) { }
}

The new method isChestOpen() would return a boolean true or false whether the player opens or close the chest. Current script would need to check this flag to make sure that any logic is not executed twice, potentially breaking some internal state. I do not believe that an extra event is necessary, and the potential breaking change is a reasonable risk since it shouldn't affect too many plugins, and those can even benefit from this flag at the same time.

Rationale

There is no way to detect when a player close a chest.

Quote from red51

That makes sense Although I'm not sure if adding a separate event might be favorable eventually... since the PlayerChestAccessEvent is cancellable, closing a chest must also be cancellable (if it's handled by the same event).

I tried to counter that argument, and I cannot find a solid objection. Because a player can simply disconnect from the server, and reconnect to go around any cancellation. Then again, if a plugin is well coded, this shouldn't be a problem, and being able to cancel closing a chest could be a good way to implement a confirmation method (given that closing a chest can programmatically be executed). For example, prevent users from closing a chest if not all items have been transferred to inventory. Or, for example, dropping items and receiving credits after closing the chest. Or, for example, a script that will automatically empty chests and transport items elsewhere when it is closed (no need for players to mule the inventory manually). Etc.

If closing a chest can be cancelled, of course players can disconnect, and reconnect, but if the logic and states are properly managed, this can be done in a way that is unfavorable to the players.