Make KickPlayerEvent cancellable

[ImMorpheus]

Fix #2178

[Zidane]

@ImMorpheus

This can target 7.

[ImMorpheus]

The event is not implemented on stable-7.

[dualspiral]

With regards to 7: #2178 (comment) - this needs to be thought about when it's done.

With regards to 8: remove the MessageChannelEvent implementation (or whatever the adventure equivalent is/will be). I do not see the use of having an audience attached to the method.

[ImMorpheus]

Done

EDIT: while it's true channels are not used we still use the message of MessageEvent.

[dualspiral]

while it's true channels are not used we still use the message of MessageEvent.

Add it on manually, don't keep an interface on if you don't use all of the elements of it.

[ImMorpheus]

Add it on manually, don't keep an interface on if you don't use all of the elements of it.

They are two different events.

MessageChannelEvent != MessageEvent

KickPlayerEvent makes full use of the latter

[dualspiral]

Also, while we're at it, make Player#kick return a boolean, because if a kick is cancelled, a comsumer of the event should be notified of it. This also needs an implementation update, so that needs doing in Common too.

[dualspiral]

KickPlayerEvent makes full use of the latter

No it doesn't - these are not used.

[ImMorpheus]

No it doesn't - these are not used.

True, KickPlayerEvent#isMessageCancelled is not used but shouldn't it be ?

ServerSideConnectionEvent.Auth and ServerSideConnectionEvent.Login are the same (both are MessageEvent whose message refers to the "disconnect message").
If the message is cancelled then the default disconnect.disconnected message is used.
Why shouldn't the same apply to KickPlayerEvent ?

[dualspiral]

If the message is cancelled then the default disconnect.disconnected message is used.

I'd rather that was ditched entirely - cancelling a message doesn't make sense in that scenario (all it's doing is basically using the original message instead). The message event should just be original/get/set if you ask me - then it's totally appropriate to put here.

[ImMorpheus]

I'd rather that was ditched entirely - cancelling a message doesn't make sense in that scenario (all it's doing is basically using the original message instead)

Done

The message event should just be original/get/set if you ask me - then it's totally appropriate to put here.

Done and added a separate interface to mark the event as "message cancellable" (just like Event and Cancellable).