Zarius
commented
10 years ago 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" notifications@github.com 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/Zarius/Bukkit-OtherBlocks/issues/306 .
stvncao5
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.