Integration Update!

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!

Grief Prevention Update!

Hi All,

This release does the following on top of v3.2.2:

• Grief Prevention v16.x is now supported.

NOTE: With this update, Grief Prevention v15.x is no longer supported, so please update accordingly!

GriefPrevention Integration Update!

This release fixes the following on top of v3.2.1

• Grief Prevention Integration has been updated to support Grief Prevention v15.x.

NOTE: Grief Prevention v14.x is no longer supported as of this update.

Bugfix for manual regeneration being cancelled!

This release fixes the following on top of v3.2.0:

• Manual regeneration commands said they succeeded to regenerate claimed chunks, but this was cancelled in the background and didn't happen.

Crashbug fixes and RedProtect 6.6+ Support!

This release does the following on top of v3.1.9:

• Chunk caching being disabled (the default setting) broke new installs of Regenerator 3.1.9. This has been resolved by populating the 'chunk database' for Regenerator with the spawn chunk for each world when the world is loaded.. to ensure the database is never empty.
• With v3.2.0 of Regenerator, RedProtect 6.6.x is now supported. 6.5.x support has been discontinued. Please update!

Teleportation should be instantaneous!

This release does the following on top of v3.1.8:

• Caching is now turned off by default by using the global cacheChunksOnLoad config setting. This is because this feature is not very useful for larger maps - every time a chunk is cached it needs to open the worlds chunk database which can be large on 50k border worlds!

Manual Regeneration now bypasses some configuration settings

This release does the following on top of v3.1.7:

• Manual regen is no longer respects the regenerateChunksInUseByPlayers configuration flag, as if it is set to false it means that regeneration cannot occur manually.
• Manual regen no longer respects the distanceNearbyMinimum configuration flag, as it assumes at least one player is in the chunk being regenerated.
• Manual regen no longer respects the targetLoadedChunks or targetUnloadedChunks configuration flags, as all chunks that will be regenerated manually will be loaded.
• Manual regen no longer respects the WarpDrive compatibility flag, as it should be up to server admins to ensure that players can not regen manually in unclaimed land unless they are trusted.