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:
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:
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
- 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.
- 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
- Other minor performance changes and enhancements
- Spigot support
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.
- Refactored some classes. Imports will need updated
- 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:
Additions:
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.
- None
- None
Additions:
- None
- None
- None
Changelog
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:
Additions:
ALTER TABLE honeypot_history ADD `type` VARCHAR NOT NULL default 'prelimBreak';
PRAGMA user_version = 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 players attempted to break blocks, as well as when action was actually taken.
- 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 newing 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.
- None
Additions:
- None
- None
- None
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.3.0
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:
Additions:
ALTER TABLE honeypot_history ADD `type` VARCHAR NOT NULL default 'prelimBreak';
PRAGMA user_version = 1;
Honeypot 3.3.0
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.
- 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 newing 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.
- None
Additions:
- None
- None
- None
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:
Additions:
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
- 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.
- None
Additions:
- None
- None
- 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:
Additions:
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
- 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.
- None
Additions:
- None
- The API is now bundled as a separate project. Please use that to develop with Honeypot going forward.
- 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:
Additions:
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.
- None
- None
- None at the moment! Let me know if you find any
Additions:
- None
- 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.
- None
- None
## 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
* 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:
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:
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
- 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!
- 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
- None at the moment! Let me know if you find any
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
- 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.
- None
- None
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:
Changes:
MD5 checksums:
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
- 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
- None
- None at the moment. If you find a bug, raise an issue!
Changes:
- None
- None
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.4 - RECOMMENDED UPDATE
This version is a hotfix for a bug which may cause items to not be returned to a container inventory. It is the only change to Honeypot this update cycle and shouldn't affect you
Core
Additions:
Changes:
MD5 checksums:
This version is a hotfix for a bug which may cause items to not be returned to a container inventory. It is the only change to Honeypot this update cycle and shouldn't affect you
Core
Additions:
- None
- Fixed a bug related to Inventory Click or Inventory Drag events. The events were cancelled after action was being taken. If the action included removing a player from the immediate area (Jailing, kicking, banning, or otherwise teleporting away) then the items would not be returned to the inventory. Events are now cancelled prior to action being taken
- None
- None at the moment. If you find a bug, raise an issue!
Changes:
- None
- None
MD5 checksums:
- a7737b7cd4c5d4ee49891df963bcea1e honeypot-core-3.0.4.jar
- 113fed6df1665a25a9176daf77eca2f6 honeypot-core-3.0.4-javadoc.jar
- 74b85e17a2191c48dcbf94807cbcfac2 honeypot-core-3.0.4-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:
Changes:
MD5 checksums:
This version fixes some bugs around the block break listener, and also changes some core behavior of the block break functionality
Core
Additions:
- None
- 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 download page for more info!
- 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.
- None
- None at the moment. If you find a bug, raise an issue!
Changes:
- None
- None
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:
Changes:
MD5 checksums:
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.
- 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!
- None
- None at the moment. If you find a bug, raise an issue!
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
- None
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:
Changes:
MD5 checksums:
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
- 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!)
- None
- None at the moment. If you find a bug, raise an issue!
Changes:
- None
- Individually packaged API is no longer available
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:
Changes:
MD5 checksums:
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 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.
- 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).
- 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.
- 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.
Changes:
- The API is packaged with the honeypot-core file now, it is not a separate file.
- Individually packaged API is no longer available
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:
Additions:
This version simply ensures functionality with MC 1.19.4
Core
Additions:
- None
- 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 in the GitHub repo. As always, the plugin is open source so you can verify this yourself. Relevant code is here and here. As always, security is of the utmost priority, so Honeypot will never make remote calls to servers that it doesn't need to.
- None
- 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.
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.
- None
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:
Additions:
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
- 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).
- None
- 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.
Additions:
- None
- 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:
Additions:
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
- 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.
- None
- None at the moment. If you see any bugs, please be sure to report them!
Additions:
- None
- 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.
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:
Additions:
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.
- 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
- None
- None at the moment. If you see any bugs, please be sure to report them!
Additions:
- Added two new events, HoneypotPreInventoryClickEvent and HoneypotInventoryClickEvent.
- 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!
Hi everyone! This update adds a small but nice feature to close
#120
Core
Additions:
Changes:
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
- None
- None
- None at the moment. If you see any bugs, please be sure to report them!
Changes:
- None
Hi everyone! Small maintenance update
Core
Additions:
Changes:
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
- None
- None
- None at the moment. If you see any bugs, please be sure to report them!
Changes:
- Version is now separate from Honeypot version. This means that the currently API version is still 2.5.2
Hi everyone! Another small optional update to help improve some of the internal workings of the code to make things more efficient, and to allow for some features added in the future. It should make the plugin more reliable & resilient.
Core
Additions:
Changes:
Core
Additions:
- Added support for French, which is language code "fr_FR".
- Added a custom ListenableQueue which allows the plugin to queue SQLite queries for better reliability.
- None
- Removed previously deprecated storage manager functions.
- None at the moment. If you see any bugs, please be sure to report them!
Changes:
- Removed previously deprecated storage manager changes. Please see this Gist for information on this breaking change
Hi everyone! Small optional update to help improve some of the internal workings of the code to make things more efficient, and to allow for some features added in the future. It also gives me an excuse to bump the threads on Spigot, Polymart, and Built By Bit
Core
Additions:
Changes:
Core
Additions:
- None
- Changed Storage Manager classes to be singletons, which will allow some cool features later on. If you are using plugins which hook into Honeypot, please make sure they are updated before you update yourself. This version can be downgraded just by a simple "drag-and-drop" of version 2.5.0. Plugins using the legacy method of hooking into the storage class will still work due to me deprecating the old method instead of removing it entirely until the next version of Honeypot (Either 2.5.2 or 2.6.0, whichever comes first). At that point I will completely break over to the new singleton methods.
- None
- None at the moment. If you see any bugs, please be sure to report them!
Changes:
- The three Storage Manager classes are now all singletons. You may access these by calling the static #getInstance() method on them. Please see this Gist for information on this breaking change
Hi everyone! No, you're not seeing things. This was supposed to be 2.4.0 but I accidentally named it 2.5.0. Oh well
This update is pretty massive, and fixes quite a few bugs as well as adds a really amazing history command to allow staff to query player Honeypot activity. If a player triggers a Honeypot, you'll know where and when it happened, and what the action was!
Core
Additions:
Additions:
This update is pretty massive, and fixes quite a few bugs as well as adds a really amazing history command to allow staff to query player Honeypot activity. If a player triggers a Honeypot, you'll know where and when it happened, and what the action was!
Core
Additions:
- Created a new /honeypot history command for querying player history
- Permission is honeypot.history
- Added history GUI button to main menu.
- Added alias to the honeypot command. You may now use /hp for all Honeypot commands
- Added info command and warning messages if server admins try to load Honeypot on a version of Spigot this plugin doesn't yet support.
- Added more caching checks so Honeypots can also get data from the cache, not just verify their status.
- Updated some configs and language files.
- Fixed a bug where players who lit TNT to break blocks wouldn't activate Honeypot blocks.
- Fixed improper permission registration in plugin.yml caused by a recent change to the remove and break permissions.
- Updated the language files to version 2. Please make sure if you're using a custom language file that you add translations for the newest entries. Built-in languages will update automatically.
- None
- None at the moment. If you see any bugs, please be sure to report them!
Additions:
- The history command relies on a new object type, HoneypotPlayerHistoryObject. This object contains the player's name, UUID, the date and time of the event, and the HoneypotBlockObject.
- You may retrieve these history objects by using the new HoneypotPlayerHistoryManager class, which contains functions for adding, removing, querying, and purging the history table in the database.
Good afternoon, everyone! This is a small update just supporting multiple languages. My goal is for as many people to be able to use this plugin as possible but limiting the plugin to English only doesn't support that goal. Therefore, new languages!
Core
Additions:
I have begun attaching the sources and javadoc jars for the API if you need them. The JavaDocs are also accessible on the Wiki.
Additions:
Core
Additions:
- Build-in English and Spanish support, with support for custom translations if you like.
- Would you like to help translate Honeypot, or learn how to provide your own translations? Learn how to here!
- Nothing has been changed besides adding multi-language support. If you had custom messages set up in the config.yml, make sure you migrate them to the language file of your choosing.
- None
- None at the moment. If you see any bugs, please be sure to report them!
I have begun attaching the sources and javadoc jars for the API if you need them. The JavaDocs are also accessible on the Wiki.
Additions:
- The HoneypotBlockObject #equals() and #hashCode() functions that were added in Honeypot Core 2.3.0 have been added to API version 2.3.1. You can now safely compare HoneypotBlockObject objects with the #equals() function.
- Just an FYI the #equals() function ignores the action parameter, it only checks against the coordinates and world parameters. These two parameters combined guarantee uniqueness because two worlds cannot be named the same. This also means you can compare Honeypots by creating a new Honeypot with the action of null since the action parameter doesn't matter.
Good evening, everyone! This version adds caching support to Honeypot, making it less dependent on the DB and quicker in general.
Core
Additions:
Nothing has been changed in this version of the API.
Core
Additions:
- A new physics utility to prevent Honeypots from being removed if they A) are adjacent to another one that was legitimately removed and B) not normally affected by physics. This will require Honeypot to be updated each time the game adds new blocks to ensure functionality with those new items.
- Caching support. Please see https://github.com/TerrrorByte/Honeypot/wiki#faq for info on how that works, I've already made a write-up there
- The honeypot.remove permission which previous allowed players to break Honeypots is now honeypot.break. The honeypot.removecommand that previously allowed staff to run /honeypot remove is now honeypot.remove.
- Essentially, honeypot.remove -> honeypot.break and honeypot.removecommand -> honeypot.remove
- None
- None at the moment. If you see any bugs, please be sure to report them!
Nothing has been changed in this version of the API.
Honeypot 2.2.5 is a small update adding support for 3rd party plugins. WorldGuard is tested and working but not fully implemented yet. GriefPrevention is experimental. This version also confirms support on 1.19.1 servers.
Also, for developers, the Honeypot API has been split into its own git submodule for independent development. I will be updating the docs for how to develop against the API shortly. For now, just download the Honeypot-API and put it in your build path.
3rd party plugin support
Adds third party support for GriefPrevention and WorldGuard. Current WorldGuard is tested and functioning, but integration is not complete (For example, /rg bypass is not respected, GriefPrevention is experimental.
WorldGuard:
Also, for developers, the Honeypot API has been split into its own git submodule for independent development. I will be updating the docs for how to develop against the API shortly. For now, just download the Honeypot-API and put it in your build path.
3rd party plugin support
Adds third party support for GriefPrevention and WorldGuard. Current WorldGuard is tested and functioning, but integration is not complete (For example, /rg bypass is not respected, GriefPrevention is experimental.
WorldGuard:
- Adds a new WorldGuard flag, "allow-honeypots". This flag defaults to true. If set to false, Honeypots will not be allowed to be created within the region, even if the person building is a member.
- Pre-existing Honeypots will still function if a region is defined around them
- A new config option has been placed in config.yml under a "3rd party settings" section. If set to false, Honeypot's will not be able to be created within GriefPrevention claims, even if the person has build permissions.
- GriefPrevention is experimental and has not been tested due to a lack of API documentation. I'm working on testing this, but wanted to release it for now.
- Pre-existing Honeypots will still function if a claim is made around them
- While /reload has been an unsupported command for quite some time, Honeypot technically worked fine when being reloaded. However, due to WorldGuard integration, reloading is no longer supported. Don't do it!
Good evening, everyone! This release fixes some bugs related to Honeypot destruction detection, and also improves the API. Version 2.2.0 was supposed to be the 3rd party plugin support update, but this update is functionally large enough I decided to increment it's version number to 2.2.0. Version 2.3.0 will be for 3rd party plugin support. I know it's crucial to get that working, so I'll do it soon!
Core
Additions:
Additions:
Core
Additions:
- Custom logger for logging detailed events. These events are stored in the logs.txt file located in the plugin folder. This file will be created at load time, but will not be used unless enabled in the config (By default it is on).
- Multiple new events! Honeypot can now check for BlockBurnEvent, BlockFromToEvent, and StructureGrowEvent. This will prevent Honeypots from being burned, fluids from destroying Honeypots, and plants from destroying them as well (Such as trees). These events should hopefully fix the issue of Honeypots being left behind when broken.
- Ghost Honeypot checker. By default, every 20 minutes (One Minecraft day) the plugin checks all Honeypots to see if any of them are Air. If so, they are removed. The interval can be configured, and even disabled altogether.
- BlockBreakEvent now always checks adjacent blocks as well to see if any of them are Honeypots. If so, they are proactively removed. This is to prevent ghost Honeypots from existing.
- Running /honeypot upgrade will now put an upgraded key in the honeypots.yml file. This is to prevent Honeypots from being double upgraded. I should've done this in the previous release, so I'm sorry that this is just now rolling out. If you ran the upgrade command and it broke or something happened causing you to need to run it again, please let me know.
- None
- There is no back button on menus to return to the previous menu. If you are in a paginated menu (Like if you have over 27 Honeypots) then the back and forward page buttons work fine, but there is no button to return to the previous menu. I'm trying to figure out how to implement this, but for now this is an issue. It doesn't limit functionality, it's just annoying
- If you see any bugs, please be sure to report them!
Additions:
- Storage Manager classes are now accessible via the API. You can now modify Honeypot Blocks and Players via these methods.
- HoneypotBlockObject and HoneypotPlayerObject are now directly accessible and allow you to create instances of those types. You will likely not need these as of now (However there are one or two methods in the storage manager classes that return these types, hence why they're publicly accessible).
- None
- None
- None
Good afternoon everyone! This release changes the way Honeypot custom actions function. Version v2.1.1 is planning to be an upgrade to the API, and version v2.2 will allow connections to 3rd party plugins to ensure Honeypots don't get left behind (For example, if WorldEdit removes a Honeypot
block. In this example, the Honeypot will still remain referenced in the DB, and can still trigger actions if replaced and then removed again).
Added:
Added:
- /honeypot upgrade command to allow admins to upgrade from previous versions to 2.1.0. This command does nothing if upgrading from a version prior to 1.6 OR if you don't have any custom actions.
- honeypots.yml file, which stores custom Honeypot types. Please visit the wiki for more info on creating these blocks. The plugin comes with 3 demo custom Honeypot blocks for you to try.
- In the past, one single command was stored in the database, and that command would be run on the player breaking the block. Now, Honeypots simply store either one of the default types, or a key of a custom type. Upon breaking, if the type is custom, it will search for that in the honeypots.yml and, depending on the type of block, execute the proper tasks. See this page for creating custom actions.
- Honeypot now depends on Vault and will not load without it. This is to ensure functionality of permission Honeypots
- No features have been removed from this version
- There is no back button on menus to return to the previous menu. If you are in a paginated menu (Like if you have over 27 Honeypots) then the back and forward page buttons work fine, but there is no button to return to the previous menu. I'm trying to figure out how to implement this, but for now this is an issue. It doesn't limit functionality, it's just annoying
- If you see any bugs, please be sure to report them!
This version makes events cancellable. I've also spent a lot of time splitting the API and Core plugin into their own Maven modules. Please review the wiki for how to compile these modules and utilize the API.
The plugin is honeypot-core-2.x.x.jar. The API is honeypot-api-2.x.x.jar. The API will not run on your server! Please use the Core JAR to run the plugin. The Core JAR contains the API as well, but the API jar was specifically built for development.
I've also fixed a few bugs with the update checker and just cleaned up things in general. If you have any issues or questions please open an issue!
The plugin is honeypot-core-2.x.x.jar. The API is honeypot-api-2.x.x.jar. The API will not run on your server! Please use the Core JAR to run the plugin. The Core JAR contains the API as well, but the API jar was specifically built for development.
I've also fixed a few bugs with the update checker and just cleaned up things in general. If you have any issues or questions please open an issue!
Honeypot v2.1 does not add any new features or changes, but instead adds a new developer API for people who want to integrate with my plugin. I would still recommend updating as this fixes a potential memory leak.
Added:
Added:
- 7 new events which are thrown at certain times. These events are:
- HoneypotPreCreateEvent
- HoneypotCreateEvent
- HoneypotNonPlayerBreakEvent
- HoneypotPrePlayerBreakEvent
- HoneypotPlayerBreakEvent
- HoneypotPrePlayerInteractEvent
- HoneypotPlayerInteractEvent
- Moved Config Manager code into its own class.
- Fixed potential memory leak caused by not closing Result Sets for some SQLite queries.
- There is no back button on menus to return to the previous menu. If you are in a paginated menu (Like if you have over 27 Honeypots) then the back and forward page buttons work fine, but there is no button to return to the previous menu. I'm trying to figure out how to implement this, but for now this is an issue. It doesn't limit functionality, it's just annoying
- If you see any bugs, please be sure to report them!
Honeypot v2.0 adds an amazing new in-game GUI as well as updates some dependencies and fixes some crucial bugs.
Added:
Added:
- New GUI which can control all aspects of the plugin! Access it by using /honeypot.
- Moved help menu to /honeypot help
- New gui.yml file allows you to tweak the GUI to meet your design specs. Change all the items in the GUI!
- Help menu has been redesigned to be less ugly. /honeypot now opens the GUI by default instead of displaying the help menu, but you can still get to the help menu by running /honeypot help
- Added a new search-radius value in the config.yml file which will allow you to tweak how far/close the locate and remove-near commands search.
- Updated BoostedYAML to the latest version, which allows better config sorting
- Fixed bug any inventory would trigger Honeypot actions if you were looking at a Honeypot. For example, if you were looking at a Honeypot and then opened a /shop GUI, the Honeypot action on the block you were looking at would activate. This is due to the fact that I was using InventoryOpenEvent and was checking if any inventory was opened while looking at a Honeypot. To compensate for this, I switched to PlayerInteractEvent and checked if the block interacted with was an instance of Container. This means that Inventories are now limited to these blocks: Barrel, BlastFurnace, BrewingStand, Chest, Dispenser, Dropper, Furnace, Hopper, ShulkerBox, Smoker
- There is no back button on menus to return to the previous menu. If you are in a paginated menu (Like if you have over 27 Honeypots) then the back and forward page buttons work fine, but there is no button to return to the previous menu. I'm trying to figure out how to implement this, but for now this is an issue. It doesn't limit functionality, it's just annoying
- If you see any bugs, please be sure to report them!
Honeypot v1.6.5 doesn't add too many new features, however it does bring some important changes.
Added:
Added:
- New honeypot.removecommand permission for removing a block via command without giving the player the ability to remove it by breaking it
- New subcommands for /honeypot remove (all | near)
The "near" subcommand will remove all honeypot blocks within a 5 block radius.
The "all" will remove every single honeypot block on the server.
Choosing to omit the optional "all" or "near" subcommand will just remove the block you're looking at, as normal. - Added %location% placeholder for use in custom actions. This placeholder will get the exact location of the player breaking the block in the format "x y z". For example, "Player" is standing at x=0, y=65, z=0 and breaks a custom action honeypot block. That Honeypot block was set to run this action: tp Player %location%. It would resolve to tp Player 0 65 0
- Completely removed JSON support. JSON was done poorly and I didn't like how difficult it was to implement. It was extremely fast (Due to using RAM instead of a DB file) but it was very complex and I just didn't like it. More storage options will be added in the future, but for now SQLite is the only supported storage medium.
- Fixed NPE if player attempts to run /honeypot create without being in range and looking at a block
- Fixed bug with custom action where the "nothing" Honeypot would try to run the command "nothing" upon break. This was due to me forgetting to add an additional case statement in the switch statement within HoneypotBreakEventListener.java and it taking the default path, which is where custom actions are done (Nothing honeypots used to take the default).
Honeypot 1.6
Gotta love when I get in the programming mood lol! One day after version 1.5 comes version 1.6! This version finally adds custom actions to Honeypot! No more only being able to use the default, built in actions. You can finally teleport a honeypot breaker to the void, or spawn 1000 creepers around them, or broadcast a message to all players! The possibilities are endless!
Note: This feature is DISABLED by default. The reason being is that custom actions are run as if they were being run through the console, not as any specific staff member or player. This means you can op, deop, stop, restart, or do whatever you want to the server with these blocks. Please exercise caution when using this feature. As it can be dangerous, it also requires a specific permission to use, honeypot.custom. Without this permission, staff will be able to create all types of honeypots EXCEPT custom action ones. I am working on a solution to this, but it is difficult without severely hurting the functionality of this feature.
Added:
Gotta love when I get in the programming mood lol! One day after version 1.5 comes version 1.6! This version finally adds custom actions to Honeypot! No more only being able to use the default, built in actions. You can finally teleport a honeypot breaker to the void, or spawn 1000 creepers around them, or broadcast a message to all players! The possibilities are endless!
Note: This feature is DISABLED by default. The reason being is that custom actions are run as if they were being run through the console, not as any specific staff member or player. This means you can op, deop, stop, restart, or do whatever you want to the server with these blocks. Please exercise caution when using this feature. As it can be dangerous, it also requires a specific permission to use, honeypot.custom. Without this permission, staff will be able to create all types of honeypots EXCEPT custom action ones. I am working on a solution to this, but it is difficult without severely hurting the functionality of this feature.
Added:
- Custom actions to Honeypots! Now you are able to do whatever you want with these blocks. This feature uses the Conversation API which is, unfortunately, poorly documented, BUT I still got it to work!
- Use %player% in custom honeypot block actions to target the player that activated the custom action.
- Removed (more) unnecessary parts of code
- /honeypot create custom now requires players to have a specific "honeypot.custom" permission to use. Otherwise, staff can create honeypot blocks except for custom action ones.
- Incremented config version to '2'.
- None in this version! I couldn't find any bugs, but if you find any please report them!
- When the config is updated upon plugin load, new values are put at the bottom. This is unfortunate because I made it so pretty last time D: I am working to see if there is a way to resolve this in the updater settings. For now, though, the config will update fine but newer options may not be where you expect them to be.
Honeypot 1.5
This version adds filters to inventories and blocks! It also switches to UUIDs instead of player names and uses a new config manager library called BoostedYAML. With BoostedYAML, I can enable config updating without requiring server administrators to re-create or delete their existing config file. Unfortunately, this means you will need to, once more, delete your config file before installing this plugin. HOWEVER, this is the last time! I realize this is...inconvenient, and I'm deeply sorry for the inconvenience. I couldn't figure out a graceful way to achieve this, but with BoostedYAML this problem is solved for the forseeable future.
Added:
* BoostedYAML support on the backend for future config updates without requiring admins to delete or manually modify config files.
* Filter support! Server admins are now able to filter which blocks can be turned into Honeypots, and which Inventories will trigger actions when opened (Regardless of if the block itself is a Honeypot).
Changed:
* Switched from using Player Names to UUIDs. This ensures players changing their names doesn't reset their Honeypot stats (if the server admin set up blocks-broken-before-action-taken). The plugin will also automatically convert player names to UUID when a player joins the server and previously existed in the database.
* Made config.yml much prettier (Will appear when the server admin updates their config).
* Removed unnecessary parts of code
Bug Fixes:
* Fixed a bug I caused in the last hotfix which prevented inventory actions from working except for Ender Chests (This was inverted accidentally. The intended function is to prevent ender chests ONLY from triggering inventory actions)
* Fixed a bug where running "/honeypot" from console without any args would through an OutOfBounds exception
This version adds filters to inventories and blocks! It also switches to UUIDs instead of player names and uses a new config manager library called BoostedYAML. With BoostedYAML, I can enable config updating without requiring server administrators to re-create or delete their existing config file. Unfortunately, this means you will need to, once more, delete your config file before installing this plugin. HOWEVER, this is the last time! I realize this is...inconvenient, and I'm deeply sorry for the inconvenience. I couldn't figure out a graceful way to achieve this, but with BoostedYAML this problem is solved for the forseeable future.
Added:
* BoostedYAML support on the backend for future config updates without requiring admins to delete or manually modify config files.
* Filter support! Server admins are now able to filter which blocks can be turned into Honeypots, and which Inventories will trigger actions when opened (Regardless of if the block itself is a Honeypot).
Changed:
* Switched from using Player Names to UUIDs. This ensures players changing their names doesn't reset their Honeypot stats (if the server admin set up blocks-broken-before-action-taken). The plugin will also automatically convert player names to UUID when a player joins the server and previously existed in the database.
* Made config.yml much prettier (Will appear when the server admin updates their config).
* Removed unnecessary parts of code
Bug Fixes:
* Fixed a bug I caused in the last hotfix which prevented inventory actions from working except for Ender Chests (This was inverted accidentally. The intended function is to prevent ender chests ONLY from triggering inventory actions)
* Fixed a bug where running "/honeypot" from console without any args would through an OutOfBounds exception
Hotfix for an NPE that was caused when opening entity-based inventories.
This fixes some large bugs that were caused due to the 1.4 update. Please download this one and cease using 1.4.
Release Honeypot 1.4.1 ยท redstonefreak589/Honeypot (github.com)
Release Honeypot 1.4.1 ยท redstonefreak589/Honeypot (github.com)
Honeypot 1.4.1
This version contains many bug fixes and adds SQLite support!!!!! SQLite is a database that allows for very quick data lookups and non-volatile permanent storage. This is now the DEFAULT storage method, however you can still use JSON if you wish. There are no new in-game features or commands, this is just a big-fix and storage update.
Added:
Changed:
Bug Fixes:
Fixed in the 1.4 update (Now pulled)
Known Issues:
This version contains many bug fixes and adds SQLite support!!!!! SQLite is a database that allows for very quick data lookups and non-volatile permanent storage. This is now the DEFAULT storage method, however you can still use JSON if you wish. There are no new in-game features or commands, this is just a big-fix and storage update.
Added:
- SQLite support. The database is stored within the plugin folder and is called "honeypot.db".
- Added a config option called "database". This will default to "sqlite" as it is the recommended way to store plugin data.
- Proper tab completion. This is being considered a feature and also a bug fix.
- SQLite requires the jdbc library, which came with my installation of Java by default. However, your server may not have it. If you are self hosting, install jdbc in your java /lib folder. If you are hosting with a server provider, ask them about installing jdbc on your server.
Changed:
- When players join with the "honeypot.update" permission and an update is available, instead of just being told where to go to download the plugin, you are now also able to go to the Github page.
Bug Fixes:
Fixed in the 1.4 update (Now pulled)
- Fixed a bug where tab complete would always list all subcommands instead of partial matches
- Fixed a bug with the "breaks-before-action" config option where A) if the value was more than 1, and B) the player had at least one of these permissions (exempt, remove, or OP), the event would be cancelled without any feedback from the system and the block would be impossible to break without the "/honeypot remove" command.
- Fixed a bug where the "/honeypot reload" command was blocked from being run via console
- Fixed a bug where any partial block in front of a targeted block was selected for the create command. For example, looking at a bookshelf that was behind a lever and running the "/honeypot create" command would create a Honeypot on the lever, not the bookshelf. Turns out, Spigot added a "getTargetBlockExact" method and I was using "getTargetBlock". Very easy fix once I learned about it!
- Fixed a bug where honeypot blocks would activate regardless of what world they were created in (For example, a non-honeypot in the nether at 0, 0, 0 would function just the same as a honeypot block in the overworld at 0, 0, 0)
- Please note that the plugin will not convert your database automatically. Because I cannot guess which world your honeypot is in, the plugin will just allow blocks to be broken. Please visit the wiki on how to fix your existing JSON database.
- Fixed a bug where Honeypot events triggered in different worlds but at the same coordinates could fail when using JSON
- Fixed a bug in which Honeypot blocks at the same coordinates but in different worlds would fail to be created when using SQLite due to a primary key constraint failing
- Fixed a bug in which Honeypot blocks at the same coordinates but in different worlds would fail to be created when using JSON due to improper logic during creation
Known Issues:
- None. Please open an issue on Github if you have any!
Honeypot 1.3.1
This version simply ensures support for 1.18, as well as cleans up the code. I've also refactored most classes of the code to make it easier to read & maintain, and also to take advantage of some newer features in Java that I'm learning, such as records (This project is meant to be a learning experience for me as well!).
I'm working on adding SQLite support very soon and making some major upgrades to the way server staff interact with the plugin. Hopefully I can get an update out on this by Janurary/February 2022!
Please see below for the Honeypot 1.3 changelog
Honeypot 1.3
This version contains a locate command which will make it easier to find honeypot blocks for admins. Running it will find any honeypot block within a 5 block radius of the player. To find a list of all honeypot blocks on the server, you must still look at the config. This is a fair trade off to me, but if anyone would like this changes let me know. It also contains a PlayerJoinEvent listener to notify admins of plugin updates on join to prevent update messages being lost in the console. This is, of course, disable-able with permissions
Added:
* /honeypot locate command. This command works by summoning an invisible, invincible glowing slime inside the honeypot block. It is the exact same size as a block so it will look like the block is glowing. This, however, disables you from mining the block while it's there because it is just ever so slightly larger. The slime will live for 5 seconds before being removed.
* Added a function to notify staff of updates to this plugin on join.
* Added the honeypot.locate and honeypot.update permissions. Add these permissions to players to allow them to use /honeypot locate and be notified of updates on join, respectively. honeypot.*, as always, contains all of these permissions.
Changed:
* No major changes to this version, however in some future versions the storage methodology may be modified. JSON support will always remain, however in the future it may not be the default
To-Do:
* Update the block storage and player storage methods to be more efficient and less resource-intensive
Known Issues:
* There is an issue which involves creating honeypot blocks with less-than-full blocks in front of them (For example, a lever). Imagine you are a player (P) creating a Honeypot block (H) with a lever in front (L). It would look like this P-L-H. Because the lever is in between you and the Honeypot block, it creates the Honeypot block on the lever, even if you're targeting the Honeypot block. I am using player.getTargetBlock() so I'm not sure why Spigot's API is causing this issue. I will investigate further for an alternative option, but for now, please ensure every block between you and the Honeypot block is air, and not something like a button, redstone dust, lever, flower, grass, etc.
* Another known issue is if staff manually erase the honeypotblock and honeypotplayer config files and forget to leave the square brackets, the plugin will fail upon load. When modifying these config items, please do not erase the [], they must always remain for GSON to function properly.
This version simply ensures support for 1.18, as well as cleans up the code. I've also refactored most classes of the code to make it easier to read & maintain, and also to take advantage of some newer features in Java that I'm learning, such as records (This project is meant to be a learning experience for me as well!).
I'm working on adding SQLite support very soon and making some major upgrades to the way server staff interact with the plugin. Hopefully I can get an update out on this by Janurary/February 2022!
Please see below for the Honeypot 1.3 changelog
Honeypot 1.3
This version contains a locate command which will make it easier to find honeypot blocks for admins. Running it will find any honeypot block within a 5 block radius of the player. To find a list of all honeypot blocks on the server, you must still look at the config. This is a fair trade off to me, but if anyone would like this changes let me know. It also contains a PlayerJoinEvent listener to notify admins of plugin updates on join to prevent update messages being lost in the console. This is, of course, disable-able with permissions
Added:
* /honeypot locate command. This command works by summoning an invisible, invincible glowing slime inside the honeypot block. It is the exact same size as a block so it will look like the block is glowing. This, however, disables you from mining the block while it's there because it is just ever so slightly larger. The slime will live for 5 seconds before being removed.
* Added a function to notify staff of updates to this plugin on join.
* Added the honeypot.locate and honeypot.update permissions. Add these permissions to players to allow them to use /honeypot locate and be notified of updates on join, respectively. honeypot.*, as always, contains all of these permissions.
Changed:
* No major changes to this version, however in some future versions the storage methodology may be modified. JSON support will always remain, however in the future it may not be the default
To-Do:
* Update the block storage and player storage methods to be more efficient and less resource-intensive
Known Issues:
* There is an issue which involves creating honeypot blocks with less-than-full blocks in front of them (For example, a lever). Imagine you are a player (P) creating a Honeypot block (H) with a lever in front (L). It would look like this P-L-H. Because the lever is in between you and the Honeypot block, it creates the Honeypot block on the lever, even if you're targeting the Honeypot block. I am using player.getTargetBlock() so I'm not sure why Spigot's API is causing this issue. I will investigate further for an alternative option, but for now, please ensure every block between you and the Honeypot block is air, and not something like a button, redstone dust, lever, flower, grass, etc.
* Another known issue is if staff manually erase the honeypotblock and honeypotplayer config files and forget to leave the square brackets, the plugin will fail upon load. When modifying these config items, please do not erase the [], they must always remain for GSON to function properly.
Hi everyone! We have a smaller update today, but the functionality it includes are definitely awesome!
This version contains a locate command which will make it easier to find honeypot blocks for admins. Running it will find any honeypot block within a 5 block radius of the player. To find a list of all honeypot blocks on the server, you must still look at the config. This is a fair trade off to me, but if anyone would like this changed please let me know. It also contains a PlayerJoinEvent listener to notify admins of plugin updates on join to prevent update messages being lost in the console. This is, of course, disable-able with permissions
Added:
This version contains a locate command which will make it easier to find honeypot blocks for admins. Running it will find any honeypot block within a 5 block radius of the player. To find a list of all honeypot blocks on the server, you must still look at the config. This is a fair trade off to me, but if anyone would like this changed please let me know. It also contains a PlayerJoinEvent listener to notify admins of plugin updates on join to prevent update messages being lost in the console. This is, of course, disable-able with permissions
Added:
- /honeypot locate command. This command works by summoning an invisible, invincible glowing slime inside the honeypot block. It is the exact same size as a block so it will look like the block is glowing. This, however, disables you from mining the block while it's there because it is just ever so slightly larger. The slime will live for 5 seconds before being removed.
- Added a function to notify staff of updates to this plugin on join.
- Added the honeypot.locate and honeypot.update permissions. Add these permissions to players to allow them to use /honeypot locate and be notified of updates on join, respectively. honeypot.*, as always, contains all of these permissions.
- No major changes to this version, however in some future versions the storage methodology may be modified. JSON support will always remain, however in the future it may not be the default
- Update the block storage and player storage methods to be more efficient and less resource-intensive
- There is an issue which involves creating honeypot blocks with less-than-full blocks in front of them (For example, a lever). Imagine you are a player (P) creating a Honeypot block (H) with a lever in front (L). It would look like this P-L-H. Because the lever is in between you and the Honeypot block, it creates the Honeypot block on the lever, even if you're targeting the Honeypot block. I am using player.getTargetBlock() so I'm not sure why Spigot's API is causing this issue. I will investigate further for an alternative option, but for now, please ensure every block between you and the Honeypot block is air, and not something like a button, redstone dust, lever, flower, grass, etc.
- If staff manually erase the honeypotblock and honeypotplayer config files and forget to leave the square brackets, the plugin will fail upon load. When modifying these config items, please do not erase the [], they must always remain for GSON to function properly.
This version contains some more checks for other types of Honeypot destruction methods such as Pistons and Silverfish. It also allows for colored config messages using & color codes, a customizable prefix, and container open actions. Finally, updated HoneypotUpdateChecker to use GitHub Raw instead of the Legacy Spigot API for version checking, as GitHub Raw is more reliable.
Added:
* Piston push/pull prevention on Honeypot blocks
* Silverfish infestation prevention (Needs testing, could not get silverfish to infest blocks at all, Honeypot and non-Honeypot)
* Ability to run Honeypot actions if containers are opened, not just broken
Changed:
* Switched to using GitHub instead of Spigot's legacy system for update checking. This is not noticeable on the end-user's side but makes development easier and update messages quicker to push
To-Do:
* Notify admins on server join of updates, not just on server start. Servers that rarely/never restart their server or pay attention to logs might miss update messages, so this will be a configurable option.
Known Issues:
* There is an issue which involves creating honeypot blocks with less-than-full blocks in front of them (For example, a lever). Imagine you are a player (P) creating a Honeypot block (H) with a lever in front (L). It would look like this P-L-H. Because the lever is in between you and the Honeypot block, it creates the Honeypot block on the lever, even if you're targeting the Honeypot block. I am using player.getTargetBlock() so I'm not sure why Spigot's API is causing this issue. I will investigate further for an alternative option, but for now, please ensure every block between you and the Honeypot block is air, and not something like a button, redstone dust, lever, flower, grass, etc.
Added:
* Piston push/pull prevention on Honeypot blocks
* Silverfish infestation prevention (Needs testing, could not get silverfish to infest blocks at all, Honeypot and non-Honeypot)
* Ability to run Honeypot actions if containers are opened, not just broken
Changed:
* Switched to using GitHub instead of Spigot's legacy system for update checking. This is not noticeable on the end-user's side but makes development easier and update messages quicker to push
To-Do:
* Notify admins on server join of updates, not just on server start. Servers that rarely/never restart their server or pay attention to logs might miss update messages, so this will be a configurable option.
Known Issues:
* There is an issue which involves creating honeypot blocks with less-than-full blocks in front of them (For example, a lever). Imagine you are a player (P) creating a Honeypot block (H) with a lever in front (L). It would look like this P-L-H. Because the lever is in between you and the Honeypot block, it creates the Honeypot block on the lever, even if you're targeting the Honeypot block. I am using player.getTargetBlock() so I'm not sure why Spigot's API is causing this issue. I will investigate further for an alternative option, but for now, please ensure every block between you and the Honeypot block is air, and not something like a button, redstone dust, lever, flower, grass, etc.
The config will not auto-update in this version. You should delete your old config and reload the plugin/restart the server. If you don't, explosion and enderman grief prevention
will not work. A copy of the new config has been uploaded here. Place it in the plugins/Honeypot folder then run
/honeypot reload to reload the config without any server/plugin restarts/reloads. The same has been reiterated below in the known issues section. I promise this will be resolved shortly!!!
---------------------------------------
Hey everyone! This is a small release designed to fix some glaring issues in the code. Mainly, you could destroy Honeypot blocks in about every way except mining them. This hopefully will prevent all explosions and Enderman from breaking them, with more fixes to come. In the mean time, download this update for these quick fixes!
Added:
---------------------------------------
Hey everyone! This is a small release designed to fix some glaring issues in the code. Mainly, you could destroy Honeypot blocks in about every way except mining them. This hopefully will prevent all explosions and Enderman from breaking them, with more fixes to come. In the mean time, download this update for these quick fixes!
Added:
- Update checker for automatic version checking with Spigot. If this plugin is out of date, it'll let you know on server startup.
- Added explosion checking to prevent TNT griefing, creeper explosions, Ghast fireball destruction, basically any explosion will be prevented
- Enderman grief detection and prevention
- Pistons can still push Honeypots
- Silverfish can still infect, and subsequently break, stone and stone variant Honeypots
- The config will not auto-update in this version. You should delete your old config and reload the plugin/restart the server. If you don't, explosion and enderman grief prevention will not work. A copy of the new config has been uploaded here. Place it in the plugins/Honeypot folder then run /honeypot reload to reload the config without any server/plugin restarts/reloads
Resource Information
Author:
----------
Total Downloads:
2,342
First Release:
Oct 6, 2021
Last Update:
Oct 28, 2024
Category:
---------------
All-Time Rating:
Find more info at github.com...
4 ratings
Version
-----
Released:
--------------------
Downloads:
------
Version Rating:
----------------------
-- ratings