Plugin Config
The config.yml file is responsible for all the core configuration in the plugin. You can download a sample config.yml file here.
Database Settings
Database settings relate to the config. In early versions of Honeypot it actually did correlate to DB settings, but now it's just there. It could be renamed, but for now know it doesn't actually mean database
file-version
A number used internally to identify the version of the config file. This number is used to handle file updates and other things. Do not modify it, otherwise you risk your config being damaged
cache-size
The number of Honeypot objects that Honeypot will store in memory. This can increase the speed of Honeypot at the expense of a minimal increase in memory usage (Think bytes, not megabytes). Set to <= 0 to disable
Plugin Settings
Plugin settings relate to the core plugin functionality. This is where you'll determine how Honeypot functions
enable-extra-events
Enables some extra events that Honeypot can listen to. These events can be quite noisy, so Honeypot may end up taking more of the tick time on the server. Leaving these off is not harmful, and is why it defaults to false
blocks-broken-before-action-taken
The number of Honeypot blocks a player is allowed to break before action is taken. Set to 1 for immediate action
allow-player-destruction
Allows players to actually break a Honeypot block. When false, Honeypot blocks are impossible to break
allow-explode
Allows Honeypot blocks to be blown up
allow-enderman
Allows enderman to pick up Honeypot blocks
container-actions.enable-container-actions
Enables actions when a player attempts to open a container (Excluding entity containers like Donkeys and Villagers). When disabled, Honeypots can only be triggered by breaking, not interacting
container-actions.use-inventory-click
This setting changes how Honeypot handles containers. Instead of triggering the moment a container is right-clicked, it triggers when a slot within the container is clicked
container-actions.only-trigger-on-withdrawal
Only trigger an action when items are attempted to be withdrawn from a container, not deposited. This only applied if container-actions.use-inventory-click is true.
always-allow-container-access
Allows players to still open containers, even if use-inventory-click is false (Meaning the right-click event would be immediately intercepted and cancelled under normal circumstances). If this is true, however, players will still be able to have full control over an inventory once opened.
search-range
The default range /honeypot locate and /honeypot remove near will use when searching.
ghost-honeypot-checker.enable
Enables the "Ghost Honeypot Checker". In the event a Honeypot is removed somehow (Such as a Honeypot block made of Leaves that decays), this will ensure that the space the block was occupying is removed from the database.
ghost-honeypot-checker.check-interval
The amount of time in minutes that the checker will run. 20 minutes = 1 Minecraft day
enable-logging
Enables all INFO, WARN, and SEVERE logs from Honeypot to be logged to disk, as well as more detailed DEBUG logs that aren't put in console
discord.enable
Enables or disables Discord webhooks, which are sent either when a player breaks a Honeypot, action taken or not, or just when an action is taken. Webhooks are sent in a separate computational thread, so they can be delayed by up to a few seconds
discord.url
The URL of your Discord webhook
discord.send-when
Determines when to send the Discord webhook message. There are two options:
Type | Description |
|---|---|
| Sent only when an action is taken. If you have |
| Sends a webhook immediately upon a break event, regardless of if the break was allowed, and regardless of if an action was triggered |
Chat Settings
Settings that relate to how Honeypot sends messages in chat
language
The language Honeypot will use to send most messages
bypass-language-check
If you are providing your own language file, set this to true. This ensures that an invalid language value doesn't crash Honeypot
history-length
When using /honeypot history query, this is how many values will be returned
Filter Settings
Filter settings relate to what blocks Honeypot will allow to be processed. You can lock Honeypot down so that only certain blocks can be made Honeypots
filters.blocks
Enables filtering blocks
filters.inventories
Enables filtering inventories
allowed-inventories
A list of inventories in MATERIAL format that Honeypot will allow actions to be triggered on when interacted with or modified. The inventory filter does not apply to block breaks, so you can still create Honeypots on disallowed inventories and only the inventory click will be filtered, the breaking of the block will still be allowed unless otherwise stated in the allowed-blocks list
allowed-blocks
A list of blocks in MATERIAL format that Honeypot's can be created on. If block filtering is enabled, and you try to create a Honeypot using a block not in the list, it will be disallowed
Experimental Settings
Experimental settings are settings that exist within Honeypot that add or enable new features, but can be potentially unstable or cause issues. Over time as these features are developed, they will be considered stable and moved into the proper category
storage-method
Allows server admins to select the best method of storing Honeypot block data, specifically. Honeypot Player and Player History data is stored in SQLite regardless. However, block data, which is queried extremely often, can benefit from different storage methods such as PDC. There are two options
Type | Description |
|---|---|
| Stores block data in the |
| Stores Honeypot data using the PDC (Persistent Data Container) API. Honeypot data is stored as key-value pairs in the "world" PDC. This also means that Honeypot data is dependent on the level.dat, and could theoretically be damaged by tools such as Amulet. |
allow-third-party-storage-managers
Honeypot allows for third party storage implementations to be programmatically added. This allows developers to add support for other systems like MySQL, H2, PostgreSQL, JSON, etc. As a security measure, this setting is in place to ensure that a third-party implementation doesn't get loaded without consent
Credits
A functionless config section. The only value in it, thank-you, only exists to ensure the comments above are populated. Without the config value, the YAML parser considers the comments unneeded and ignores them.