Skip to content

Integration Update!

Latest
Latest
Compare
Choose a tag to compare
@StargateMC StargateMC released this 24 Jun 01:40
· 56 commits to master since this release
3.3.0
1931cb5

Hi All,

Release Summary - For all Regenerator Users

This release is primarily directed at moving away from the integrations that Regenerator has required in the past, requiring work to be completed per-plugin to enable support, while having that support breaking with every major release of the integrated plugin.

Instead of integrating with plugins, Regenerator will present events and API methods to allow for protection plugin developers to easily integrate Regenerator within a few minutes.

All existing integrations will function as normal and will take precedence over any event listeners that plugin developers create until v4.0.0, when I will be removing the integration system entirely.

Don't worry, for the plugins which I have created integrations for I will make an 'addon' plugin for Regenerator to perform the same task.. if the plugin author isn't willing to pick up support for Regenerator - but this should eventually be merged into the protection plugin's codebase.

This release is intended as a way for developers to have time to adjust to how Regenerator v4.0 will work!

Technical Summary - For Developers and Server Admins

  • Plugins may now request regeneration, by firing a RegenerationRequestEvent which will then be actioned provided it does not conflict with the old integration system (integrations still take precedence until v4.0 when they will be removed).

  • All Regeneration Queueing is now done through the event system, allowing for plugins to listen for anything that triggers regeneration via Regenerator, including when a player does this via commands or another plugin asks to regenerate a chunk. This can be cancelled and occurs at the time a chunk is requested to be regenerated.

  • All actioning of chunk regeneration will be done through the new event system, through a Regenerator fired, RegenerationActionEvent. This can be cancelled and occurs at the time a chunk is regenerated.

Note: RegenerationActionEvent should not be called by other plugins, and will not cause regenerator to regenerate a chunk if this is done. Please fire RegenerationRequestEvent instead!

Technical Details - For Developers

RegenerationRequestEvent supports the following methods:

  • getTrigger() - This returns the trigger for the request, be it a Break or place event, a player running a command or another plugin (See the com.draksterau.Regenerator.event.RequestTrigger enum for details).
  • isImmediate() - This returns if the chunk is to be immediately regenerated. This has no effect on command triggered requests, which are always immediate.
  • setIsImmediate(boolean) - This allows a developer's event listener to either set or unset the isImmediate flag, causing for the event to be queued in Regenerator instead of happening immediately or vice versa.

Note: Command triggered Regeneration Requests are always immediate and the immediate flag has no effect.

  • getPluginRequestor() - This returns the JavaPlugin of the plugin requesting the regeneration to happen. This will quite often be Regenerator, but could be any plugin which is integrating with Regenerator.
  • getRequestor() - All Requests will have a player reference. This will be the player that triggered the request, be it by breaking or placing blocks, running a command or something else created by another plugin.
  • getChunk() - This returns the chunk the request is occurring for.
  • getWorld() - This returns the world in which the chunk affected exists.
  • getBlock() - This returns the block at the location that triggered the request. This is helpful for region based plugins!
  • getLocation() - This gets the Bukkit Location for the trigger of the request. This is helpful for region based plugins!
  • getCancelledReasons() - This returns as HashMap of reason & plugin for all plugins that are listening in on this event that have already been processed.
  • clearCancellations() - This method clears both the cancelled flag for the request and all reasons associated with that cancellation, effectively overriding all other plugins to allow this request through (though it can be overridden by a higher priority event listener).
  • cancelWithReason(String, JavaPlugin) - This method will cancel the event if it is not already cancelled and also add a reason the list of reasons why the event was cancelled. This will be returned to the player, so word it well!

RegenerationActionEvent supports the following methods:

  • getChunk() - This returns the chunk the request is occurring for.
  • getWorld() - This returns the world in which the chunk affected exists.
  • getBlock() - This returns the block at the location that triggered the request. This is helpful for region based plugins!
  • getLocation() - This gets the Bukkit Location for the trigger of the request. This is helpful for region based plugins!
  • getCancelledReasons() - This returns as HashMap of reason & plugin for all plugins that are listening in on this event that have already been processed.
  • clearCancellations() - This method clears both the cancelled flag for the request and all reasons associated with that cancellation, effectively overriding all other plugins to allow this request through (though it can be overridden by a higher priority event listener).
  • cancelWithReason(String, JavaPlugin) - This method will cancel the event if it is not already cancelled and also add a reason the list of reasons why the event was cancelled. This will be logged to console by Regenerator, so it should be understandable to Server Admins!

Important Note

Until the SQL support is introduced with v4.0.0 and Regenerator can store the triggering block coordinates, getBlock() and getLocation() will return the block at chunkX,0,chunkZ at all times. This should not be relied on by region based plugin authors for RegenerationActionEvent!

Assets 3
Loading