Home
- 👀 Privacy focused. This plugin only collects basic statistics using bStats and nothing more. If you want to know more about this in layman's terms, I'm happy to share! You can view all stats here
- 💪 Lightweight. I wanted this Honeypot plugin to be lightweight. I'm still working on optimizing the code but so far so good.
- 😄 Easy to update. Honeypot uses pretty basic APIs and is hopefully easy to understand, making it not too complicated to update.
- 🔨 Easy to build upon. Each object type in the plugin uses a management class which allows me to expand functionality without making major code changes. I designed the command and listener managers to be extensible, enabling me to add commands, subcommands, and listeners at any time without changing existing code, only adding new code. It also has the added benefit of making it easier for other developers to fork and add on things.
So far I believe I've met those goals, but I'm working on adding more features to the plugin and continuously optimizing as time goes on.
Staff will require the honeypot.commands permission to use any commands, including /honeypot help.
| Command | Permission | Description |
|---|---|---|
| /honeypot | honeypot.gui | Alias for /honeypot gui
|
| /honeypot create | honeypot.create | Creates a honeypot of type type
|
| /honeypot remove (near | all) | honeypot.remove | Remove the honeypot you're looking at. Specify near or all to remove nearby Honeypots or all Honeypots |
| /honeypot reload | honeypot.reload | Reloads the honeypot config. This is the only command that'll work in the console |
| /honeypot locate | honeypot.locate | Locate nearby Honeypots |
| /honeypot help | Display the help menu | |
| /honeypot gui | honeypot.gui | Opens the GUI menu |
| /honeypot history | honeypot.history | Allows looking up a players honeypot history |
| /honeypot debug | honeypot.debug | Allows users to peer into PDC data, if there is any. Only really useful for the developer of Honeypot, and must be enabled in config. |
| Permission | Description |
|---|---|
| honeypot.* | Gives access to all Honeypot commands and permissions below |
| honeypot.break | Allows players to break Honeypots, regardless of config values. They still cannot use /honeypot remove
|
| honeypot.notify | Anyone with this permission will be notified if players break "notify" honeypots |
| honeypot.exempt | Players with this permission will not be affected by Honeypots |
See this link for an example configs and explanations of all their values.
- Create your Custom Action in the honeypots.yml file (See this page for more info)
- Type
/honeypot create <action name>. Enabled behavior providers (Including the built-in ones) and custom actions will be displayed in the same list. Action Name will tab-complete based on values in the config! Remember, Behavior Providers take precedence over custom actions. - You may also use the GUI to create custom actions. See this page for info one what each icon means in the GUI.
Honeypot, as of 3.1.0, now supports Placeholders and even provides three as well. If you want to use custom placeholders, you may do so by adding them to your honeypots.yml file. As for the placeholders that Honeypot provides, those are:
- %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-takenin 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-takenin config.
As a reminder, Honeypot does not currently keep track of the all-time total Honeypots a player has broken. It does, however, keep track of how many they've broken before an action is taken. So, if you have blocks-broken-before-action-taken set to 5, then they can break up to 5 before the counter is reset and an action is taken against the player. These placeholders are meant to display that information to the player at any given time. You can also query a different player using these placeholders.
Q) Is Honeypot efficient?
A) Honeypot tries to be as efficient as possible. It caches Honeypots in memory to prevent costly database transactions, it does its best to return early if it doesn't need to continue processing an event or events, and other features to help with speed. More recently (v3.2.0), Honeypot supports the Spigot PDC API, which removes the dependency on SQLite entirely. It shouldn't cause too much lag on your server, however I'm always optimizing. If you have an issue with the plugin or a suggestion on how to improve it, please let me know!
Q) Is Honeypot secure?
A) I've taken all precautionary steps to ensure Honeypot is secure. Honeypot is obviously a Spigot plugin so it is only as secure as Spigot. It doesn't store any personal information about players or servers, and only collects anonymous statistics via bStats. The plugin is open source for peer review and I also use SonarCloud to scan my code and ensure no slippery security flaws sneak in. Of course, this is all available to the public. Clicking the SonarCloud badge on the README.md page will take you to the SonarCloud dashboard.
Q) How does Honeypot work?
A) Great question! Honeypot, at its core, is simply a tool for storing and retrieving block information from a database, and running actions depending on that data. A staff member creates a Honeypot and defines an action which is then stored in an SQLite database. Then, when a player interacts with that Honeypot, the action is retrieved from the DB, the plugin looks up the code for how the action should be processed, and finally the action is ran against the player. That's the simple definition, there's a lot more to it, of course 😉
Q) What's the caching feature in version 2.3.0?
A) Caching works by storing the latest n queried Honeypots in memory (RAM). That way, when the plugin checks if a block is a Honeypot, it doesn't have to query the database so much. Essentially, when Honeypot needs to check if a block is a Honeypot or not, it'll first check the cache to see if that block exists there. If the block exists, then we know it's a Honeypot and we skip querying the database altogether. If it doesn't exist in cache, it'll then check the database. If the block exists in the Database, then we know it's a Honeypot and it'll store that Honeypot in the cache for future use so if it that same block is queried again it doesn't have to go to the DB 😃
This feature can be disabled and the cache size can also be configured. If you have extra RAM, I'd recommend keeping the cache pretty large. There is no limit to the number of Honeypots that can be put in cache, so you’re only limited by the number you configure in config yourself.