Honeypot

# Honeypot 5.1.3 Honeypot 5.1.3 fixes a bug with the `/honeypot reload` command that would cause it to fail if the Ghost Honeypot Checker was disabled, and also drastically improves performance for storage providers. A chunk cache now sits in front of all Storage Providers and will cache which chunks contain Honeypots in them. If a chunk doesn't contain any Honeypots, the plugin won't even reach out to the Storage Provider in the first place. This will lead to dramatic performance improvements by bypassing the DB entirely for events such as `BlockFromToEvent`, which are triggered on fluid spread and blocks with gravity falling, such as gravel, sand, dripstone, and anvils. ## Core Changes & Additions: * Added a chunk caching mechanism to the Region Manager which sits in front of all Storage Providers. Storage Providers are no longer requested to check if a block is a Honeypot Block or Region if the chunk the block is in doesn't contain any Honeypots. Bug Fixes: * Fixed a bug where `/honeypot reload` would fail if the Ghost Honeypot Checker was disabled. Removals: * None ## API To developers, since the new caching changes sit in front of all Storage Providers, if you notice your Storage Provider isn't being hit anymore when you believe it should, please open an issue. Changes & Additions: * None Bug Fixes: * None Removals: * None

# Honeypot 5.1.2 Honeypot 5.1.2 fixes a single bug in the `/honeypot list` command that was accidentally introduced in 5.1.0. `/honeypot list` sorted blocks based on distance from the player, but used `Location::distanceSquared()`, which throws an exception if the Locations are in different worlds. The sorting mechanism didn't account for this, sorry about that! ## Core Changes & Additions: * The `/honeypot list` command now includes the world name Bug Fixes: * Fixed a bug where `/honeypot list` and the List GUI option failed if Honeypots existed in worlds the player was not currently in. This also meant that if Honeypots existed in multiple worlds, this command would always fail Removals: * None ## API Changes & Additions: * None Bug Fixes: * None Removals: * None

# Honeypot 5.1.1 Honeypot 5.1.1 fixes a couple bugs related to Honeypot Inventory Actions and standardizes the click and drag events. ## Core Changes & Additions: * The `InventoryDragEvent` handler now obeys `only-trigger-on-withdrawal`, allowing players to drag items into the inventory. Bug Fixes: * Fixed a bug where players could shift click items into a Honeypot inventory from their own * Fixed a bug where players could use the "double-click to collect items" feature to pull all similar items from the Honeypot inventory to their own inventory * Fixed a bug where the `InventoryDragEvent` could be cancelled by other plugins without Honeypot noticing * All Honeypot events have a priority of `EventPriority.LOWEST` but also have `ignoreCancelled = true`. The `InventoryDragEvent` did not, so this was fixed. Removals: * None ## API Changes & Additions: * None Bug Fixes: * Fixed a bug where the `HoneypotPreInventoryClickEvent` and `HoneypotPreTriggerEvent` would be triggered in a scenario where an `InventoryClickEvent` or `InventoryDragEvent` would've normally been ignored. Removals: * None

# Honeypot 5.1.0 Honeypot 5.1.0 comes 3 days after Honeypot 5.0.0's release and introduces per-type trigger limits for Honeypots, as well as ensures that inventory interact/click and TNT explosions are tracked properly and apply limits the same way. This replaces the legacy `blocks-broken-before-action-taken` config value, so be sure to check out your configs when updating! It also adds improvements to logging, and a new "What's New" GUI for update notifications. This GUI is dynamically generated from a version manifest here on GitHub, and displays the entire change log in an easy-to-read format 😁 Alongside the new features, 5.1.0 fixes a whopping 25 bugs in total, some of which are critical. It is highly recommended you update your version of Honeypot as soon as possible! For developers, this update brings 2 new event types and deprecates 7. The `PlayerStore` and `PlayerHistoryStore` interfaces got updated to support the new `TriggerType` Enum, and the legacy methods deprecated. Existing `StorageProvider` implementations will make the assumption that everything is `TriggerType.BREAK`, but you should update your `StorageProvider` as soon as possible to support the various new trigger types. This update, however, **is** backwards compatible, so you have time. Honeypot 6 will remove all the events and methods that were deprecated this version. ## Core Changes & Additions: - Added per-type trigger limits, so server owners can decide how many of each type of Honeypot they want to trigger - This is per-type based on the event listener, not the action of the Honeypot - In the `/honeypot history query [player]` menu, each break will show the type of trigger that caused it. If no action was taken, the trigger will be prefixed with "prelim", meaning "preliminary". - Added lifetime action and trigger tracking for players - These values are backfilled on migration based on the history table! For most servers, you'll be able to have lifetime tracking right away! - Added new placeholders for these features: - `%honeypot_current_count_[type]%` - Gets the current player's trigger count, where `[type]` is `break`, `inventory_open`, `inventory_interact` or `generic` - `%honeypot_current_count_[type]_[playerName]%` - Gets a given player's trigger count, where `[type]` is `break`, `inventory_open`, `inventory_interact` or `generic` and `[playerName]` is the name of the player to check - `%honeypot_lifetime_triggers%` - Gets the current player's total lifetime Honeypot triggers - `%honeypot_lifetime_triggers_[playerName]%` - Gets a given player's total lifetime Honeypot triggers, where `[playerName]` is the player to check - `%honeypot_lifetime_actions%` - Gets the current player's total lifetime Honeypot actions taken against them - `%honeypot_lifetime_actions_[playerName]%` - Gets a given player's total lifetime Honeypot actions taken against them, where `[playerName]` is the player to check - `%honeypot_triggers_before_action_[type]%` - Gets the number of triggers required per type before action is taken, where `[type]` is `break`, `inventory_open`, `inventory_interact` or `generic` - The legacy Placeholders still exist for backwards compatibility, and use the `break` type - Improved internal player history management, trigger count logic, and action handling to ensure that history and trigger counts are much more accurate and less prone to bugs. - Added a "What's New" GUI for version updates moving forward. This GUI displays how many versions Honeypot is behind, what features have been added and in what version, and what bugs have been fixed and in what version. - Added detection of players lighting things on fire with Flint and Steel or Fire Charges. This prevents players from lighting TNT honeypots and also allows action to be taken on players who attempt to burn burnable Honeypots (previously, the fire would be lit, but the actual burning of the block would be prevented) - This still doesn't not take action against players if a fire they lit spreads to a burnable block, or if they light it via a fire charge shot by a dispenser - As before, Honeypots are prevented from burning, at least - Added a new option to set the minimum log level for Honeypot - Added a new log level, `VERBOSE` - `VERBOSE` logging is far and few between still. I'm working on improving how logging is _implemented_, now, so Honeypot isn't littered with `logger.verbose()` calls lol - Added a new config option to enable or disable logging to a file without having to see DEBUG or VERBOSE messages in the file - Setting the minimum log level to DEBUG or VERBOSE ignores this setting, forcibly enabling file writes Bug Fixes: - Fixed a bug where Block Break Events for a player would incorrectly send WebHooks to Discord regardless of the `send-when` value in config, and would incorrectly categorize them as Action Taken, even if action was *not* taken - Fixed a bug where history was counted twice for players who attempted to blow up Honeypots using TNT - Fixed a bug where players would have a bogus history row added to them when blowing up Honeypots using TNT if they would normally be considered exempt or have the necessary permissions to break the Honeypot - Fixed a bug where, when `allow-player-destruction` was `true` (default), player-lit TNT deleted the Honeypot object while `allow-explode: false` would keep the block intact, allowing players to essentially "disarm" Honeypots by blowing them up if the server was configured as such - Going forward, for ALL explosions, only `allow-explode` is taken into consideration when determining whether to remove a Honeypot, regardless of if `allow-player-destruction` is `true` - Fixed Player History being properly added for inventory interactions and sign changes - Fixed a bug where TNT explosions triggered regions for every block affected by the exposion within the region, rather than treating it as a single event - Fixed a bug where `SignChangeEventListener` blocked changes to sign Honeypots for exempt players - Fixed a potential thread-safety issue regarding the Honeypot Logger and the Discord WebHook handler - Fixed a bug where ghost Honeypots were created when an integration such as WorldGuard blocked an action. The block would be destroyed, but the Honeypot would remain in the database - Fixed a bug where a piston being extended into a breakable Honeypot wasn't detected, breaking the block and leaving a ghost Honeypot behind - Fixed Placeholder API placeholders using `Bukkit.getOfflinePlayer()` instead of `Bukkit.getOfflinePlayerIfCached()` to prevent a blocking call - Fixed a bug where running `/honeypot reload` after setting `use-inventory-click` to `true` would cause the inventory open listener to stop, but the inventory interact listeners to never start, resulting in all container-based Honeypots to be disarmed until the next server restart - Fixed a bug where breaking a block that was supporting a Honeypot but wasn't, itself, a honeypot (i.e. a torch placed on a block, where the block was NOT a Honeypot but the torch WAS) wouldn't trigger the `BlockBreakEvent` for the Player who broke the supporting block - This inadvertently surfaced a pre-existing, but previously unknown, bug where history events would have AIR logged as the associated block if a Honeypot was broken in this manner. That bug has also been fixed - Fixed a bug where regions in different worlds that overlapped on coordinates could be removed when running `/honeypot remove` - Fixed a bug where the Ghost Honeypot Checker was always scheduled on startup, even if it was disabled, until `/honeypot reload` was run to cancel it - Fixed a bug where the "Unsupported Version" message would only show if EVERY version number within the MC version was out of range (year, drop, and hotfix if applicable) - Fixed a bug where comparing two Honeypot Regions for equality would always return true - Fixed a bug where the message for `no-permission` would fail to show if a player attempted to use an action in the GUI they didn't have permission for - Fixed a bug where servers using versions of Honeypot before 3.4.0 that upgrade to Honeypot 4 or later will lose their Honeypots permanently from the DB - Fixed a bug where Honeypot compared versions incorrectly, leading to versions such as `5.1.10` being considered newer than `5.2.0` - Fixed a bug where Honeypots created past ~16,700,000 blocks would get rounded and be created at a completely different location - Fixed a bug where `/honeypot history purge` required a Player argument even though it wasn't required or necessary - Fixed a bug where offline players could not be queried with `/honeypot history query [name]` Removals: * None ## API Changes & Additions: - Added `HoneypotPreTriggerEvent` and `HoneypotTriggerEvent` which is called before and after any Honeypot would be triggered - This event is called for all player-based events and pistons. Pistons events are called using the `NON_PLAYER` trigger type - Added a new `TriggerType` for `PlayerStore` - Updated the `PlayerStore` interface with new methods for utilizing per-trigger event types - Deprecated several event types. All of these events are being replaced by `HoneypotPreTriggerEvent` and `HoneypotTriggerEvent`, accordingly. `HoneypotPreCreateEvent` and `HoneypotCreateEvent` are not deprecated. These will be removed in Honeypot 6.0 - `HoneypotPreInventoryClickEvent` - `HoneypotInventoryClickEvent` - `HoneypotNonPlayerBreakEvent` - `HoneypotPrePlayerBreakEvent` - `HoneypotPlayerBreakEvent` - `HoneypotPrePlayerInteractEvent` - `HoneypotPlayerInteractEvent` - Added an API to `PlayerHistoryStore` to allow retrieval of players based on UUID, which allows querying for offline players now. Bug Fixes: * Fixed a bug in which the (now deprecated) `HoneypotNonPlayerBreakEvent` could be given a neighboring block instead of the Honeypot Removals: * None; see "Changes & Additions" for **deprecations**, however

# 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) <img width="1920" height="1009" alt="Region Screenshot" src="https://github.com/user-attachments/assets/71bfb729-ee95-429d-aebc-4d4cacd98fae" /> 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. > [!IMPORTANT] > Because Honeypot 5 is a massive architectural change, its Developer API is, once again, not backwards compatible with Honeypot 4 or 3.x plugins. Developers working with Honeypot will need to perform quite a bit of work to update to Honeypot 5, especially if they are providing a `StorageProvider`. ## 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 `Location`s. * 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.

# Honeypot 4.0.2 This version doesn't change anything except bump the version of Inventory Framework from 0.12.0 to 0.12.1-SNAPSHOT to fix a bug where an ugly stack trace is printed to console each time a player drops an item, which is due to Inventory Framework's `PlayerDropItemEvent` event listener and Paper 26.1. Nothing else has changed. Server admins who don't care about or ever check the console logs can ignore this version.

# Honeypot 4.0.1 Honeypot 4 was pulled due to an issue where it could not be loaded on servers that have not ran any version of Honeypot in the past. It only changes a single dependency and does not change any of the code. Honeypot 4's release notes are below. # Honeypot 4.0.0 Honeypot 4 is finally here, and it's the largest architectural change ever to Honeypot since its release! Honeypot is now officially powered by [ByteLib](https://github.com/TerrorByteTW/ByteLib), the first-ever (to my knowledge) plugin framework designed with Paper-native in mind. If you'd like to learn more about ByteLib, [check out the code here](https://github.com/TerrorByteTW/ByteLib), or[ read the documentation](https://terrorbytetw.github.io/ByteLib/welcome-to-bytelib.html) for a more in-depth look. ByteLib allows Honeypot 4 to be faster, more powerful, more customizable, and overall ***better***. I hope you enjoy this release as much as I enjoyed creating it! > [!NOTE] > Honeypot 4's Developer API is not backwards compatible with Honeypot 3.5.1 or below, and it also is compiled for Java 25/Paper 26. It is not compatible with lower versions. Server owners are expected to update their servers if they haven't already done so. > [!TIP] > The configuration of Honeypot 4 has changed quite a bit. As comments are not updated with config options, it's recommended you make a backup of your config, let Honeypot generate a new one, then copy any previous configuration over. ## Core Changes & Additions: * Honeypot is now powered by ByteLib, which makes it a paper native plugin. The under-the-hood changes dramatically improve Honeypot's performance! <img width="669" height="99" alt="image" src="https://github.com/user-attachments/assets/cefdd800-de8c-4873-8dc7-40a7112df7be" /> * To test, I ran a piston-based block swapper on a redstone clock and took two 5-minute Spark profiles. Each of these profiles was run on my PC, running a Ryzen 9 5900X with 2GB of RAM allocated to the server. The version of Paper that was tested on was `Paper 1.21.11-91-main@a0f626b` (Yes, this is a couple builds behind as of writing this). * Honeypot 3.5.1 spent 488ms processing Piston Pull Events while this block swapper was running. * Honeypot 4 spent **only 24ms** processing the same events. * Changed how Honeypot caches blocks. Instead of caching the block object, Honeypot now caches the result of SQLite queries. This means that Honeypot now has positive **and** negative caching, meaning giant hopper sorting systems, piston farms, etc. will cause way less lag on servers than before. * Added support for configurable Behavior Providers. Behavior Providers, when marked configurable in their code, will have a configuration file generated within the `honeypot/` folder in your server. At the current time, these files will be blank. It is up to the developer of the Behavior Provider to tell Honeypot users what options are available. This will be changed in the next update to allow default options. * To demonstrate these capabilities, the built-in `warn`, `ban`, `kick`, and `notify` action types have been made configurable. The `warn` one is my favorite, you definitely should give it a try! * Only the built-in providers have default configurations available to them. 3rd party providers cannot provide default options. Again, this will change in the next update. * Added support for configuring SQLite options. This allows server admins to tweak how SQLite will operate within Honeypot. This is a very powerful feature and **will break Honeypot if you're not careful**, so exercise caution if you even _think_ you need to change these options. * Some of these options can and/or will cause instability, but they can improve performance even further. If you have questions, please refer to the documentation within the configuration file. * Honeypot commands now use the Brigadier API. This allows for much more flexible and powerful command authoring, but there is a difference in how commands are displayed. The biggest change is players who do not have permission to run the command will not even see it in the slash menu. Attempting to run a command they don't have permission to, even if it exists, will cause Minecraft to display its generic "command not found" error. * SpiGUI has been replaced with InventoryFramework, allowing for more feature-rich GUI's that target the most recent version of Minecraft. * Improved debug messages. * Added a new config option to silence noisy event messages from being logged. This only affects `DEBUG` level messages. Bug Fixes: * Fixed a bug where `Material`s that are not able to be represented as `ItemType`s (Such as `REDSTONE_WALL_TORCH`) would cause Honeypot to throw unhandled exceptions in console when a GUI was accessed that attempted to render said `Material`s. * Fixed a bug where Honeypot may throw an exception during load due to an improperly formatted supported versions file. * Fixed a bug where staff who did not have `honeypot.create` but _did_ have `honeypot.gui` could create Honeypot blocks. Removals: * The PDC storage provider is no longer an option. A separate, official, plugin that provides PDC storage will be released soon. However, this is not a priority and server staff should not assume this is coming anytime soon. * Servers using PDC will be automatically migrated to SQLite on boot. This may take a bit, and depending on various factors may cause Honeypot to crash. **This is known and will not break your server.** Please see the bottom of the change log for details. * As Honeypot now uses ByteLib, the previous caching options have been removed from config. * Removed `/honeypot migrate` and related permissions, translations, and code. ## API Changes & Additions: * Changed `HoneypotStoreRegistry` to `StoreRegistry`. This is more in-line with the naming of `BehaviorRegistry` as well. * Added a `configurable` value to the `@Behavior` annotation. When `true`, Honeypot will create a configuration file within its data directory for your provider. * Changed the method definition of `BehaviorProvider`'s `process` method to be `public abstract boolean process(Player p, Block block, @Nullable YamlDocument config);`. If your `@Behavior` annotation has `configurable = true`, Honeypot will provide a `YamlDocument` object from [BoostedYAML](https://github.com/dejvokep/boosted-yaml) in the `config` parameter. If `configurable = false`, then `config` will be null. * Configuration is provided via ByteLib, and plans currently exist to replace BoostedYAML with a different library. As a result, this API will change in the future. Bug Fixes: * Fixed a bug where `HoneypotPreCreateEvent` was called twice (and `HoneypotCreateEvent` was never called) when a Honeypot was created via the GUI. * Fixed a bug where `HoneypotNonPlayerBreakEvent` for Piston Extension and Retraction would always have the block being pushed or retracted as the piston, not the Honeypot. Removals: * None # A note about PDC For server owners who adjusted the experimental storage option to PDC instead of SQLite, this change is important. Honeypot no longer supports PDC out of the box. If you need PDC, you will need to create your own Honeypot store _or_ remain on Honeypot 3.5.1. If Honeypot detects PDC in use during first boot, it will automatically begin a migration to move your data to SQLite. Your PDC data will also not be removed after this migration, meaning that if you decide to go back to Honeypot 3.5.1 for whatever reason, your data is safe. The main reason for this section is because of a potential crash caused by a slow disk on first launch. Honeypot utilizes ByteLib for SQLite. ByteLib's SQLite API has fairly low tolerances when it comes to query times. By default, the SQLite module in Honeypot is configured to throw an exception if a query lasts over 50ms. For some servers or hosts (especially shared and/or budget hosts, where disk read/write is shared among dozens of virtual servers on a single physical host), this may be quite common. If Honeypot's migration query lasts longer than 50ms, Honeypot will throw an exception which, ultimately, will cause it to crash. To workaround this, allow Honeypot to crash on first launch (if it does, at all), stop your server, open Honeypot's `config.yml` (which should have been updated at this point) and change `db.main-thread-timeout` to something like `2000` (2 seconds). Then, start your server again, allow Honeypot to perform the migration, and then either change it back or leave it be.

# Honeypot 3.5.1 Version 3.5.0 has been pulled due to 2 somewhat critical bugs pertaining to the Caching System and Double Chests. Version 3.5.1 has no breaking changes from 3.5.0, and it's recommended you IMMEDIATELY update as soon as possible. Version 3.5.0's notes are at the bottom: ## Core Additions: * Added a new warning in console on startup that will output a warning if the version of Honeypot being ran has been pulled from GitHub (And, by proxy, Hangar and Modrinth) Bug Fixes: * Fixed a bug in the Caching System which would store Honeypots in memory with no way to "remove" them without either filling the cache with "new" Honeypots or rebooting the server. * Fixed a bug with the `/honeypot remove` command where it would attempt to remove the targeted block instead of the actual Honeypot block when the block is bisected (double chest, doors, beds, etc.) * Fixed a bug where, when `use-inventory-click` was enabled in Config, clicking within a Double Chest would throw a `ClassCastException` in console. * The `DoubleChest` class is the only class in Paper that doesn't implement `Container` but instead extends `InventoryHolder`. There is so much custom logic just for `DoubleChest`s because they don't follow the standard. Woo. Hoo. Changes: * The Honeypot Cache is now cleared on `/honeypot reload` should anything go haywire. This also allows you to disable caching on the fly by setting the cache value to `0` in config, then reloading. Removals: * None # Honeypot 3.5.0 Hi everyone! I'm back with another small update to Honeypot, but it fixes some critical bugs and improves the plugin a little bit. I hope you are still enjoying Honeypot! Testing of the last few versions has proven successful, so this version brings Honeypot out of Preview and back into Stable again! # Please read As part of this update, the way the Chat Prefix was handled has been changed. You are not *required* to change your prefix, but you **should** add a space at the end. The plugin used to prepend a ` ` character automatically after the chat prefix anywhere used in code, but now since the ` ` is after the prefix *in the translation*, if you don't add a ` ` at the end of your prefix, your messages will be smashed against the prefix. Heads up! ## Core Additions: * None Bug Fixes: * Fixed a bug where the Locate GUI object would throw an error. Resolves #211 * Fixed a bug where messages in custom Honeypots would send to the player a string representation of the `TextComponent` instead of the actual formatted text. Resolves #212 * Fixed a bug where Double Chests would not trigger Honeypot actions. Merges in #208 with changes * This has been extended to Doors and Beds as well since they are also bisected. * Fixed an incorrect warning about running Folia on non-Folia servers when the server starts Changes: * Removed usage of `/hpteleport` everywhere in Honeypot. When teleporting to blocks using the Honeypot GUI, internally a fake command `/hpteleport` was forced to be ran by the player, and subsequently intercepted and cancelled. This was to allow teleporting of players who didn't have `/tp` access. This was also....**really** stupid. The plugin now uses the proper APIs to teleport the player instead of psuedo-commands. * Fun fact! The only "vulnerability" Honeypot has ever experienced was surrounding this command. Before it was patched, if you ran `/hpteleport` as a player, you could teleport anywhere in the world without permission, without anyone knowing. It wasn't even output in console. I'm very glad this fake command has been removed. * Use the Spigot Library Loader instead of compiling libraries directly into the plugin. I discovered this thanks to Restitutor, who also created PR #210. This drastically reduced Honeypot's file size to just 231.39 KB! * Increment version number of all languages by one to fix an issue where `<reset>` being at the end of the chat prefix no longer deserializes properly, resulting in the rest of the message formatting not actually being reset properly Removals: * None ## API: Bug Fixes: * Fixed a bug where the `#isHoneypotBlock()` method of Storage Providers would return `false` for bisected blocks in which the other part of the block *was* a Honeypot. For example, if the *top half* of a door was a Honeypot block and `#isHoneypotBlock()` was called on the *bottom half*, you'd get `false` instead of `true`. Additions: * None Changes: * None Removals: * None

# Honeypot 3.4.1 Honeypot 3.4.1 fixes a few small bugs that snuck their way into 3.4.0. ## Core Additions: * None Bug Fixes: * Fixes a text formatting glitch with certain commands caused by implicit `#toString()` conversion on Components. Fixes #203 * Fixed a bug where `allow-player-destruction` was ignored when the player had certain permissions Changes: * None Removals: * None ## API: These changes are bleed-over from 3.4.0. I'm keeping them here as it's important for developers to see it! :) ### PLEASE READ If you are a **developer** and have written plugins for Honeypot, please know that they will no longer be supported as of 3.4.0. You will need to do some minor refactoring. Specifically, a new `Registry` class is available in the API to interact with the Behavior Registry and the new Storage Provider Registry. The TL;DR is: Anywhere you use `Honeypot.getRegistry()`, change it to `Registry.getBehaviorRegistry()`. ~~Documentation will come for this new API, I'm working on writing it with Writerside now, and it will be published on a pretty website :)~~ Documentation is now available [here](https://terrorbytetw.github.io/Honeypot-Docs/)! Additions: * Support for Storage Provider. Honeypot can now add 3rd party storage providers if PDC or SQLite aren't suited for you. However, do note that Honeypot is not written for asynchronicity in mind, so for now storage providers _should_ be synchronous. Network access in your storage provider is not recommended. Changes: * Refactored some classes. Imports will need updated Removals: * None

# IMPORTANT As of Minecraft 1.21, Java 21 is required for Paper to run. Plugins _can_ use Java 17 still and that was Honeypot's goal. However, due to certain dependencies being updated to require Java 21 (WorldGuard), I cannot develop on Java 21. Therefore, you MUST run Java 21 as well! As noted n the previous release, Honeypot as of this version **does not support Spigot**. Paper is, by far, the most widely used and performant server platform. It's no surprise that it's so widely used either: Paper provides users download links, Spigot requires you to build from source which requires quite a bit of technical know-how. That alone will cause people to gravitate towards it, even if they don't realize that Paper is vastly more performant. Paper is making a hard fork at some point in the future, meaning they will be diverging from the Spigot API, and then I'd have to maintain two versions of the plugin, each with potentially differing feature sets depending on the API availability. Folia is supported currently, but the difference between Folia and Paper is very minute (For the technical people, all I had to do was write a custom Scheduler implementation that utilizes Folia's scheduler instead if the plugin detects it is running on it, otherwise it uses the default Spigot/Paper one). According to bstats, as of typing this [only one server is utilizing Spigot](https://bstats.org/plugin/bukkit/Honeypot/15425) anyway. For these reasons, I have killed support for Spigot and moved fully over to the Paper APIs. If you want to use Honeypot and you are using Spigot, you will need to migrate to Paper. For 99% of users this will be a simple drag-n-drop of the Paper jar in-place of your Spigot jar, no other changes should be necessary. The regular changelog is below! 😄 --- # Honeypot 3.4.0 Honeypot 3.4.0 is a MASSIVE rework of many features, internal APIs, and contains several bug fixes and feature improvements. ## Core Additions: * Adds `/honeypot migrate`. "Fixes" #188 * Adds support for custom storage providers Bug Fixes: * Fixed a bug that caused Honeypot to crash if PlaceholderAPI and Vault weren't installed, even though these are optional dependencies. Fixes #191 * Fixed a potential bug where there was a possibility of Honeypot blocks triggering within areas protected by other Claims plugins (GriefPrevention, Lands, WorldGuard). Fixes #192 * Fixed a bug which caused custom Honeypots defined in `honeypots.yml` to not be able to trigger their commands. Changes: * Changed the way Honeypot Blocks are stored in SQLite and PDC. * This change has made Honeypot queries and lookups quite literally almost 100% faster. From testing, Honeypot went from taking 22.36% of the tick time to only 0.21%, which comes out to a 97% reduction in processing times. This was done by migrating SQLite to spatial indexing which allows "querying" in 3D space, and migrating PDC to use the native `Location#distance()` function within the API. To put this into perspective, SQLite and PDC both can now query a 2,000,000³ area (That's eight **QUINTILLION** blocks) in only a few milliseconds. Before this change, it was impossible to query anything larger than a 10³ or 20³ without locking up the server. Yay for optimization (And also not doing DB queries the stupid way)! Fixes #187 * Other minor performance changes and enhancements Removals: * Spigot support ## API: ### PLEASE READ If you are a **developer** and have written plugins for Honeypot, please know that they will no longer be supported as of 3.4.0. You will need to do some minor refactoring. Specifically, a new `Registry` class is available in the API to interact with the Behavior Registry and the new Storage Provider Registry. The TL;DR is: Anywhere you use `Honeypot.getRegistry()`, change it to `Registry.getBehaviorRegistry()`. Documentation will come for this new API, I'm working on writing it with Writerside now, and it will be published on a pretty website :) Additions: * Support for Storage Provider. Honeypot can now add 3rd party storage providers if PDC or SQLite aren't suited for you. However, do note that Honeypot is not written for asynchronicity in mind, so for now storage providers _should_ be synchronous. Network access in your storage provider is not recommended. Changes: * Refactored some classes. Imports will need updated Removals: * None