Honeypot

Honeypot

Plugin

Honeypot is a customizable anti-grief plugin which allows any placeable block to be used as a trap for players looking to grief.

Server ManagementUtility

319 downloads
4 followers
Createda year ago
Updated8 days ago

Follow Save
Host your Minecraft server on BisectHosting - get 25% off your first month with code MODRINTH.
Filter loader...
Filter versions...
Filter channels...

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.

Changes:

  • Fixed a bug in /honeypot history query where the command would just return random values from the table instead of the most recent values in descending order.
  • (Internal change) Refactored the plugin to use Dependency Injection, which will make the plugin easier and faster to develop. It also has the benefit of potentially making the plugin slightly faster and more efficient since it's not 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.

Removals:

  • None

API:

Additions:

  • None

Changes:

  • None

Removals:

  • None

The SQLite patching system I've written has been mostly tested, but I'm still not 100% about it, more like 98%. Due to this, I'm marking this a pre-release until I finish testing the weird one-off scenarios. If you want to upgrade the DB manually so you don't have to fear anything, here are the two commands you need to run in some SQLite DB explorer!

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

Sorry for the delayed updates with this project. In real life I've been pretty busy with my daughter and family, as well as studying for multiple IT certificates (Genesys Cloud CX for my job, CKA, and CompTIA Security+), and my time has been stretched so thin I barely have time to think haha. That being said, this project is not dead, just...slowed. I hope you understand and still stick with it! I welcome pull requests if anyone wants to help add some features. Thanks, everyone! 😄


Honeypot 3.2.2

Updated for version 1.20.5. To support backwards compatibility, I'm planning to remove the PhysicsUtil and just check if any blocks surrounding a block break event were Honeypots and are now air. I want to test this for efficiency to ensure these checks don't bog down the server, so I'll combine some methods and work on improving efficiency (We already switched to PDC so this will really help).

This also fixes a minor, likely unnoticed, bug regarding reloading language files from the console. Finally, it adds some better debug logging for block break events, and updates some logic. This logic was complex prior to the refactor, so if anything stops working that I didn't see in testing, let me know via Discord or an issue!

Core

Additions:

  • None

Changes:

  • Better debug logging for BlockBreakEvent
  • Fixed a bug where language files wouldn't be reloaded if /honeypot reload was ran from console. This was a result of the Console's /honeypot reload logic actually being decoupled from the plugin's /honeypot reload subcommand. I apparently forgot to add language file reloading via console when I added translation support, and it's been like that ever since.

Removals:

  • None

API:

Additions:

  • None

Changes:

  • None

Removals:

  • None

Honeypot 3.2.1

Resolves a bug in the previous version of Honeypot where all Honeypot types in the "Create Honeypot" inventory would show as Paper. This is now configurable on the action level, meaning you can have whatever icon you want!

Core

Additions:

  • Custom actions can now specify an icon for their GUI counterparts

Changes:

  • The API is no longer bundled with Honeypot, you must use the separate API package. Please refer to the Honeypot wiki for instructions on how to do this if you develop with Honeypot. This is a simple dependency swap, everything else is the same.
  • Custom actions no longer display as Paper, which was the fallback if an icon based on the type didn't exist. A previous version of Honeypot removed the type requirement, so if you removed the type field, you probably noticed all your icons were paper.

Removals:

  • None

API:

Additions:

  • None

Changes:

  • The API is now bundled as a separate project. Please use that to develop with Honeypot going forward.

Removals:

  • None

Honeypot 3.2.0

This update adds support for an experimental new storage method, PDC. Persistent Data Containers are an API in Spigot which allow you to store data within Worlds, Chunks, ItemMetas, Entities, TileStates, and Structures. This enables you to store Honeypot data directly in the world instead of the sqlite DB, meaning faster queries and less TPS lag. This is an experimental feature, and while it's been tested and is working, should still be considered experimental until the next version when I make it a standard feature. To enable it, update the plugin and restart your server, open your config, go allllllllllll the way down the bottom and change storage-method from sqlite to pdc. Then, restart your server one last time.

Core

Additions:

  • Experimental support for utilizing PDC for Honeypots. This currently uses the World to store data, as any other method wasn't feasible.
  • A new /honeypot debug command, which is disabled by default and can only be enabled by a config change followed by a server restart. This command is specifically for me to use when developing Honeypot, but may come in handy for other server owners, who knows. So, it's been documented.

Changes:

  • None

Removals:

  • None

Known Bugs:

  • None at the moment! Let me know if you find any :)

API:

Additions:

  • None

Changes:

  • None. The addition of PDC will not affect your plugin if you were using the HoneypotBlockManager to interact with Honeypot. If you were using the SQLite or Database classes for some horribly abusive reason, you will be affected if the server decides to switch to PDC, as these classes, while they will still function, will not have updated data.

Removals:

  • None

Known Bugs:

  • None

I gave up on MD5 checksums. I really don't feel like wasting my time generating them. So, from now on those will not be provided. If you ever don't trust a release, build from source, as each of my commits is signed and verifiable with my SSH key (Need my public ed25519 key? Get it here). It should be relatively easy, just clone the project and gradle build 😄

What's Changed

  • Optimized some events that may have caused lag on older hardware or shared hosts.
    • One of those events was BlockFromToEvent, which was to help prevent water and lava from breaking Honeypots such as torches. This event is now part of the "extra" events in config, and is off by default. If this is left off, the Ghost Honeypot Fixer will come in and, at every interval you set in the config, will check if any Honeypots are water or lava. If so, it's assumed that water destroyed a Honeypot and the block will be removed from the DB. The drawbacks of this are that water can destroy certain Honeypots now, but the benefits are a very noisy event is no longer fired
    • The other event that was modified was InventoryMoveItemEvent. This event is what handles processing hopper and dropper moves to/from an inventory. This is a very noisy event as well, and as a result can fire thousands of times a second. I've done what I can to optimize this event as well. On shared hosts or hosts with older hardware, however, this event can still be an issue. I've done Spark profiler tests and Timings checks (Even though Timings is deprecated and isn't accurate per the Paper team), and it seems to be better, but if server owners continue to have issues let me know! I'm still working on optimizing this, and have reached out to folks that know better than I for assistance as well.
  • Migrated build system from Maven to Gradle (Resolves #166)

New Contributors

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:

  • Lands is now a supported integration! If Lands is installed on your server, Honeypot will not allow creation of a pot within a claimed Land
  • Placeholder API support is here! You can now use Placeholder API in your custom Honeypots
  • Honeypot now has a built-in Placeholder Extension! These Placeholders allow you to display messages such as "Player has broken 3/5 Honeypots". This would be written as "Player has broken %honeypot_current_count_broken%/%honeypot_breaks_before_action% Honeypots". There are currently three placeholders available:
    • %honeypot_current_count_broken% -- This placeholder displays the count of Honeypots the player has broken this cycle. This means that this value will never be more than blocks-broken-before-action-taken in config.
    • %honeypot_breaks_before_action% -- This placeholder displays the value of blocks-broken-before-action-taken.
    • %honeypot_current_count_broken_<player>% -- This placeholder will get the current amount of Honeypots a specific player has broken this cycle. This value will never be more than blocks-broken-before-action-taken in config.
  • More listeners to prevent creative ways of destroying Honeypots

Changes:

  • HoneypotConfigManager now shuts down the plugin if it fails to reload using non-deprecated methods
  • /honeypot reload now shuts down the plugin if anything fails during the reload
  • /honeypot reload will now reload the Ghost Honeypot Fixer, which means changes to those settings no longer require a restart. This means that the GHF can now be started or stopped on the fly
  • Config is now version 18
  • Languages files are now version 4 (With the exception of French, which is now version 3). Be sure to update your custom translations, if needed!

Removals:

  • Custom Honeypots made in honeypots.yml are no longer limited to types. This means that the "type" key is no longer required, and you can have permissions, commands, broadcasts, and messages all in the same honeypot. I put this under "Removals" because the type requirement has been removed

Known Bugs:

  • None at the moment! Let me know if you find any :)

API:

There were a few changes to the internals of Honeypot. None of these should affect you unless you are a maintainer, as you shouldn't be using these methods in your own plugins.

Additions:

  • None

Changes:

  • Folia utility classes are now stored in the utils folder
  • An AdapterManager now handles all adapters within the plugin. This is a WIP, and I intend to make this cleaner
  • WorldGuardUtil and GriefPreventionUtil have had the "Util" stripped off and replaced with "Adapter". This makes more sense in my opinion
  • The Update Checker and Supported Version checker now use Java's Consumer instead of Bukkit's Consumer import. Not sure how I missed that, but it's been resolved
  • The Deprecated "log" method within HoneypotLogger has been removed
  • ListenerSetup uses more modern methods to register events. Less duplicated code, but slightly more complex.

Removals:

  • None

Known Bugs:

  • None

I gave up on MD5 checksums. I really don't feel like wasting my time generating them. So, from now on those will not be provided. If you ever don't trust a release, build from source, as each of my commits is signed and verifiable with my SSH key (Need my public ed25519 key? Get it here). It should be relatively easy, just clone the project and mvn package 😄

Honeypot 3.0.5

Version 3.0.4 was pulled due to the bug it was supposed to fix not being fixed. Turns out I had made a typo which caused the problem to not be solved. During testing, another major bug was discovered that can cause the plugin to silently fail to finish loading, so this update is recommended for all Honeypot users. The changelog below is largely technical, but is here in the spirit of transparency. I apologize for any issue this caused. Luckily, 3.0.4 was only downloaded twice before the issue was caught, and I know at least one of the servers it was running on was the person who reported it.

Core

Additions:

  • None

Changes:

  • Within the InventoryClickDragEventListener file, it was discovered by a member of my Discord server that the event wasn't being cancelled prior to action being taken, meaning that if a player was removed from the general vicinity of a container, they would keep items inside. See here for the action, and here for the cancellation. So, the event.setCancelled(false) line was moved to above. However, keen eyed devs may notice the issue: #setCancelled(false) is, obviously, false. This should be true, so the event was still not being cancelled. This has been fixed and tested thoroughly to ensure the problem has been resolved.

  • During testing, I threw Honeypot onto a test server (without Vault) and was extremely confused when the /honeypot command wasn't working, but was also not throwing errors. In debugging this I found I left a return; statement inside the #onEnable() method which returns early out of the #onEnable() if Vault isn't found. The original vault code used to live in its own method, but I moved it inside the #onEnable() method a while back and clearly forgot to remove the return. This caused several issues due to the early return, including:

    • GriefPrevention support was not loaded
    • The command manager for Honeypot was not registered (Existing Honeypots would work, but the /honeypot command and GUI would not)
    • The splash message was not output
    • The Folia check was not done
    • Server version support verification was not completed
    • The update check was not ran

    These issues have been fixed

Removals:

  • None

Known Bugs:

  • None at the moment. If you find a bug, raise an issue!

API

Changes:

  • None

Removals:

  • None

Nerd info

MD5 checksums:

  • 2192446e2626b1198ea16ae9bc34e9bb honeypot-core-3.0.5.jar
  • bd2b4fc33324ff0442f5056da013f0e5 honeypot-core-3.0.5-javadoc.jar
  • 5355f588e6515410e4b004115d67ed09 honeypot-core-3.0.5-sources.jar

Honeypot 3.0.3

This version fixes some bugs around the block break listener, and also changes some core behavior of the block break functionality

Core

Additions:

  • None

Changes:

  • The allow-player-destruction value in config.yml now determines if action is taken at all. If allow-player-destruction is set to true, action will only be taken if A) blocks-broken-before-action-taken is <= 1, or B) the player has reached the blocks-broken-before-action-taken value. This allows Honeypots to be broken without triggering events, if the staff still choose. If you had blocks-broken-before-action-taken set to 1 or less and/or had allow-player-destruction disabled, this won't affect you. If it was set to a greater value and you had player destruction enabled anyway, then this WILL affect you, as your Honeypots will silently disappear upon breaking.
Allow Player Destruction Blocks Broken Before Action Taken Are you affected?
True <=1 No!
True >1 Yes, this change affects you!
False <=1 No!
False >1 No!
  • Fixed some issues with the Honeypot break logic. It wasn't all inclusive, and some edge-cases would allow certain players to break blocks without punishment.
  • Added more detailed logging to Honeypot. If enable-logging in config is enabled, honeypot.log will include all debug, info, warning, and severe messages. Console will always include info, warning, and severe messages regardless.

Removals:

  • None

Known Bugs:

  • None at the moment. If you find a bug, raise an issue!

API

Changes:

  • None

Removals:

  • None

Nerd info

MD5 checksums:

  • 730d53cc77f90427fa5c83b5685e0e20 honeypot-core-3.0.3.jar
  • 3125da1a01b32a21cae95bdbf52463de honeypot-core-3.0.3-javadoc.jar
  • 46d61e6ff0b3965fda8883e03c671948 honeypot-core-3.0.3-sources.jar

Honeypot 3.0.2

This version adds a new %world% placeholder for custom actions. It also removes the Vault requirement, and instead soft-depends on it, allowing you to run this in Folia servers without issue.

PLEASE NOTE Folia is an experimental server software. In order to make Honeypot run on Folia, I had to move Vault from a hard to soft dependency. This means that, without Vault, you cannot use custom actions of type permission. This is the only caveat!

Core

Additions:

  • %world% placeholder for custom actions. The %world% placeholder will be replaced by the name of the world the block was broken in. For example, if broken in the default Nether, it will say world_nether.

Changes:

  • Vault is no longer required. If not installed, permission custom actions won't work, but that's the only thing that will stop functioning :)
  • Config version has been increased to 16. The %world% feature was a suggestion in my discord, so I'm crediting the suggester accordingly. If you want to be included in the credits, be sure to suggest a feature, report a bug, or translate Honeypot to your native language!

Removals:

  • None

Known Bugs:

  • None at the moment. If you find a bug, raise an issue!

API

Changes:

  • The #process event within the abstract BehaviorProvider class no longer marks the block as @Nullable. This was part of the original design just in case a block wasn't necessarily passed to a provider, but later I wrote the internal code to require a block to be passed before a behavior is processed. This result in this annotation not only being unnecessary, but also contextually wrong. This won't affect your builds, by the way :)

Removals:

  • None

Nerd info

MD5 checksums:

  • d9bd5aa5876977856107abfd77acb2d3 honeypot-core-3.0.2.jar
  • 05654bb2f17c0f8bb764b5d57934e87e honeypot-core-3.0.2-javadoc.jar
  • 0866d4954cbd69669d830c8bc712c52e honeypot-core-3.0.1-sources.jar

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

  • 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

Changes:

  • 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!)

Removals:

  • None

Known Bugs:

  • None at the moment. If you find a bug, raise an issue!

API

Changes:

  • None

Removals:

  • Individually packaged API is no longer available

Nerd info

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:

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

Changes:

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

Removals:

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

Known Bugs:

  • If a player spam clicks an item in a Honeypot, it may still be placed. I am trying to figure out why this is the case, but I think it's a race condition.

API

Changes:

  • The API is packaged with the honeypot-core file now, it is not a separate file.

Removals:

  • Individually packaged API is no longer available

Nerd info

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:

  • None

Changes:

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

Removals:

  • None

Known Bugs:

  • If a player spam clicks an item in a Honeypot, it may still be placed. I am trying to figure out why this is the case, but I think it's a race condition.

API

Additions:

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

Removals:

  • None

Honeypot 2.6.3

  • Add /honeypot list to go directly to All Honeypots GUI
  • Fix #129
  • Begin writing permissions manager to be more extensible
    • NOTE: This permissions manager is heavily lacking in features. More coming soon!
  • Adjust ListenableQueue functionality

External resources



Project members

TerrorByteTW

Owner


Technical information

License
Project ID