Hi any example on how to make something activate a listener event to do things only when command is set to 1 and not if 0? do I always have to listen and just not act?
No, listeners cannot be activated and deactivated at will. In your command, set a variable; then, in your listener, check the variable.
1 Like
Pretty sure they can, because that’s what I do in Nucleus.
@Technium_Unlimited If you have the listener to activate/deactivate in its own class, keep a reference to the listener in your command, maybe use a boolean to check to see if you’ve registered it, then use Sponge.getEventManager().unregisterListeners(ListenerClass) and Sponge.getEventManager().registerListeners(Plugin, ListenerClass)
That said, you can just leave it activated and use a boolean, like @pie_flavor said - probably much simpler. It’s wrong to suggest you can’t deactivate a listener though.
1 Like
I meant individual methods. You can definitely register and deregister listeners, though there’s a performance overhead for doing so.
Actually, you can, if you wrap a call to the method in an EventListener<T> class. Sure, it’s not the preferred way of doing it, and you lose the benefit of event filters, though I have been investigating such use for performance reasons - it can certainly be done, that’s what that method is designed for. However, for the OPs purpose, this isn’t something I’d recommend they do.
And there is a performance overhead for leaving a listener registered doing a boolean check. In fact, there is a performance overhead from just calling an event. At some point, I’m sure the loss from doing things one way will overtake the other, if you consider an event could be called thousands of times and registration/deregistration only a handful of times. Calling an event listener is fairly involved, especially if there are event filters on it. Yes, so is creating an event listener (especially because a class is created using ASM to call the listener), but I don’t imagine that this task would be done anywhere near as many times as actually potentially calling the handler.
The question becomes, do you take the one time hit of registering/unregistering, or do you take a constant performance hit from the listener being fired needlessly? For some events, like the displacement events, disabling the listener seems like a great idea if it’s not in use given how many times it can fire per second on a mid sized server, worse on a large server. Other events, such as the disconnection events, might not see such a benefit from being disabled.
I’d love to see some numbers on this, but overall, the performance hit in both cases are two different beasts, small hit per tick vs a larger hit in one tick. Maybe I’ll write a benchmark if I can be bothered. That being said, when I reload my many conditional listeners in Nucleus, I only see a small hit, on the order of a tick or so, if that - considering that only happens on a reload event and allows me to keep absolutely useless listeners disabled, freeing time up for other plugins, it’s a price worth paying, if you ask me.
If it was constantly going to be turned on or off, I would have stuck with a boolean check. It’s unclear to me from @Technium_Unlimited’s case what he’s trying to do, so maybe a boolean check is better, but I’d stop short as to argue that it’s a bad idea to register/unregister listeners in the right scenario.