feat: add region lifecycle events (add, delete, redefine, flag, membe… - #2299
feat: add region lifecycle events (add, delete, redefine, flag, membe…#22991wairesd wants to merge 1 commit into
Conversation
…r, priority) Add six cancellable Bukkit events that fire before key region operations, allowing third-party plugins to intercept and cancel them cleanly without resorting to reflection hacks or command interception. New events in worldguard-bukkit/.../event/region/: - RegionAddEvent - fired before /rg define - RegionDeleteEvent - fired before /rg remove - RegionRedefineEvent - fired before /rg redefine - RegionFlagChangeEvent - fired before /rg flag (set or clear) - RegionMemberChangeEvent - fired before addmember/addowner/removemember/removeowner (async) - RegionPriorityChangeEvent - fired before /rg setpriority All events carry: - World - the world the region belongs to - ProtectedRegion - the affected region - CommandSender (nullable) - the actor who triggered the operation, or null for API calls - setCancelled(true) - cancels the operation - setCancelMessage(String) - optional custom feedback message Architecture: - Six default methods added to WorldGuardPlatform (return true by default, so no existing platform implementations break) - BukkitWorldGuardPlatform overrides all six, adapts WE World to Bukkit World, fires the event via Bukkit.getPluginManager().callEvent() - RegionCommands wired for define/redefine/remove/flag/setPriority - MemberCommands wired for addMember/addOwner/removeMember/removeOwner; success message is only sent when the event is not cancelled This eliminates the need for plugins to use reflection into RegionManager internals or intercept raw commands in order to protect regions from deletion.
|
That implementation is only called when region manipulation is done by commands. Such an implementation should cover that. Unfortunately the API currently doesn't provide feedback whether changes were successful so there is no good way of implementation without breaking changes. |
Yeah that's a fair point. I was thinking about a few ways to handle this: Fire events directly from RegionManager methods, cancellation would return emptySet() instead of null (which still means "not found"). Not a breaking change technically, but the empty set semantics could be confusing. Add new methods like removeRegionChecked() that return a result object with success/cancelled state, and deprecate the old ones. Binary compatible, cleaner API. Just keep it as command-level events with clear javadoc saying "these only cover command-initiated operations". Covers most real use cases without touching the API contract at all. I'm fine with implementing whichever approach works best for you. Or if this is something you'd rather defer to a bigger API rework, I get that too, just let me know. |
2 participants
…r, priority)
Add six cancellable Bukkit events that fire before key region operations, allowing third-party plugins to intercept and cancel them cleanly without resorting to reflection hacks or command interception.
New events in worldguard-bukkit/.../event/region/:
All events carry:
Architecture:
This eliminates the need for plugins to use reflection into RegionManager internals or intercept raw commands in order to protect regions from deletion.