Closed mfnalex closed 4 years ago
I think a better solution is to check if the actual class of the event is a PlayerInteractEvent so that all subclasses are ignored - adding specific dependencies is a rabbit hole I really do not want to go down - but yeah, that sounds good. The only other alternative is for you to manually fire the PlayerInteractEvent and not check event handlers listening on monitor.
Please see my PR, it doesnt add any dependencies at all
Yeah, it's a solution, but special casing specific plugins is not a great way to go. Generates a lot more maintenance work in the end.
Although it's just a small string comparison, that might be true. It would be nice if there would be any solution, because I already got several requests why InvUnload doesn't work and my first response is always "Do you use OpenInv?" ^^
I have to rely on the check with the PlayerInteractEvent to support every protection plugin available. I have not yet encountered other plugins cancelling that event without wanting to block access to the chest at the same time, so I would be very happy if we could find a solution :)
Spartan for example has an API method that lets a plugin cancel the cancellation of that event, maybe that would be an option?
See at the bottom of this page at Developer API: https://www.spigotmc.org/resources/spartan-advanced-anti-cheat-hack-blocker.25638/ ( https://pastebin.com/raw/PH63gHRg (yes, their API docs are a pastebin file.....) )
Like I said, just class comparison.
if (!PlayerInteractEvent.class.equals(event.getClass()) {
return;
}
Oh, I must have missed that in your first reply. Of course, that would be awesome!
Hi, I am the author of InvUnload. Some users reported that the /unload command of my plugin does not work when they have /anychest or /silentcontainer enabled, which has the following reason:
InvUnload calls a PlayerInteractEvent to check if a player may use a chest. Unfortunately, that event is then cancelled by OpenInv.
I might create a subclass of the PlayerInteractEvent, so that InvUnload will call that one instead. You could then just check if the PlayerInteractEvent is actually my custom event, and if yes, don't cancel it.
Would this be a viable solution?