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

Changelog

ALTER TABLE honeypot_history ADD `type` VARCHAR NOT NULL default 'prelimBreak';
PRAGMA user_version = 1;

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). 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 #167

Full Changelog: 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). 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, and here for the cancellation. 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 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. Check the GitHub page to see if you're affected (Likely not!)
• 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 2.6.3

This revision of version 2.6 implements some changes that were requested, as well as adds a new command and rewrites some of the base code.

Core

Additions:

• Added new /honeypot list command, which will take you straight to the All Honeypots GUI inventory
  • Permissions for this command are he same as if you were to type /honeypot and manually navigate to the inventory. This is just an alias

Changes:

• Players are disallowed from placing blocks in container if only-trigger-on-withdrawal is set to true (#129)
• Internally, the commands now use a Permission class for verifying permissions. This will allow more extensible permission management later without spaghetti code, and also currently allows permissions to be checked at the command manager layer and not at the subcommand execution layer (Permissions are checked earlier, reducing unnecessary overhead).

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:

• None

Removals:

• None

Honeypot 2.6.2

This revision of version 2.6 fixes two bugs that were previously found in 2.6.1. These are #126 and #127

Core

Additions:

• None

Changes:

• Honeypot now checks if the BlockBreakEvent is cancelled before doing any further processing. This is due to some odd behavior caused by things like creative mode players holding swords. For whatever reason, instead of just not throwing the event, Spigot will instead just mark the event cancelled by default. Checking for these scenarios fixes those types of edge cases.
• GriefPrevention support is now working correctly. Previously, if GriefPrevention support was enabled and respect-griefprevention was set to false, it would immediately block all Honeypot creations across the entire world. Setting this to true would still block staff from building in GriefPrevention areas if they didn't have permission, but would allow them to build elsewhere. This has been fixed by first checking if there is a claim at the coordinates, and if not, immediately continuing the creation process. If there is a claim, it will then check the respect flag and finally GriefPrevention build permissions.

Removals:

• None

Known Bugs:

• None at the moment. If you see any bugs, please be sure to report them!

API

Additions:

• None

Removals:

• None

Honeypot 2.6.1

This release is a hotfix for a bug found in Honeypot which affects versions 2.5.x - 2.6.0 and is recommend for all users. This bug, if abused, allows players to teleport wherever they wanted without needing permissions. The bug works by abusing an internal command used for the Player History GUI menu. This command was not registered with the server so players were unable to see it in the tab-complete menu. However, it was used as a placeholder to bypass needing /minecraft:tp permissions for staff in order to teleport them to where a history event took place. Due to not writing the event listener responsible for handling this command properly, the command bypassed permission checks altogether.

Fix: A new permission, honeypot.teleport, was introduced to prevent abuse of this command. Please ensure if you want your staff to be able to teleport to the location of a Honeypot history item, that they have this permission. My apologies for any issues this may have caused.

Honeypot 2.6.0

The full release of version 2.6.0 is here! Sorry for anyone that tried the pre-release and found it failing miserably lol. This is definitely a version you want to download, as it fixes some major bugs and includes some sick new features.

Core

Additions:

• Added InventoryClickEvent. This new event type will trigger Honeypot actions if an inventory is opened & manipulated, instead of just opened.

Changes:

• config.yml version is now 13 to accommodate new settings
• InventoryClickEvent and PlayerInteractEvent are now mutually exclusive. One will not load if the other is loaded. This is determined by the use-inventory-click value in config. A server restart is required for change to take effect if use-inventory-click is changed.
• Fixed a bug where custom actions would not work on PlayerInteractEvents. Apparently I forgot to migrate that portion of code to the new Custom Action types introduced in 2.1.0. My mistake!
• PlayerInteractEventListener and InventoryClickEventListener are only registered if necessary, reducing overhead. This means your server and Honeypot should be faster, even if ever so slightly :)

Removals:

• None

Known Bugs:

• None at the moment. If you see any bugs, please be sure to report them!

API

Additions:

• Added two new events, HoneypotPreInventoryClickEvent and HoneypotInventoryClickEvent.

Removals:

• Removed deprecated Storage Manager constructors. They were removed from the core plugin, but forgotten in the API, which would've caused some nasty runtime issues if used. Sorry Devs! :P

Hi everyone! This update adds a small but nice feature to close #120

Core

Additions:

• Added a new config option to close #120. This config option will enable server staff to optionally allow containers to be opened even if container actions are enabled. This has not been tested! Theoretically it was an incredibly easy change, but I am moving and my testing PC is currently packed. If it ends up not working, I'll have it fixed for real in about a week 🙂

Changes:

• None

Removals:

• None

Known Bugs:

• None at the moment. If you see any bugs, please be sure to report them!

API

Changes:

• None

Hi everyone! Small maintenance update

Core

Additions:

• Added support for Japanese, which is language code "ja_JP" (Thanks to a Discord server member, @siyukatu!).
• Updated version check to support 1.19.3, no more console spam :)

Changes:

• None

Removals:

• None

Known Bugs:

• None at the moment. If you see any bugs, please be sure to report them!

API

Changes:

• Version is now separate from Honeypot version. This means that the currently API version is still 2.5.2