Honeypot 5.0.1 (HOTFIX)

Honeypot 5.0.0 apparently introduced a bug in a database migration that caused Honeypot to basically never be able to work unless it was already set up, which isn't possible without running it. It was a catch-22. This update fixes that bug, ensures database migrations are executed prior to tables being created (which is what caused the bug in the first place), and fixes an unrelated bug regarding InventoryDragEvent causing stack traces to get thrown when dragging within any double chest.

IMPORTANT: Any server that never used Honeypot before and ran Honeypot 5 for the first time will need to delete their honeypot.db from their plugin folder!

Honeypot 5.0.0

After several months, Honeypot 5 is releasing today and brings a huge change to Honeypot as you know it: Honeypot Regions.

Since Honeypot 3.4.0, when R*-tree was implemented for spatial indexing, Honeypot has, in theory, always been able to store regions. In fact, technically speaking, it did store regions, but each region was a 1x1x1 space. Now, Honeypot can create regions of any size, and all blocks within that region act as if they are Honeypot blocks. Pistons can't push or pull, water can't flow into the region, block breaks and places are impossible, TNT can't explode, etc., just like a normal Honeypot. /honeypot locate will highlight regions with a cyan particle effect! (Note, the particles are much brighter without shaders on. My shaders remove the brightness of particles for some reason)

As well, the /honeypot history command has been improved to become a GUI, allowing server staff to review an player's entire history, rather than however many most recent records, as configured within config.

As something for server owners to look forward to, in Honeypot 5.1.0, the blocks-broken-before-action-taken config will be rewritten to support different types of actions, and will be applied across all Honeypot events listeners.

Core

Changes & Additions:

• Added support for Honeypot Regions, entire areas protected by Honeypot which utilize a single action. These regions are protected from damage/destruction the same as Honeypot Blocks. Create a region with /honeypot create region [action].
  • When creating a region, you will be given a Honey Bottle by default (configurable in config). To create a region, right-click two points. To cancel region creation, drop the Honey Bottle. If you accidentally delete the Honey Bottle, wait 10 minutes, change worlds, or relog.
  • The wand cannot be deposited into an inventory, put in an item frame, or even moved around your inventory if you have another inventory open (if yours is open, i.e. the "E" key, you can still move it). Not all possibilities are accounted for, however. For example, the wand can be given to an armor stand. If you find situations like this which allow you to remove the item from your Inventory, please let me know so I can fix it (armor stand will be resolved later!)
• Added support for changing the type of Honeypot created via the GUI. You can now choose if a block or a region will be created.
  • If you find yourself making regions more than blocks, you can change the default in the gui.yml config!
• Changed /honeypot history from a chat message, limited by whatever was set in config, to a GUI. The GUI now shows all blocks a Player has broken, and each set of blocks is only loaded on page navigation to reduce lag 😁
  • Because the block type was never previously tracked for Player History entries, a barrier will be displayed indicating the type information is not available. For all new blocks broken after this update, the type will be displayed
  • Internally, breaks are tracked by prelimBreak or break. A prelimBreak is a break that occurred but no action was taken as a result of blocks-broken-before-action-taken being higher than 1. If you see a block in this GUI that says prelimBreak, the action was not taken against the player, but it was counted.
• Added support for individual storage providers per store type. You may now have different storage providers for your players, player history, and regions. In theory, you can now store players in a YAML file, player history in a SQLite DB, and if you wanted to get insane, somehow figure out how to serialize data and encode it into an image for your regions. The possibilities are endless!
  • Honeypot, of course, is "batteries included", meaning it comes with three providers for these store types, all of which utilize the same SQLite file you're already using.

Bug Fixes:

• Fixed a bug where the honeypot.* wildcard permission and /op permission was ignored in the GUI, requiring staff to have the exact command-equivalent permission to run an action (i.e., An op or someone with honeypot.* couldn't use "Create a Honeypot" without having honeypot.create, or couldn't locate anything without honeypot.locate, etc.)
• Fixed an issue where, in new versions of Paper, if the Paper version didn't have a hotfix in the version number (i.e., 26.2 instead of 26.2.1 or something), then Honeypot would crash on startup.
• Fixed a bug where players weren't properly auto-completing in the /honeypot history command.
• Fixed potential edge-case where, if a Honeypot was attempted to be created in a Lands region which was in an unloaded chunk, it would be allowed.

Removals:

• Removed legacy migration for PDC, which completes the removal of PDC support in Honeypot.
  • PDC may come back as a separate plugin for another day, but it doesn't really work with regions.

API

Changes & Additions:

• Created HoneypotRegionObject which replaces HoneypotBlockObject. HoneypotRegionObject is used for both creating regions and single block Honeypots. Depending on your need, either call createHoneypotRegion(Block block, String action) to create a single block, using the coordinates of the Block as the region corners, or createHoneypotRegion(Location pos1, Location pos2, String action), which will create a region between the two Locations.
• Added a type parameter to HoneypotStore which defines what kind of provider it is.
  • Currently, three types of stores exist: StoreType.REGION, StoreType.PLAYER, and StoreType.PLAYER_HISTORY. All of these are under the StoreType enum.
• Instead of a StorageProvider being required to implement the entire Honeypot storage specification, it can now define individual stores by annotating the class and implementing the proper Store interface. These are: RegionStore, PlayerStore, and PlayerHistoryStore. Each Store type only requires the necessary methods to be implemented. Want to store players in SQLite while storing Regions in a serialized file, for example? You can do that!
• Registry now has individual set and get methods for the Region Store, the Player Store, and Player History Store.
• Added an AbstractProcessor called HoneypotStoreProcessor. This processor is completely optional and does nothing on its own, but can be added to your build pipeline within build.gradle.kts or pom.xml, and will verify on build that your stores have been properly configured.

Bug Fixes:

• None

Removals:

• Removed HoneypotBlockObject, as all Honeypot blocks are now simply 1x1x1 regions. Use HoneypotRegionObject moving forward.
• Removed Registry.getStorageProvider() and Registry.setStorageProvider(StorageProvider provider), as StorageProvider no longer exists.
• Removed StorageProvider interface as it's been split into individual interfaces for various store types.