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, 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, or read the documentation 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!
  • 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 Materials that are not able to be represented as ItemTypes (Such as REDSTONE_WALL_TORCH) would cause Honeypot to throw unhandled exceptions in console when a GUI was accessed that attempted to render said Materials.
• 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 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 DoubleChests 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!

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 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 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