ВЕРСИИ (24)

# 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

# IMPORTANT As of Minecraft 1.21, Java 21 is required for Paper to run. However, plugins can still be developed using Java 17, so Honeypot will still be built on that version to support older server software (I always develop for the latest version though, so I'd highly suggest using 1.21 with 3.3.2!). However, with this version also comes an announcement: Honeypot, as of all future versions (3.3.3+), will **no longer 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. Even though I support Spigot and develop against it, I've actually been exclusively using Paper to test when I create updates. 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 will be killing support for Spigot and moving 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.3.2 Version 3.3.2 brings the plugin out of its `SNAPSHOT` state since testing of the 3.3.1 feature set is complete. It also adds support for Discord webhooks so you can be proactively notified if any Honeypots are triggered while you aren't online. ## Core Additions: * Added Discord Webhook support. Simply enable the new discord setting in `config.yml`, paste your Discord Webhook URL, and state whether or not you want notifications for all block breaks (`onbreak`) or just when action is taken (`action`). * Do note, this is using OkHttp3 from Square, and during testing I noticed that it was taking nearly 1 second for these requests to be made and would "freeze" the server until the request was sent (See screenshot below). Due to this, I've designed Honeypot to create a separate thread each time a notification needs to be sent to prevent blocking the main server thread. If, however, you notice lag, please let me know and provide me with a Spark profiler export so I can check. Please be sure to do `/spark profiler start --thread *` so I can see everything happening, not just the single server thread.  Changes: * None Removals: * None ## API: Additions: * None Changes: * None Removals: * None

Version 3.3.0 is being re-released as 3.3.1 to fix a bug relating to /honeypot create failing in GriefPrevention areas. It also adds translations for Chinese (Simplified). Thanks, @HaHaWTH! I'm still considering this a snapshot --- # Honeypot 3.3.1 Please see the note at the bottom of this release! This update brings a feature that was recommended in my Discord a while back, and is finally being released: The `type` field in the history command. Previously, Honeypot only logged breaks when an action was taken, not if the break was just counted. Now, Honeypot counts each break AND will list whether or not it was a `prelimBreak` or a `break`. `prelimBreak` indicates the block was broken but no action was taken. The block may or may not still exist based on permissions of the player or config options. It also fixes a bug regarding the `/honeypot history query` command and refactors large parts of the code. ## Core Additions: * Added a `type` field to the Honeypot History table. This allows admins to see when players `attempted` to break blocks, as well as when action was actually taken. Changes: * Fixed a bug in `/honeypot history query` where the command would just return random values from the table instead of the most recent values in descending order. * (Internal change) Refactored the plugin to use Dependency Injection, which will make the plugin easier and faster to develop. It also has the benefit of potentially making the plugin slightly faster and more efficient since it's not `new`ing a ton of crap every 5 seconds! * (Internal change) Because this version of Honeypot changes the DB schema, I've implemented a SQLite versioning system within the plugin. This will allow me to add patches at any point in time should I need to add a feature that requires a SQLite DB schema change. Removals: * None # API: Additions: * None Changes: * None Removals: * None --- The SQLite patching system I've written has been mostly tested, but I'm still not 100% about it, more like 98%. Due to this, I'm marking this a pre-release until I finish testing the weird one-off scenarios. If you want to upgrade the DB manually so you don't have to fear anything, here are the two commands you need to run in [some SQLite DB explorer](https://sqlitebrowser.org/)! ``` ALTER TABLE honeypot_history ADD `type` VARCHAR NOT NULL default 'prelimBreak'; PRAGMA user_version = 1; ```

Sorry for the delayed updates with this project. In real life I've been pretty busy with my daughter and family, as well as studying for multiple IT certificates (Genesys Cloud CX for my job, CKA, and CompTIA Security+), and my time has been stretched so thin I barely have time to think haha. That being said, this project **is not dead**, just...slowed. I hope you understand and still stick with it! I welcome pull requests if anyone wants to help add some features. Thanks, everyone! 😄 --- # Honeypot 3.2.2 Updated for version 1.20.5. To support backwards compatibility, I'm planning to remove the PhysicsUtil and just check if any blocks surrounding a block break event were Honeypots and are now air. I want to test this for efficiency to ensure these checks don't bog down the server, so I'll combine some methods and work on improving efficiency (We already switched to PDC so this will really help). This also fixes a minor, likely unnoticed, bug regarding reloading language files from the console. Finally, it adds some better debug logging for block break events, and updates some logic. This logic was complex prior to the refactor, so if anything stops working that I didn't see in testing, let me know via Discord or an issue! ## Core Additions: * None Changes: * Better debug logging for BlockBreakEvent * Fixed a bug where language files wouldn't be reloaded if `/honeypot reload` was ran from console. This was a result of the Console's `/honeypot reload` logic actually being decoupled from the plugin's `/honeypot reload` subcommand. I apparently forgot to add language file reloading via console when I added translation support, and it's been like that ever since. Removals: * None # API: Additions: * None Changes: * None Removals: * None

# Honeypot 3.2.1 Resolves a bug in the previous version of Honeypot where all Honeypot types in the "Create Honeypot" inventory would show as Paper. This is now configurable on the action level, meaning you can have whatever icon you want! ## Core Additions: * Custom actions can now specify an icon for their GUI counterparts Changes: * The API is no longer bundled with Honeypot, you must use the separate API package. Please refer to the Honeypot wiki for instructions on how to do this if you develop with Honeypot. This is a simple dependency swap, everything else is the same. * Custom actions no longer display as Paper, which was the fallback if an icon based on the type didn't exist. A previous version of Honeypot removed the type requirement, so if you removed the type field, you probably noticed all your icons were paper. Removals: * None # API: Additions: * None Changes: * The API is now bundled as a separate project. Please use that to develop with Honeypot going forward. Removals: * None

# Honeypot 3.2.0 This update adds support for an experimental new storage method, PDC. Persistent Data Containers are an API in Spigot which allow you to store data within Worlds, Chunks, ItemMetas, Entities, TileStates, and Structures. This enables you to store Honeypot data directly in the world instead of the sqlite DB, meaning faster queries and less TPS lag. This is an **experimental** feature, and while it's been tested and is working, should still be considered experimental until the next version when I make it a standard feature. To enable it, update the plugin and restart your server, open your config, go allllllllllll the way down the bottom and change `storage-method` from `sqlite` to `pdc`. Then, restart your server one last time. ## Core Additions: * Experimental support for utilizing PDC for Honeypots. This currently uses the World to store data, as any other method wasn't feasible. * A new `/honeypot debug` command, which is disabled by default and can only be enabled by a config change followed by a server restart. This command is specifically for me to use when developing Honeypot, but may come in handy for other server owners, who knows. So, it's been documented. Changes: * None Removals: * None Known Bugs: * None at the moment! Let me know if you find any :) # API: Additions: * None Changes: * None. The addition of PDC will not affect your plugin if you were using the HoneypotBlockManager to interact with Honeypot. If you were using the SQLite or Database classes for some horribly abusive reason, you will be affected if the server decides to switch to PDC, as these classes, while they will still function, will not have updated data. Removals: * None Known Bugs: * None I gave up on MD5 checksums. I really don't feel like wasting my time generating them. So, from now on those will not be provided. If you ever don't trust a release, build from source, as each of my commits is signed and verifiable with my SSH key (Need my public ed25519 key? Get it [here](https://reprogle.org/keys)). It should be relatively easy, just clone the project and `gradle build` 😄

## What's Changed * Optimized some events that may have caused lag on older hardware or shared hosts. * One of those events was BlockFromToEvent, which was to help prevent water and lava from breaking Honeypots such as torches. This event is now part of the "extra" events in config, and is off by default. If this is left off, the Ghost Honeypot Fixer will come in and, at every interval you set in the config, will check if any Honeypots are water or lava. If so, it's assumed that water destroyed a Honeypot and the block will be removed from the DB. The drawbacks of this are that water can destroy certain Honeypots now, but the benefits are a very noisy event is no longer fired * The other event that was modified was InventoryMoveItemEvent. This event is what handles processing hopper and dropper moves to/from an inventory. This is a _very_ noisy event as well, and as a result can fire thousands of times a second. I've done what I can to optimize this event as well. On shared hosts or hosts with older hardware, however, this event can still be an issue. I've done Spark profiler tests and Timings checks (Even though Timings is deprecated and isn't accurate per the Paper team), and it seems to be better, but if server owners continue to have issues let me know! I'm still working on optimizing this, and have reached out to folks that know better than I for assistance as well. * Migrated build system from Maven to Gradle (Resolves #166) ## New Contributors * @SandwichBtw made their first contribution in https://github.com/TerrorByteTW/Honeypot/pull/167 **Full Changelog**: https://github.com/TerrorByteTW/Honeypot/compare/3.1.0...3.1.1

# Honeypot 3.1.0 This one is a pretty large update! This update fixes some bugs, refactors parts of the project to be easier to maintain, adds support for Lands and Placeholder API, removes some limitations from custom Honeypots, and adds 3 new (optional) event listeners for preventing "creative" methods of griefing! ## Core Additions: * Lands is now a supported integration! If Lands is installed on your server, Honeypot will not allow creation of a pot within a claimed Land * Placeholder API support is here! You can now use Placeholder API in your custom Honeypots * Honeypot now has a built-in Placeholder Extension! These Placeholders allow you to display messages such as "Player has broken 3/5 Honeypots". This would be written as "Player has broken %honeypot_current_count_broken%/%honeypot_breaks_before_action% Honeypots". There are currently three placeholders available: * %honeypot_current_count_broken% -- This placeholder displays the count of Honeypots the player has broken *this cycle*. This means that this value will *never* be more than `blocks-broken-before-action-taken` in config. * %honeypot_breaks_before_action% -- This placeholder displays the value of `blocks-broken-before-action-taken`. * %honeypot_current_count_broken_\<player\>% -- This placeholder will get the current amount of Honeypots a specific player has broken *this cycle*. This value will *never* be more than `blocks-broken-before-action-taken` in config. * More listeners to prevent creative ways of destroying Honeypots Changes: * HoneypotConfigManager now shuts down the plugin if it fails to reload using non-deprecated methods * /honeypot reload now shuts down the plugin if anything fails during the reload * /honeypot reload will now reload the Ghost Honeypot Fixer, which means changes to those settings no longer require a restart. This means that the GHF can now be started or stopped on the fly * Config is now version 18 * Languages files are now version 4 (With the exception of French, which is now version 3). Be sure to update your custom translations, if needed! Removals: * Custom Honeypots made in honeypots.yml are no longer limited to types. This means that the "type" key is no longer required, and you can have permissions, commands, broadcasts, and messages all in the same honeypot. I put this under "Removals" because the type requirement has been removed Known Bugs: * None at the moment! Let me know if you find any :) # API: There were a few changes to the internals of Honeypot. None of these should affect you unless you are a maintainer, as you shouldn't be using these methods in your own plugins. Additions: * None Changes: * Folia utility classes are now stored in the utils folder * An AdapterManager now handles all adapters within the plugin. This is a WIP, and I intend to make this cleaner * WorldGuardUtil and GriefPreventionUtil have had the "Util" stripped off and replaced with "Adapter". This makes more sense in my opinion * The Update Checker and Supported Version checker now use Java's Consumer instead of Bukkit's Consumer import. Not sure how I missed that, but it's been resolved * The Deprecated "log" method within HoneypotLogger has been removed * ListenerSetup uses more modern methods to register events. Less duplicated code, but slightly more complex. Removals: * None Known Bugs: * None I gave up on MD5 checksums. I really don't feel like wasting my time generating them. So, from now on those will not be provided. If you ever don't trust a release, build from source, as each of my commits is signed and verifiable with my SSH key (Need my public ed25519 key? Get it [here](https://reprogle.org/keys)). It should be relatively easy, just clone the project and `mvn package` 😄

# Honeypot 3.0.5 Version 3.0.4 was pulled due to the bug it was supposed to fix not being fixed. Turns out I had made a typo which caused the problem to not be solved. During testing, another major bug was discovered that can cause the plugin to silently fail to finish loading, so this update is recommended for all Honeypot users. The changelog below is largely technical, but is here in the spirit of transparency. I apologize for any issue this caused. Luckily, 3.0.4 was only downloaded twice before the issue was caught, and I know at least one of the servers it was running on was the person who reported it. ## Core Additions: * None Changes: * Within the InventoryClickDragEventListener file, it was discovered by a member of my Discord server that the event wasn't being cancelled prior to action being taken, meaning that if a player was removed from the general vicinity of a container, they would keep items inside. [See here for the action](https://github.com/TerrorByteTW/Honeypot/blob/5941fda9760bfe1cd1f98bc3dca42ee9cd1dc26a/honeypot-core/src/main/java/org/reprogle/honeypot/common/events/InventoryClickDragEventListener.java#L93), and [here for the cancellation](https://github.com/TerrorByteTW/Honeypot/blob/5941fda9760bfe1cd1f98bc3dca42ee9cd1dc26a/honeypot-core/src/main/java/org/reprogle/honeypot/common/events/InventoryClickDragEventListener.java#L99). So, the `event.setCancelled(false)` line was moved to above. However, keen eyed devs may notice the issue: `#setCancelled(false)` is, obviously, false. This should be true, so the event was still not being cancelled. This has been fixed and tested thoroughly to ensure the problem has been resolved. * During testing, I threw Honeypot onto a test server (without Vault) and was extremely confused when the /honeypot command wasn't working, but was also not throwing errors. In debugging this [I found I left a `return;` statement inside the `#onEnable()` method](https://github.com/TerrorByteTW/Honeypot/blob/5941fda9760bfe1cd1f98bc3dca42ee9cd1dc26a/honeypot-core/src/main/java/org/reprogle/honeypot/Honeypot.java#L126) which returns early out of the `#onEnable()` if Vault isn't found. The original vault code used to live in its own method, but I moved it inside the `#onEnable()` method a while back and clearly forgot to remove the return. This caused several issues due to the early return, including: * GriefPrevention support was not loaded * The command manager for Honeypot was not registered (Existing Honeypots would work, but the /honeypot command and GUI would not) * The splash message was not output * The Folia check was not done * Server version support verification was not completed * The update check was not ran These issues have been fixed Removals: * None Known Bugs: * None at the moment. If you find a bug, raise an issue! ## API Changes: * None Removals: * None ## Nerd info MD5 checksums: * `2192446e2626b1198ea16ae9bc34e9bb` honeypot-core-3.0.5.jar * `bd2b4fc33324ff0442f5056da013f0e5` honeypot-core-3.0.5-javadoc.jar * `5355f588e6515410e4b004115d67ed09` honeypot-core-3.0.5-sources.jar

# Honeypot 3.0.3 This version fixes some bugs around the block break listener, and also changes some core behavior of the block break functionality ## Core Additions: * None Changes: * The `allow-player-destruction` value in config.yml now determines if action is taken *at all*. If allow-player-destruction is set to true, action will only be taken if A) `blocks-broken-before-action-taken` is <= 1, or B) the player has reached the `blocks-broken-before-action-taken` value. This allows Honeypots to be broken without triggering events, if the staff still choose. If you had `blocks-broken-before-action-taken` set to 1 or less and/or had `allow-player-destruction` disabled, this won't affect you. If it was set to a greater value and you had player destruction enabled **anyway**, then this WILL affect you, as your Honeypots will silently disappear upon breaking. | Allow Player Destruction | Blocks Broken Before Action Taken | Are you affected? | |--------------------------|-----------------------------------|-------------------------------| | True | <=1 | No! | | True | >1 | Yes, this change affects you! | | False | <=1 | No! | | False | >1 | No! | * Fixed some issues with the Honeypot break logic. It wasn't all inclusive, and some edge-cases would allow certain players to break blocks without punishment. * Added more detailed logging to Honeypot. If `enable-logging` in config is enabled, honeypot.log will include all debug, info, warning, and severe messages. Console will always include info, warning, and severe messages regardless. Removals: * None Known Bugs: * None at the moment. If you find a bug, raise an issue! ## API Changes: * None Removals: * None ## Nerd info MD5 checksums: * `730d53cc77f90427fa5c83b5685e0e20` honeypot-core-3.0.3.jar * `3125da1a01b32a21cae95bdbf52463de` honeypot-core-3.0.3-javadoc.jar * `46d61e6ff0b3965fda8883e03c671948` honeypot-core-3.0.3-sources.jar

# Honeypot 3.0.2 This version adds a new %world% placeholder for custom actions. It also removes the Vault requirement, and instead soft-depends on it, allowing you to run this in Folia servers without issue. **PLEASE NOTE** Folia is an _experimental_ server software. In order to make Honeypot run on Folia, I had to move Vault from a hard to soft dependency. This means that, without Vault, you cannot use custom actions of type `permission`. This is the only caveat! ## Core Additions: * %world% placeholder for custom actions. The %world% placeholder will be replaced by the name of the world the block was broken in. For example, if broken in the default Nether, it will say `world_nether`. Changes: * Vault is no longer required. If not installed, permission custom actions won't work, but that's the only thing that will stop functioning :) * Config version has been increased to 16. The %world% feature was a suggestion in my discord, so I'm crediting the suggester accordingly. If you want to be included in the credits, be sure to suggest a feature, report a bug, or translate Honeypot to your native language! Removals: * None Known Bugs: * None at the moment. If you find a bug, raise an issue! ## API Changes: * The #process event within the abstract BehaviorProvider class no longer marks the `block` as @Nullable. This was part of the original design just in case a block wasn't necessarily passed to a provider, but later I wrote the internal code to require a block to be passed before a behavior is processed. This result in this annotation not only being unnecessary, but also contextually wrong. This won't affect your builds, by the way :) Removals: * None ## Nerd info MD5 checksums: * `d9bd5aa5876977856107abfd77acb2d3` honeypot-core-3.0.2.jar * `05654bb2f17c0f8bb764b5d57934e87e` honeypot-core-3.0.2-javadoc.jar * `0866d4954cbd69669d830c8bc712c52e` honeypot-core-3.0.1-sources.jar

# Honeypot 3.0.1 This version fixes a few bugs, and adds preliminary support for Folia. Soon, Honeypot will natively support Spigot, Paper, and Folia, instead of using the Spigot API in its entirety. This will mean it'll perform better on Paper servers, but will still run on whatever you like! **PLEASE NOTE** Folia is an _experimental_ server software. While Honeypot _does_ support Folia, in order to do so I had to disable Vault while testing. Vault is still a dependency, and does _not_ support Folia yet, meaning you will not be able to load Honeypot on your server until Vault adds support. However, the good news is that once Vault does add support, Honeypot will be ready and waiting for you! 😁 ## Core Additions: * Complete Folia support. Honeypot will work with Folia as soon as Vault adds support. If you need to use Folia now, please head to my Discord and I can work something out with you! Discord link is in the project's README Changes: * Running /hpteleport (An internal-only command) could cause errors in console. This has been fixed * Fixed a bug where if you spam click an inventory that is a Honeypot (Such as a chest or barrel) fast enough, an item might be placed. (If this still happens for you even after the fix, please create an issue so I can investigate!) Removals: * None Known Bugs: * None at the moment. If you find a bug, raise an issue! ## API Changes: * None Removals: * Individually packaged API is no longer available ## Nerd info MD5 checksums: * `a97fb2fc03ffb687c4001bd1afb6f9ab` honeypot-core-3.0.1.jar * `6587dec2e4262d51f4c646d98b58009e` honeypot-core-3.0.1.jar * `89f4425bd9bede390e00d7b92244c743` honeypot-core-3.0.1.jar

# Honeypot 3.0.0 This version adds many new features, fixes some bugs, and ensures support for 1.20! **PLEASE NOTE** this is a snapshot build, and does not include all the features promised for 3.0.0. However, it is still stable! Feel free to use it in production. ## Core Additions: * Added a new developer feature called Behavior Providers. Behavior Providers allow developers to add completely custom behavior to any Honeypot. View the [wiki](https://github.com/TerrorByteTW/Honeypot/wiki/Developing-plugins-using-the-Honeypot-API) for more info! * Behavior Providers will show up as options in the GUI and in the create command just like custom actions. Behavior Providers will take priority over custom actions as well, if the names clash. Behavior Provider names, however, must be unique. * Behavior Providers must have a custom icon defined by the developer, and this icon will show up in the GUI. This makes it easier to identify your actions (For example, the built in "Kick" behavior provider is Leather Boots). * Added InventoryMoveItemEventListener. This event listener prevents Hoppers and Droppers from dumping items into Honeypots as a way to prevent griefing via item spam. * Added some extra logging to help with fixing issues later on. Changes: * Creation command now no longer asks if you want to use built-in behaviors or custom ones. They are all in one list, simplifying the creation of Honeypots. * On the same lane of thought, the GUI now does the same * Fixed bug with `/honeypot history` causing console errors if ran without subcommands * The API is now packaged with the core plugin. Having it separate was nice at first, but it just got more frustrating the further along I went. Just change your dependency from `honeypot-api` to `honeypot-core`, nothing else will need changing because, quite frankly, I'm amazing lol (JK, the API always was shaded into the main jar anyway, so the package names were always the same regardless. That's why you had to use the API for development but the core plugin for your server, and it worked just the same). Removals: * Removed `/honeypot upgrade` command. Bstats shows that no one is using old versions anymore, so that function is obsolete * Removed unused translations as a result of the removal of the upgrade command. * Removed the "nothing" Honeypot. It was pretty useless IMO, no need for it. Known Bugs: * If a player spam clicks an item in a Honeypot, it may still be placed. I am trying to figure out why this is the case, but I think it's a race condition. ## API Changes: * The API is packaged with the `honeypot-core` file now, it is not a separate file. Removals: * Individually packaged API is no longer available ## Nerd info MD5 checksums: * `477c0aa8f78754d3f2ab062b07a98b70` honeypot-core-3.0.0-javadoc-SNAPSHOT-1.jar * `77acc322f6c6343e4ee0b1fa087ea4e0` honeypot-core-3.0.0-sources-SNAPSHOT-1.jar * `8b7c17a9138ac6550635dc86b8c80364` honeypot-core-3.0.0-SNAPSHOT-1.jar

# Honeypot 2.6.4 This version simply ensures functionality with MC 1.19.4 ## Core Additions: * None Changes: * Honeypot now checks GitHub to verify if Honeypot supports the server version you're running. Long story short, this means that if a minor MC revision comes out that doesn't affect Honeypot functionality, I can remotely disable the "Honeypot may not support this version of Minecraft" messages on server boot. * The plugin is checking [this folder](https://github.com/TerrorByteTW/Honeypot/tree/master/supported-versions) in the GitHub repo. As always, the plugin is open source so you can verify this yourself. Relevant code is [here](https://github.com/TerrorByteTW/Honeypot/blob/master/honeypot-core/src/main/java/org/reprogle/honeypot/utils/HoneypotSupportedVersions.java) and [here](https://github.com/TerrorByteTW/Honeypot/blob/0d5a12cca358ad4b1948fbeacb274fb446012097/honeypot-core/src/main/java/org/reprogle/honeypot/Honeypot.java#L148). As always, security is of the utmost priority, so Honeypot will never make remote calls to servers that it doesn't need to. Removals: * None Known Bugs: * If a player spam clicks an item in a Honeypot, it may still be placed. I am trying to figure out why this is the case, but I think it's a race condition. ## API Additions: * Version number now reflects release number to prevent confusion. This undoes a change I made a while back where the API version number was independent from the plugin version number. API releases may not change functionality even if the version number is incremented. Removals: * None

## Honeypot 2.6.3 * Add `/honeypot list` to go directly to All Honeypots GUI * Fix [#129](https://github.com/TerrorByteTW/Honeypot/issues/129) * Begin writing permissions manager to be more extensible * NOTE: This permissions manager is heavily lacking in features. More coming soon! * Adjust ListenableQueue functionality