Disable beacon buffs - especially regeneration

[DeathDragonAW]

Feature request

Short description

There should be an option to disable beacon buffs (e.g. regeneration) for mobarenas.

Implementation details

For me it would be OK to disable it completely for all mobarenas, maybe some ppl would like to have an per-arena setting.

Additional info

I'm allowing all players on my server to build their own arena and now they are starting to use beacons near the arenas which affects the balance of drops.

[garbagemule]

Thanks for the feature request.

I had a quick look through the Bukkit API and the googles, and I can't seem to find a way to find the source of a potion effect on a player. There might not be a clean way to disable beacon buffs in general, so we might have to resort to dirty hacks, and over the years I have become highly allergic to those.

I'm gonna leave the issue open in case anyone else has any experience with this stuff, but if not, we'll have to close it.

I suggest looking for workarounds. Perhaps you could make arenas and beacons mutually exclusive with WorldGuard regions somehow. If nothing else, you could make a dedicated arena world and just deny beacon building in it.

[slipcor]

It is hidden under the EntityPotionEffectEvent, it has a cause. See here:

https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/event/entity/EntityPotionEffectEvent.Cause.html

Question now is, how will this be implemented, do we allow to block multiple of these, all of these, only the beacon? ^^

[garbagemule]

@slipcor Sweet, thanks!

Assuming the existing join process properly clears beacon buffs along with other potion effects, it should be quite simple to add a hook for EntityPotionEffectEvent and then just cancel all events with BEACON as the cause if the entity in question is a player in the lobby or arena.

But isn't this better handled by plugins like WorldGuard? I can't tell if this fits properly inside MobArena's isolation paradigm, or if it is a slippery slope kind of thing. I suppose the opposing schools of thought are these:

• "I want my arenas to be strictly isolated from the world." This is the classic/intended behavior of MobArena as a minigame. The only thing that really should cross the border between the rest of the server and MobArena are the rewards. Everything else is reset and restored.
• "I want my arenas to be an integrated part of the server." This is the emerging "neo-behavior" we're seeing with features like My Items, where people want arenas to act more like dungeons than a minigame. It's not hard to imagine beacons playing an important part in an "integrated" setup, perhaps even one that encourages players to prepare "outside" before they join.

This is beginning to smell a lot like Sessions Rework stuff, so I'm going to add the tag for good measure. I'm beginning to see a hazy outline of a config section dedicated to integration/isolation stuff, but that's future stuff.

If we do implement this, I think it would be best to start off with a per-arena toggle (no fine-grained control over specific buffs or levels or anything like that). But is WorldGuard a better fit? Thoughts?

[slipcor]

Looking through the other causes, I think they do not really break the arena-bounds like the beacon can do, so I don't see a slippery slope there. However, further configuration of the allowed beacons would be very weird in my opinion.

If you want to allow in-arena beacons but you place the arena in an accessible world, this becomes slippery then. What do you allow and what happens when someone places a beacon of the type that you allow in the arena, but outside? Would MobArena have to listen to beacon-create events and cancel them if they overlap with the arena? Because with this event that I provided, there is no information about where the beacon the effect originates from is located.

I feel like this is easier fixed with worldguard [placement of beacon] for isolation. If there is a big rework with a dedicated config section and plugin class managing the isolation, this might be easier to revisit then.