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.