This is a bit of a specific request, so I'll provide background information as to why I'm making the request.

I use many plugins that add new abilities - some of these abilities can "change" blocks when you interact with it. For example, I use MonsterBox which lets you change a mob spawner by right clicking it with the appropriate spawn egg. However, anyone who has access to this ability can change a mob spawner even if it's protected via LWC/Residences. This is just one of the many examples I can offer.

A big reason as to why plugins don't support protection plugins very well (and often bypass them), is because it's too much of a work to hook into every protection plugin. Passing a "BlockBreakEvent" may not be a satisfactory solution either. There's no Vault-like system for protection plugins (while there is Shield "http://dev.bukkit.org/bukkit-plugins/shieldapi/", it's outdated and too big of a job for one developer).

So, with OtherDrops already being flexible and powerful, I was thinking it could be turned into a rudimentary "protection plugin". By adding a parameter (dependent on LWC) that can check whether the block is protected by LWC, one could cancel even plugin events (without using the "DENY" parameter), and not have to worry too much about this hassle. Here's how it would work.

There will be a new condition-type parameter named "LWC: ", and the value could be set to "private" or "public".
IF "LWC: private" is specified, it becomes a necessary condition that the block is checked for a private protection, and that if there is one, the doer and the owner match up. If there is no protection, or a non-private LWC protection, the event DOES occur; it is not blocked. If the person interacting with the LWC-protected block is not the same person as the owner of that protection, the event is entirely blocked. If the interactor and owner are the same, the event is allowed to pass.

Basically, ignore any block that's not "cprivate" protected, and block all intruders.

If "LWC: public" is specified, the block must be protected under "cpublic" in order for the event to PASS. If the block is protected with a different type of protection, or is not protected at all, the event is canceled.

There could be more values, but more can always be added later on. And the effects of "private" and "public" are a bit specific, but I think that's the most intuitive way they would work.

IN A NUTSHELL: This is basically like a "drop: DENY" for LWC-protected blocks. I don't know if "drop: DENY" cancels all events including plugin-induced events, but if it doesn't, it should be "more aggressive" so as to do that.

Unfortunately this isn't something that OtherDrops can fix. It's an issue
of priorities. Bukkit is designed such that plugins at a lower priority
run first therefore having a chance to cancel an event. Higher priority
plugins will then be able to see this event as cancelled.

I've seen some protection plugins use priority "highest" which means no
other plugin can be higher and see any cancelled events. I thought this
might be the case here but I checked LWC - it listens to the player
interact event at "normal" priority. Unfortunately Monster Box also
listens at normal priority which means it's likely monster box runs before
LWC can cancel the event. If you can get monster box to listen to player
interact events at high or highest priority it should work fine (you should
check what level residences listens to player interact first).

OtherDrops by necessity runs at "highest"priority so that an protection
plugins will have had a chance to cancel the event before it gets to
OtherDrops (unless the protection plugin also uses highest and then you
can't tell which would run first).
On Jan 15, 2014 6:37 AM, "CommodoreAlpha" [email protected] wrote:

This is a bit of a specific request, so I'll provide background
information as to why I'm making the request.

I use many plugins that add new abilities - some of these abilities can
"change" blocks when you interact with it. For example, I use MonsterBox
which lets you change a mob spawner by right clicking it with the
appropriate spawn egg. However, anyone who has access to this ability can
change a mob spawner even if it's protected via LWC/Residences. This is
just one of the many examples I can offer.

A big reason as to why plugins don't support protection plugins very well
(and often bypass them), is because it's too much of a work to hook into
every protection plugin. Passing a "BlockBreakEvent" may not be a
satisfactory solution either. There's no Vault-like system for protection
plugins (while there is Shield "
http://dev.bukkit.org/bukkit-plugins/shieldapi/", it's outdated and too
big of a job for one developer).

So, with OtherDrops already being flexible and powerful, I was thinking it
could be turned into a rudimentary "protection plugin". By adding a
parameter (dependent on LWC) that can check whether the block is protected
by LWC, one could cancel even plugin events (without using the "DENY"
parameter), and not have to worry too much about this hassle. Here's how it
would work.

There will be a new condition-type parameter named "LWC: ", and the value
could be set to "private" or "public".
IF "LWC: private" is specified, it becomes a necessary condition that the
block is checked for a private protection, and that if there is one, the
doer and the owner match up. If there is no protection, or a non-private
LWC protection, the event DOES occur; it is not blocked. If the person
interacting with the LWC-protected block is not the same person as the
owner of that protection, the event is entirely blocked. If the interactor
and owner are the same, the event is allowed to pass.

Basically, ignore any block that's not "cprivate" protected, and block all
intruders.

If "LWC: public" is specified, the block must be protected under "cpublic"
in order for the event to PASS. If the block is protected with a different
type of protection, or is not protected at all, the event is canceled.

There could be more values, but more can always be added later on. And the
effects of "private" and "public" are a bit specific, but I think that's
the most intuitive way they would work.

IN A NUTSHELL: This is basically like a "drop: DENY" for LWC-protected
blocks. I don't know if "drop: DENY" cancels all events including
plugin-induced events, but if it doesn't, it should be "more aggressive" so
as to do that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/306
.

Ah, gotcha. I now feel more enlightened on how events and priorities work. :)

If you feel like closing this ticket, then by all means go ahead.