Releases: TerrorByteTW/Honeypot
Honeypot 3.4.0
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 17. Therefore, you MUST run Java 21 as well!
As noted in 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,0003 area (That's eight QUINTILLION blocks) in only a few milliseconds. Before this change, it was impossible to query anything larger than a 103 or 203 without locking up the server. Yay for optimization (And also not doing DB queries the stupid way)! Fixes #187
- 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
- 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 :) 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
3.3.2
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.
- 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
Changes:
- None
Removals:
- None
API:
Additions:
- None
Changes:
- None
Removals:
- None
Honeypot 3.3.1
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 playersattempted
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!
ALTER TABLE honeypot_history ADD `type` VARCHAR NOT NULL default 'prelimBreak';
PRAGMA user_version = 1;
Honeypot 3.2.2
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
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
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. (Resolves #145)
- 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
😄
3.1.1
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
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.
- %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
- 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
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.jarbd2b4fc33324ff0442f5056da013f0e5
honeypot-core-3.0.5-javadoc.jar5355f588e6515410e4b004115d67ed09
honeypot-core-3.0.5-sources.jar
Honeypot 3.0.3
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. It also improves logging to allow for better debugging if issues arise.
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 theblocks-broken-before-action-taken
value. This allows Honeypots to be broken without triggering events, if the staff still choose. If you hadblocks-broken-before-action-taken
set to 1 or less and/or hadallow-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.jar3125da1a01b32a21cae95bdbf52463de
honeypot-core-3.0.3-javadoc.jar46d61e6ff0b3965fda8883e03c671948
honeypot-core-3.0.3-sources.jar