As Minecraft 1.20 comes closer, and Honeypot development starts slowing, I started thinking about what would be best for the future of Honeypot. It's still used by dozens of servers in more than half a dozen countries, so I definitely didn't want it to become stale. What would be the next step? Today I'm excited to announce the start of development for Honeypot 3.0
Honeypot 3.0 will be a re-write from the ground up. Don't get me wrong, I'm extremely proud of some of the methods I've created for handling basic tasks within Honeypot, but I think I could do better. I've done a lot of learning since Honeypot was created, but many of my old methods are still contained within the plugin. The list of features I plan on adding are as follows:
- Asynchronous Database Queries. Honeypot will still rely on SQLite and will not have the ability to access remote Databases due to the nature of the plugin (It doesn't really need it), but the SQLite queries will be asynchronous. This will be to prevent locking code, and increase performance speed of the plugin. Other actions will be able to start being processed while processing existing actions!
- Behavior Providers. Honeypot's existing functionality will still exist, but with behavior providers, you'll be able to determine how those events are handled. For example, the ban action uses Bukkit's built-in ban feature. With behavior providers, you'll be able to dynamically load in behaviors and define what they do. If you wanted a ban to ban them from aspecific location on your server instead of the server overall, you can do that!
- Plugins. Honeypot will have a feature called "plugins" (Revolutionary, I know) which will allow developers to add functionality to the Honeypot. Default plugins will include WorldGuard and GriefPrevention. These features already exist today, but they're being renamed, and being given extra functionality. More on this to come, as I'm working out details.
- Pub/Sub model. Honeypot will function based off a Publisher/Subscriber model internally and externally. This means that when an action is triggered by a player, Honeypot will simply dispatch the command to whatever subscribers are listening, and those subscribers will be responsible for handling the action, accordingly! In practice, these subscribers would be the behavior providers
- Self-contained API. Splitting the API into its own module seemed like a good idea, but I'm realizing the more I maintain this plugin that it was a bad idea. Plus, since it's open source, it doesn't really matter if the main plugin's logic is abstracted away. Therefore, the API will be self-contained in the main plugin jar.
- In-game config editor. No more
/honeypot reload! If you want to make some adjustments to the plugin, you can simply use the in-game editor!- I'm thinking about creating a web-based editor as well. I'll feel this out as I go :)
I hope you're as excited for Honeypot 3.0 as I am. These ideas have given me a new drive to continue work on the plugin for many versions to come. If you have any ideas, please be sure to leave a feature request so I can research it. The timeline for this release is ~2-3 months, as I have to put a lot of work into it. I can't guarantee it'll be ready by version 1.20, but rest-assured this version will be everything you didn't know you wanted.
While development of this is on-going, in the meantime I'll be pausing development of version 2.x. When 1.20 releases, if version 3.0 isn't finished, I'll push an update to include the new blocks to ensure compatibility. I'm looking forward to what version 3.0 has to offer server admins and staff!
-Nate (TerrorByte)